Talk:OggYUV: Difference between revisions
Jump to navigation
Jump to search
Line 75: | Line 75: | ||
. | . | ||
7 Extended Shape, unsupported in v1.0 | 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. | |||
--[[User:Gumboot|Gumboot]] 02:58, 10 Nov 2005 (PST) |
Revision as of 02:58, 10 November 2005
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)
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)