Am 15.09.2022 um 11:41 schrieb Paul B Mahol:
On 9/15/22, Michael Koch <astroelectro...@t-online.de> wrote:
Am 15.09.2022 um 11:26 schrieb Dan:
You are right that datascope shows no difference. But the issue is also
reproducible with VLC player.
As well as VLC Player and FFplay, I've tried MediaPlayerClassic,
Google Chrome,
Microsoft Edge and Vegas Pro, and the problem occurs with each of
those. Could
there be a "takes two to tango" thing going on, where both the players
and ffmpeg
are at fault due to miscommunication? It's somewhat hard to conceive
they'd all
interpret the file incorrectly otherwise. Only one player I tried -
Irfanview - interpreted
it correctly.
I can't get to test it with Firefox or Waterfox unfortunately. They
think the file
is corrupt (output mp4 produced using the "-f lavfi -i
color=0x19be0f:s=400x720" technique).
Maybe there's a way around that.
Also, showinfo produced an incorrect colour too. See:
https://i.imgur.com/LF43udT.png
(I use: "ffplay.exe -vf showinfo 576.mp4" ).
In summary, I've love a workaround at least, or at least some
reassurance that
Chrome et al. will come round to fix this, or that ffmpeg will
communicate the file
better to them.
This seems to work with VLC player:
ffmpeg -f lavfi -i color=0x19be0f:s=400x576 -colorspace bt709 -crf 0
-vcodec libx264 -t 5 -y out1.mp4
ffmpeg -f lavfi -i color=0x19be0f:s=400x578 -colorspace bt709 -crf 0
-vcodec libx264 -t 5 -y out2.mp4
mostly because of extra -colorspace flag supplied.
Wouldn't it be a good idea to show in FFprobe a message
"colorspace=unknown" if colorspace isn't set?
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
