Talk:OggYUV

Interlace Flag?

• The interlacing information doesn't seem complete to me. How do you know which field(s) you have in any give packet, for example? How do you distinguish between a 25Hz shutter and a 50Hz shutter? Field order switching? Mixing with uninterlaced data?

--Gumboot 03:00, 9 Nov 2005 (PST)

• In my experience, all interlace is every other frame, even scanlines followed by odd scanlines. Is there any video codec which supports more than an interlace flag?

--Arc 10:42, 9 Nov 2005 (PST)

Variable frame-rates

• There doesn't seem to be any handling of variable frame-rate data, or a specification for a timebase for the granulepos.

--Gumboot 03:00, 9 Nov 2005 (PST)

• Granulepos is the last frame decodable in the current packet/page. As far as variable framerates within a single stream, is there any codec which supports this currently?

--Arc 10:42, 9 Nov 2005 (PST)

Codec Identifier

• The identifier seems a little short. You'd get false positives if somebody wanted to use a "YUVx" format, for example.

--Gumboot 03:00, 9 Nov 2005 (PST)

• I believe that's OK with raw formats, if someone wanted to use a YUV-like codec they could use a prefix, vs a suffix, to identify it by. Also, if their header packet ID is something other than 0x00, it will not generate a false positive to have a YUV* codec identifier since the YUV plugins only support streams which begin with packet id 0.

--Arc 10:42, 9 Nov 2005 (PST)

Aspect ratio

• Is the aspect ratio the pixel aspect or the frame aspect?

--Gumboot 03:00, 9 Nov 2005 (PST)

• Frame aspect, this acts exactly like the aspect ratio in the Theora header, right down to having the same bit-size for the fields. Typically, the ratio is 4:3 or 16:9.

--Arc 10:42, 9 Nov 2005 (PST)

• Arc, Theora uses pixel aspect ratio, from the spec:

 13. Read a 24-bit unsigned integer as PARN.
 14. Read a 24-bit unsigned integer as PARD. Together with PARN, these
     specify the aspect ratio of the pixels within a frame, defined as the ratio
     of the physical width of a pixel to its physical height. This is given by
     the ratio PARN : PARD. If either of these fields are zero, this indicates
     that pixel aspect ratio information was not available to the encoder. In
     this case it MAY be specified by the application via an external means,
     or a default value of 1 : 1 MAY be used.

--J^ 13:42, 11 Nov 2005 (PST)

• Sorry, my mistake or typo. Thanks for pointing this out. :-)

Chroma Subsampling Methods

• We need to know two things, what the size/shape of chroma pixels are, and if they are packed, what order they are provided in the bitstream.
  • This seperates the order of the data and the processing of the data, both of which are important but get very complicated if mixed
  • The order must match the shape it's based on, ie, 4:4:4 should be in "0:0" order, any other value (which is illegal) should not be supported by any software if encountered and should never be generated.

Chroma Pixel "Shapes"
=====================
ID  Shape  Used-In
 0  #---   4:4:4
    ----
    ----
    ----
 .
 1  ##--   4:2:2
    ----
    ---- 
    ----
 .
 2  ####   4:1:1
    ----
    ----
    ----
 .
 3  #---   ?
    #---
    ----
    ----
 .
 4  ##--   4:2:0
    ##--
    ----
    ----
 .
 5  ####   4:1:0
    ####
    ----
    ----
 .
 6  ####   ?
    ####
    ####
    ####
 .
 7  Extended Shape, unsupported in v1.0

• In things like 420 you also need to know the relative phase of the sampling of the chroma. Some standards have it as being sampled exactly on the top left, some halfway across the top row, some halfway down the left edge, some in the centre of everything... then there are all the interlaced variants.

You also have the matter of whether or not there are unused areas at the top and bottom of the range of legal values, and many other things along those lines.

--Gumboot 02:58, 10 Nov 2005 (PST)

I'm a little confused about the x:y:z notation, so I'm not going to use that here. But here are a couple formats that aren't described in this table that I use. Dash (-) indicates a luma sample without a chroma sample, and # indicates a luma and chroma sample, I'm not sure if this is the same as used above or not..

 ####
 ####   Luma and Chroma sampled at at every pixel.
 ####
 ####
.
 ----     #-#-
 #-#- and ----    Typically sampled with a phase offset, but ignoring that for now. One   
 ----     #-#-    chroma sample per two luma horizontally, every other row. 
 #-#-     ----
.
 #-#- 
 #-#-     One chroma sample per two luma horizontally, every row.  
 #-#-     
 #-#- 
.
 There may be variants of #-#- (eg -#-#, maybe even -##- or #--#) out there too

--Jkoleszar 11:09, 10 Nov 2005 (PST)