[FFmpeg-user] trouble confirming ffv1 lossless encode

[Dave Rice]

Hi Nathan,

On Feb 1, 2013, at 10:03 AM, Nathan Lewis wrote:

> On Fri, Feb 1, 2013 at 6:20 AM, Peter B. <pb at das-werkstatt.com> wrote:
> 
>> @Nathan:
>> Have you tried Carl Eugen's suggestion?
>> 
>> If there are still issues with verifying FFv1's losslessness is your
>> case, could you upload your uncompressed sample somewhere, so I could
>> take a look at it?
> 
> 
> Hi Peter,
> I was able to test using Carl Eugen's suggestion and I was able to verify
> ffv1's losslessness using -pix_fmt yuyv422 when running framemd5 on the
> ffv1.

I see Carl already answered but in a rather paranoid ffv1 encoding process that I use on uyvy422 source I first run:

ffmpeg -report -vsync 0 -i "$file" -map 0:v -map 0:a -c:v ffv1 -g 1 -c:a copy "${file%.*}_ffv1.mov" -f framemd5 -an "${file%.*}.framemd5"

which outputs the ffv1 encoding as well as a framemd5 of the video track. I then run:

ffmpeg -i "${file%.*}_ffv1.mov" -f framemd5 -pix_fmt uyvy422 -an "${file%.*}_ffv1.framemd5"

which decodes the ffv1 back to the source pixel format. After this if the "${file%.*}.framemd5" output is the same as the "${file%.*}_ffv1.framemd5" then I can consider the visual encoding to be lossless. In your case you'd have to change uyvy422 to yuvy422.

Also consider that the lossless output file may need to represent non-audiovisual tracks of the source. I also include some tests for non-ffmpeg supported tracks and demux these out with muxmovie. If you'd doing lossless encoding in order to consider deleting the uncompressed source file then consider setting the FFREPORT variable before the encodings in order to save the logs in case you need to later audit the process. Like:

export FFREPORT="file=${dirname}/%p_%t_convert-to-ffv1.log"

> @Carl Eugen:
> Apologies for the delay in getting back to you with an update.  I
> appreciate your quick response to my question.
> 
> I have a few follow up questions about the use of -pix_fmt in this example.
> Please let me know if this warrants a new posting/thread.
> 
> My input file (8-bit Uncompressed from a Digital Rapids DRC-1400) is
> yuyv422.  Looking over the -pix_fmts available to ffv1 in ffv1enc.c I found
> that yuyv422 is not supported within ffv1:
> 

[...]

> 
> Would it be better to force the -pix_fmt to something other than the
> default yuv422p for encoding into ffv1?

I think raw data in yuyv422, uyvy422, and yuv422p depicts the same visual data but stores the data in different orders. FFv1 uses planar pixel formats, thus the use of yuv422p. Conversions between the three pixel formats should be lossless.

> I assume that yuv422p represented 8-Bit Planar YUV and yuv422p10
> represented 10-bit Planar YUV.

Yes, in addition to colorspace and bit depth, the pixel format also infers chroma subsampling.

> Is there some place within the ffmpeg
> source (or elsewhere) where I might find some more detail about the
> colorspaces/pix_fmts available to different codecs within ffmpeg?

You can get encoder specific help like this:
ffmpeg -h encoder=ffv1

which yields:

Encoder ffv1 [FFmpeg video codec #1]:
   Threading capabilities: slice
   Supported pixel formats: yuv420p yuva420p yuva422p yuv444p yuva444p yuv440p yuv422p yuv411p yuv410p bgr0 bgra yuv420p16le yuv422p16le yuv444p16le yuv444p9le yuv422p9le yuv420p9le yuv420p10le yuv422p10le yuv444p10le gray16le gray gbrp9le gbrp10le gbrp12le gbrp14le
ffv1 encoder AVOptions:
-slicecrc          <int>        E..V.. Protect slices with CRCs (from -1 to 1)

Dave Rice