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

[Timothy B. Terriberry]

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