[Theora-dev] frame_height, height, y_height etc...
Timothy B. Terriberry
tterribe at vt.edu
Tue Dec 21 10:39:08 PST 2004
> 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).
More information about the Theora-dev