[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!

Pb


More information about the ffmpeg-devel mailing list