[Theora-dev] frame_height, height, y_height etc...

[Timothy B. Terriberry]

illiminable wrote:

In the spec, I use the metaphor that there is a "picture" region 
surrounded by a "picture frame"... so the width of the frame can be 
larger than the picture itself. Unfortunately, the API has not been 
updated since then, and the original variable names for the picture 
region were frame_width and frame_height. When we clean up the API for 
the beta, this should be fixed.

> //mTheoraInfo values
> //==================
> //width, height     - /16 up rounded values, size of the outer frame
> //frame_width, frame_height  - size of the inner picture region
> //offset_x      - Distance at bottom left from outer frame to inner 
> picture <= width - frame_width
> //offset_y      - Distance at bottom left from outer frame to inner 
> picture <= height - frame_height

offset_x and offset_y are in addition restricted to be 255 or less 
(because there's only 8 bits allocated for them in the header). 
Otherwise, this is all correct.

> //mYUV values
> //=============================
> //y_stride      - Equal to the /16 up rounded wdith values
> //y_width      - Equal to the /16 up rounded wdith values
> //uv_stride      - Equal to *half* the /16 up rounded width values
> //uv_width      - Equal to *half* the /16 up rounded wdith values
> //y_height      - Equal to the /16 up rounded height value
> //uv_height      - Equal to *half* the /16 up rounded height value
> //y        - Buffer of size y_stride*y_height (/16 up rounded values)
> //u,v       - Buffers each *quarter* the size of the y buffer (/16 up 
> rounded values)

In general, the stride does _not_ have to equal the width. It can be 
larger, it can be negative (and with the experimental encoder it can 
even be _smaller_ without problems, so long as its magnitude is at least 
the picture width; this is _not_ true of the baseline encoder). It is 
just the number to add to the pointers to reach the next row of data.