theora dev - Dec 2004 - frame_height, height, y_height etc...

I'd previously been working on the assumption that the frame_height was the 
height of the inner picture region... and height was the height of the outer 
frame.

Then upon readnig the spec... where it calls the outer part the frame and 
the inner part the picture region... i assumed i'd made a mistake and that 
frame_width is actually >= width in the theorainfo structure... ie 
frame_width is the size of the frame and width is the size of the picture 
inside the frame.

So now i'm completely confused.

Could someone please clarify if the following is correct...

theorainfo.frame_width  = width of the inner picture region
theorainfo.width = width of the outer frame
yuvbuffer.y_stride = theorainfo.width = width of the outer frame
yuvbuffer.y_width = theorainfo.frame_width = width of the inner picture 
region

???


Cheers,

Zen.

Actually... let me try again... this is my current understanding...

 //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

 //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)


----- Original Message ----- 
From: "illiminable" <ogg@illiminable.com>
To: <theora-dev@xiph.org>
Sent: Monday, December 20, 2004 8:00 PM
Subject: [Theora-dev] frame_height, height, y_height etc...

> I'd previously been working on the assumption that the frame_height was
> the height of the inner picture region... and height was the height of the 
> outer frame.
>
> Then upon readnig the spec... where it calls the outer part the frame and 
> the inner part the picture region... i assumed i'd made a mistake and
that
> frame_width is actually >= width in the theorainfo structure... ie 
> frame_width is the size of the frame and width is the size of the picture 
> inside the frame.
>
> So now i'm completely confused.
>
> Could someone please clarify if the following is correct...
>
> theorainfo.frame_width  = width of the inner picture region
> theorainfo.width = width of the outer frame
> yuvbuffer.y_stride = theorainfo.width = width of the outer frame
> yuvbuffer.y_width = theorainfo.frame_width = width of the inner picture 
> region
>
> ???
>
>
> Cheers,
>
> Zen.
>
> _______________________________________________
> Theora-dev mailing list
> Theora-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/theora-dev
>
>
>

salsaman wrote:
> Allowing the stride to be < width is very very dangerous. For example, 
> some players/editors may allocate memory as height*stride; this could 
> cause a buffer overflow when reading in a complete frame (e.g. on the 
> last row, if width bytes are written). A good editor will therefore 
> reject any files with rowstride < width.
I'm just talking about on the (experimental) encoder side, where the 
application is the one that fills in the stride values. The decoder 
(both experimental and baseline) will never return a stride whose 
magnitude is less than the width (in fact it will always be greater). 
You might have to take an absolute value to get the magnitude, since the 
baseline decoder returns a negative stride. In general, though, I would 
expect players/editors to allocate height*width blocks of memory, and 
perform copies row by row.

Allowing a stride smaller than the width on input allows an application 
to "virtually" pad the image by adjusting the pointers and the width
and
height, while still referring to a block of memory that is only the size 
of the picture region, not the entire frame. This lets the application 
avoid a copy if its data source hands it unpadded frames.

To emphasize, this only works in the experimental encoder. The baseline 
encoder _will_ try to reference pixels outside the picture region if it 
is smaller than the whole frame, and if those pixels do not lie inside 
the allocated block of frame data, this could case segfaults (or at best 
the encoding of garbage data, which requires lots of bits).