[FFmpeg-user] AVFrame, AV_NUM_DATA_POINTERS

[Mark Filipak (ffmpeg)]

On 09/27/2020 03:31 PM, James Darnley wrote:
> On 27/09/2020, Mark Filipak (ffmpeg) <markfilipak at bog.us> wrote:
>>   From https://www.ffmpeg.org/doxygen/trunk/frame_8h_source.html#l00309
>> typedef struct AVFrame {
>> #define AV_NUM_DATA_POINTERS 8
>> /**
>> * pointer to the picture/channel planes.
>> * This might be different from the first allocated byte
>> *
>> * Some decoders access areas outside 0,0 - width,height...
>>
>> 1, Are samples & lines actually indexed from zero? I ask because, if so,
>> then shouldn't the extents
>> should be 0,0 - (width-1),(height-1)? -- the descrepancy makes me unsure how
>> to interpret what I read.
> 
> Yes, from 0.  Everything in C is indexed from 0 because they are
> pointer offsets.  Maybe that document should say what you suggest.

Thanks, James.

>> 2, Are the width & height indexes in bytes or samples? If bytes, how are
>> 8-bit v. 10-bit v. 12-bit
>> pixel formats handled at the index generation end?
> 
> Width and height are given in pixels.  How that relates to bytes in
> memory depends on the pixel format.  Different planes can have
> different sizes like in the extremely common yuv420p.

Ah-ha #1. I think you've answered another question. The planes that ffmpeg refers to are the Y, Cb, 
and Cr samples, is that correct?

So, I'm going to make some statements that can be confirmed or refuted -- making statements rather 
than asking questions is just part of my training, not arrogance. Statements are usually clearer. 
I'm trying to nail down the structures for integration into my glossary.

For YCbCr420, 8-bit, 720x576 (for example), the planes are separate and the structures are:
Y: 2-dimensional, 720x576 byte array.
Cb: 2-dimensional, 180x144 byte array.
Cr: 2-dimensional, 180x144 byte array.
Specifically, the decoder's output is not in macroblock format, correct? The reason I ask for 
confirmation is that H.262 implies that even raw pictures are in macroblock format, improbable as 
that may seem.

>  Byte order
> (endianess) of larger samples depends on the pixel format (but it is
> usually native).  The number of bytes used for a sample is given in
> the pixel format.  The bits are in the low N bits.

Ah-ha #2. I think you've answered yet another question: The arrays are bytes, not bits, correct? So, 
going from 8-bit samples to 10-bit samples doubles the sizes of the arrays, correct?

Thanks so much, James. Warm regards,
Mark.

-- 
The U.S. political problem? Amateurs are doing the street fighting.
The Princeps Senatus and the Tribunus Plebis need their own armies.