[FFmpeg-devel] evaluating the experimental status of ffv1 version 3

Reimar Döffinger Reimar.Doeffinger at gmx.de
Wed Oct 17 08:41:49 CEST 2012

On 4 Oct 2012, at 17:00, "Peter B." <pb at das-werkstatt.com> wrote:

> Quoting Reimar Döffinger <Reimar.Doeffinger at gmx.de>:
>> "Peter B." <pb at das-werkstatt.com> wrote:
>>> I must admit though, that I was surprised that both raw nut files have
>>> the identical filesize for yuv422p16le and yuv422p10le. Is that due to
>>> yuv422p10le being padded to 32bits?
>> 422p10 is the planar format, padding to 32 bits makes not much sense there, I suspect you confuse it with how 10 bit 422 packed is stored.
>> All > 8 bit planar formats use 16 bit per component with the highest bits 0.
> I must admit I'm not really 100% sure if I understand you correctly.
> It seems obvious that it's somehow necessary to store >8bit formats using 16bit and fill them up with 0 (that's what I meant with "padding"), which for uncompressed codecs would result in identical filesize with a full 16bit format then.
> However, I do assume that there's a benefit from even having pixel formats between 8 and 16 regarding the size - I just realized that obviously I don't exactly understand how that's handled.

As said, you can store them packed in interleaved format into a 32 bit int, but FFmpeg does not do that.
The other advantage is that intermediate results (e.g. during DCT) still fit into 16 bit.
For full 16 but you will often have to use 32 bit for the intermediates, so you cannot reuse even parts of the assembler optimized transforms for 8 bit and the speed will be about half even after writing new optimizations.
There are also other points, like that 10 and 9 bits are supported formats over DVI and HDMI but to my knowledge 16 bits is not, so having 10 bit in the first place can save you a transformation,

> Is there any good source of information where I could read up on the binary layout of different colorspaces, because I'd really like to understand this better!

No idea. Generally the probem is that someone somewhere probably uses any layout you can imagine, even if some are used much more than others...

More information about the ffmpeg-devel mailing list