[FFmpeg-user] Questions about readout important metadata from DPX files ("logarthmic/linear") and recreate DPX with same metadata
dave at dericed.com
Mon Mar 9 21:35:27 CET 2015
> On Mar 9, 2015, at 4:05 PM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> Dave Rice <dave <at> dericed.com> writes:
>>>> As far as I tested I can say (for the
>>>> ffv1-supported pixelformats "gbrp10le" and
>>>> "gbrp12le") it works lossless. All FrameMD5s
>>>> are equal:
>>> (This is not the first time that I am slightly
>>> surprised people use FFmpeg to prove that an
>>> encoder of FFmpeg is lossless.)
>> Why is this slightly surprising?
> Assuming this is done to rule out bugs
> in FFmpeg:
> I find it unlikely that ffv1 is not lossless
> and that you will find out like this (as
> opposed to feed random data to the codec).
Using framemd5 verification after ffv1 encoding, I’ve found about 3 frames that weren’t lossless. This is out of probably millions of frames, but computer problems happen. In all of the cases the a local computer was using an input and an output that were accessed over a network and re-running the process a second time produced an error-free output.
The flac utility has a --verify option for this level of paranoia so that the file written is assessed. I added an enhancement ticket for a similar approach in ffmpeg here: https://trac.ffmpeg.org/ticket/2866 <https://trac.ffmpeg.org/ticket/2866>. The issue is hard to reproduce as reproduction usually involves huge amounts of encoding.
> I find it much more likely that a bug in
> the dpx decoder exists: Since you use the
> same decoder twice in above test you
> would not find such a bug.
This is true with the input but not with this output. This is exactly how we found the libopenjpeg bug referenced here: https://trac.ffmpeg.org/ticket/3745 <https://trac.ffmpeg.org/ticket/3745>. The framemd5 of the original file represents the properly decoded frame but the corresponding framemd5 of the improperly decoded jpeg2000 frame gives a different framemd5 value.
> A bug in both gm and FFmpeg that leads to
> identical output seems less likely to me.
> Of course I do believe that framemd5 is
> useful to compare frames.
> Carl Eugen
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
More information about the ffmpeg-user