Talk:OggYUV - Revision history

Arc: /* Aspect ratio */

2005-11-13T08:23:57Z

Aspect ratio

← Older revision		Revision as of 08:23, 13 November 2005
Line 40:		Line 40:
	or a default value of 1 : 1 MAY be used.		or a default value of 1 : 1 MAY be used.
	--[[User:J^\|J^]] 13:42, 11 Nov 2005 (PST)		--[[User:J^\|J^]] 13:42, 11 Nov 2005 (PST)
		+
		+	* Sorry, my mistake or typo. Thanks for pointing this out. :-)

	=== Chroma Subsampling Methods ===		=== Chroma Subsampling Methods ===

J^: /* Aspect ratio */

2005-11-11T21:42:28Z

Aspect ratio

← Older revision		Revision as of 21:42, 11 November 2005
Line 30:		Line 30:
	--[[User:Arc\|Arc]] 10:42, 9 Nov 2005 (PST)		--[[User:Arc\|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, deﬁned 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 ﬁelds are zero, this indicates
		+	that pixel aspect ratio information was not available to the encoder. In
		+	this case it MAY be speciﬁed by the application via an external means,
		+	or a default value of 1 : 1 MAY be used.
		+	--[[User:J^\|J^]] 13:42, 11 Nov 2005 (PST)

	=== Chroma Subsampling Methods ===		=== Chroma Subsampling Methods ===

Jkoleszar: /* Chroma Subsampling Methods */

2005-11-10T19:09:54Z

Chroma Subsampling Methods

← Older revision		Revision as of 19:09, 10 November 2005
Line 79:		Line 79:
	: 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.		: 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)		--[[User:Gumboot\|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
		+	--[[User:Jkoleszar\|Jkoleszar]] 11:09, 10 Nov 2005 (PST)

Gumboot: /* Chroma Subsampling Methods */

2005-11-10T10:58:03Z

Chroma Subsampling Methods

← Older revision		Revision as of 10:58, 10 November 2005
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)

Arc: /* Chroma Subsampling Methods */

2005-11-10T05:30:20Z

Chroma Subsampling Methods

← Older revision		Revision as of 05:30, 10 November 2005
Line 32:		Line 32:

	=== Chroma Subsampling Methods ===		=== Chroma Subsampling Methods ===
-	~~# There are less than 32 possible methods for~~ chroma ~~subsampling within a 4x2 block~~, it'd be ~~fairly simple to simply put these into a table and refer to them~~ by ~~index~~# ~~<br>~~--~~[[User~~:~~Arc\|Arc]] 19~~:~~36, 9 Nov 2005 (PST)~~	+	* 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 method seems a bit.. non~~-~~optimal, and also doesn't define how those samples are mapped to neighboring pixels~~.~~<br>~~--~~[[User~~:~~Arc\|Arc]] 19~~:~~36, 9 Nov 2005 (PST)~~	+	** This seperates the order of the data and the processing of the data, both of which are important but get very complicated if mixed
-	# ~~U and V can be defined seperatly, with more patterns specified~~. ~~These patterns are listed below~~. --~~[[User~~:~~Arc\|Arc]] 19~~:36, ~~9 Nov 2005 (PST)~~	+	** 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

Arc at 03:36, 10 November 2005

2005-11-10T03:36:36Z

← Older revision		Revision as of 03:36, 10 November 2005
Line 29:		Line 29:
	* 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.		* 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.
	--[[User:Arc\|Arc]] 10:42, 9 Nov 2005 (PST)		--[[User:Arc\|Arc]] 10:42, 9 Nov 2005 (PST)
		+
		+
		+	=== Chroma Subsampling Methods ===
		+	# There are less than 32 possible methods for chroma subsampling within a 4x2 block, it'd be fairly simple to simply put these into a table and refer to them by index# <br>--[[User:Arc\|Arc]] 19:36, 9 Nov 2005 (PST)
		+	#* This method seems a bit.. non-optimal, and also doesn't define how those samples are mapped to neighboring pixels.<br>--[[User:Arc\|Arc]] 19:36, 9 Nov 2005 (PST)
		+	# U and V can be defined seperatly, with more patterns specified. These patterns are listed below. --[[User:Arc\|Arc]] 19:36, 9 Nov 2005 (PST)

Arc: syntax unification, comments as list items, followed by sig on newline

2005-11-09T21:17:41Z

syntax unification, comments as list items, followed by sig on newline

← Older revision		Revision as of 21:17, 9 November 2005
Line 1:		Line 1:
	=== Interlace Flag? ===		=== 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? --[[User:Gumboot\|Gumboot]] 03:00, 9 Nov 2005 (PST)	+	* 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?
		+	--[[User:Gumboot\|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? --[[User:Arc\|Arc]] 10:42, 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?
		+	--[[User:Arc\|Arc]] 10:42, 9 Nov 2005 (PST)


	=== Variable frame-rates ===		=== 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.	+	* There doesn't seem to be any handling of variable frame-rate data, or a specification for a timebase for the granulepos.
	--[[User:Gumboot\|Gumboot]] 03:00, 9 Nov 2005 (PST)		--[[User:Gumboot\|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? --[[User:Arc\|Arc]] 10:42, 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?
		+	--[[User:Arc\|Arc]] 10:42, 9 Nov 2005 (PST)


	=== Codec Identifier ===		=== Codec Identifier ===
-	The identifier seems a little short. You'd get false positives if somebody wanted to use a "YUVx" format, for example. --[[User:Gumboot\|Gumboot]] 03:00, 9 Nov 2005 (PST)	+	* The identifier seems a little short. You'd get false positives if somebody wanted to use a "YUVx" format, for example.
		+	--[[User:Gumboot\|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. --[[User:Arc\|Arc]] 10:42, 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.
		+	--[[User:Arc\|Arc]] 10:42, 9 Nov 2005 (PST)


	=== Aspect ratio ===		=== Aspect ratio ===
-	Is the aspect ratio the pixel aspect or the frame aspect? --[[User:Gumboot\|Gumboot]] 03:00, 9 Nov 2005 (PST)	+	* Is the aspect ratio the pixel aspect or the frame aspect?
		+	--[[User:Gumboot\|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. --[[User:Arc\|Arc]] 10:42, 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.
		+	--[[User:Arc\|Arc]] 10:42, 9 Nov 2005 (PST)

Arc at 18:42, 9 November 2005

2005-11-09T18:42:59Z

← Older revision		Revision as of 18:42, 9 November 2005
Line 1:		Line 1:
-	* 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?	+	=== Interlace Flag? ===
-	* There doesn't seem to be any handling of variable frame-rate data, or a specification for a timebase for the granulepos.	+	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? --[[User:Gumboot\|Gumboot]] 03:00, 9 Nov 2005 (PST)
-	* The identifier seems a little short. You'd get false positives if somebody wanted to use a "YUVx" format, for example.	+
-	* Is the aspect ratio the pixel aspect or the frame aspect? --[[User:Gumboot\|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? --[[User:Arc\|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.
		+	--[[User:Gumboot\|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? --[[User:Arc\|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. --[[User:Gumboot\|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. --[[User:Arc\|Arc]] 10:42, 9 Nov 2005 (PST)
		+
		+
		+	=== Aspect ratio ===
		+	Is the aspect ratio the pixel aspect or the frame aspect? --[[User:Gumboot\|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. --[[User:Arc\|Arc]] 10:42, 9 Nov 2005 (PST)

Gumboot at 11:00, 9 November 2005

2005-11-09T11:00:00Z

New page

* 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?
* There doesn't seem to be any handling of variable frame-rate data, or a specification for a timebase for the granulepos.
* The identifier seems a little short. You'd get false positives if somebody wanted to use a "YUVx" format, for example.
* Is the aspect ratio the pixel aspect or the frame aspect? --[[User:Gumboot|Gumboot]] 03:00, 9 Nov 2005 (PST)