theora dev - Apr 2004 - YUV Format

I posted this the other day... but it didn't get delivered...

-------------------------------------------------------------------
I'm getting stuck into a theora decoder for directshow... i was just
wondering if someone could give me some info.

What output format does theora use ?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwmt/html/YUVFormats.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/directx/htm/yuvvideosubtypes.asp

Heres the list i haev to work from... could someone tell me which of these it is
?

Best i can tell it's YUV12 ?

So can someone confirm the following... each component is 8 bits.

I have an array of y data.

and it is an array [0..y_height] of arrays [0..y_width]

ie... an array of horizontal lines ?

And the uv data is an array [0..uv_height] of arrays [0..uv_width*2]

where data goes
UVUVUVUVUVUV........ (width uv_width*2 or uv_width lots of UV)
UVUV.....
.
.
.
(uv_height lines)

Is this correct ? Or is the actual byte width of the UV lines actually uv_width
? ie one UV component is shared over the y components.

So if this is the yuv data from my file
Pack No  : 11
Y Width  : 352
Y Height : 288
Y Stride : -384
UV Width : 176
UV Height : 144
UV Stride : -192 

the memory allocated to the y buffer = 352 * 288
the memory allocated to the uv buffer = 176 * 2 * 144 or is it 176 * 144 ????

Thanks !

Zen.

<p><p><p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'theora-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

> Heres the list i haev to work from... could someone tell me which of 
> these it is ?
I have no idea if Microsoft has a specific code for it. The data is 
stored in a planar fashion. Video is stored in an 8-bit per channel 
Y'CbCr space. See doc/color.html for a precise specification of the 
color space used. The current library only uses 4:2:0 decimation 
(decimation of the chroma planes by 2 in both the horizontal and 
vertical direction). Each component, Y', Cb, and Cr, are in separate 
buffers, as suggested by the three separate pointers to them in struct 
yuv_buffer.

The horizontal stride in each buffer is always 1. So the contents of a 
single row are always contiguous in memory. The vertical stride in each 
buffer is NOT the width. So separate rows are NOT contiguous in memory. 
The y_stride and uv_stride variables tell you what to add to your 
pointer to get to the next row. The fact that there is only one value 
for the Cb and Cr planes indicates that each separate Cb and Cr buffer 
uses the same memory organization, NOT that they are stored in the same 
buffer. You will note that this value is negative in the buffers 
returned by the current library, indicating that each row after the top 
row actually comes BEFORE the top row in memory. There is no guarantee 
that libtheora will always do this.

Note also that libtheora may overwrite the contents of the buffer the 
next time you decode a frame. If either DirectShow does not have a way 
of describing the buffer layout given above or you need to keep data 
around for longer than a single frame decode cycle, you will need to 
copy the contents of the buffer somewhere else. You can then use 
whatever memory organization suits your fancy.
--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'theora-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.