[FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422) Compression

[Jason Freets]

I'm not sure where to put the file. So, I just uploaded it to DropBox for now. Here's a link to the file:

https://www.dropbox.com/s/6ugnjlivdhdlixt/10BitRGB444_r10k_2sec.avi?dl=0

It's just a 2 second 10 Bit RGB 444 r10K file I already had sitting around. It's about 80 MB.

If you want, I could create a longer and different file too. Just let me know. 

You said, "you can probably test by either doing"...does this mean you've applied the patch to the GIT repository of FFMpeg and I could actually test files? Or? 

If so, I could pull it from GIT and run the compare pattern as you suggested (I have a lot of large files):

r10k -> ffv1 -> r10k -> ffv1 ->r10k

Please let me know. Either way, you have a 2 second file to play with for now. If you need additional test files, please let me know and a place to upload them if DropBox is not suitable for you. =)

Cheers, 

Jason

> Subject: Re: [FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422)	Compression
> 
> Peter B. <pb <at> das-werkstatt.com> writes:
> 
> >   $ ffmpeg -i input.avi -c copy -s 10 -t 5 output.avi
> 
> I wanted to suggest -vframes 3 which would produce a 
> significantly smaller output file.
> 
> Note that you can cut avi with dd (if you don't trust 
> FFmpeg which makes sense if you want to test losslessness.)
> 
> But please note that the reason why r210 -> ffv1 -> r210 
> was not lossless in the past was a bug (or missing feature) 
> in the software scaler. This issue was fixed a year ago and 
> it has also fixed the issue with r10k.
> The difference with r10k is that it is more difficult to 
> show that the conversion is lossless, instead of:
> 
> > r10k's format: rrrrrrrr rrgggggg ggggbbbb bbbbbbxx
> 
> FFmpeg writes:
> r10k's format: rrrrrrrr rrgggggg ggggbbbb bbbbbbbb
> (blue is 12 instead of 10 bits.)
> The conversion is still lossless but the most significant 
> blue bits will be repeated as an eleventh and 12th bit 
> making the files not bit-identical (while the saved frames 
> are bit-identical) assuming xx are 0 (if they aren't 0 you 
> will never get identical output files).
> 
> Two patches are currently discussed to fix this issue in 
> the encoder (which does not affect that the output is 
> lossless but does affect the easiness of testing) but 
> you can probably test by either doing:
> r10k -> ffv1 -> r10k -> ffv1 ->r10k
> and comparing the two ffv1 and the last two r10k files.
> You could also reencode to r210 and compare.
> And you can of course use -pix_fmt gbrp10 -f framecrc to 
> get identical output (but this means you trust my fix for 
> the gbrp10 conversion).
> 
> Carl Eugen
> 
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user