On Mon, Mar 30, 2020 at 4:48 PM Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
> I believe there is some historical evidence that this guessing is needed > to get visually correct output in many cases. I haven't found any evidence of that. This guessing has been part of the code since the write_colr flag was originally added. Unfortunately I don't see the original patch in the ffmpeg-devel archives so I don't know what discussions there were around it originally. But I would counter with the following: 1. The user can guess if they want using the -color_primaries/-color_trc/-colorspace flags. 2. If ffmpeg does want to guess, this is the wrong place to do it. There are various parts of ffmpeg that deal with color primaries/trc/space. The right way to guess this info is higher up in the pipeline where it can be consistently applied throughout the pipeline and bitstream. Doing it locally here is just begging for one part of ffmpeg to make one assumption and this part to make a different assumption, which would be even worse. 3. Building on point 2, this is an especially bad place to guess this because the color info is a property of the input, not the output. If this really breaks things for people (which I highly doubt it will) they can always send a patch with a better and more robust implementation. But I feel strongly that we should not stabilize the write_colr flag with this auto-guessing logic. We really shouldn't have people depend on it and should encourage them to use the -color_primaries/-color_trc/-colorspace flags themselves for better color guessing. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
