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

Peter B. pb at das-werkstatt.com
Wed Oct 17 09:56:48 CEST 2012

On 10/17/2012 08:41 AM, Reimar Döffinger wrote:
> 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...
Thank you very much for your explanation!


More information about the ffmpeg-devel mailing list