[FFmpeg-user] Questions about readout important metadata from DPX files ("logarthmic/linear") and recreate DPX with same metadata

[Dave Rice]

> 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.

Certainly true.
dave

> Of course I do believe that framemd5 is 
> useful to compare frames.
> 
> Carl Eugen
> 
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user