Oggless - Revision history

Saoshyant at 23:27, 15 February 2008

2008-02-15T23:27:58Z

← Older revision		Revision as of 23:27, 15 February 2008
Line 139:		Line 139:
	====Example and Discussion of the MOV container====		====Example and Discussion of the MOV container====
	A single glbl atom shall be placed in the stsd atom in which the the global header shall be stored.		A single glbl atom shall be placed in the stsd atom in which the the global header shall be stored.
		+
		+	[[Category:Drafts]]

DonDiego: typo

2008-02-05T10:05:11Z

typo

← Older revision		Revision as of 10:05, 5 February 2008
Line 73:		Line 73:
	\| tarkin		\| tarkin
	\|-		\|-
-	\| ~~Flac~~	+	\| FLAC
	\| flac		\| flac
	\| flac		\| flac

DonDiego: typo

2008-02-04T13:48:30Z

typo

← Older revision		Revision as of 13:48, 4 February 2008
Line 52:		Line 52:

	===Storing packets:===		===Storing packets:===
-	Each codec packet shall be stored in exactly one "container packet" and one "container packet" must not contain more then one codec packet. "container packet" here means the smallest ~~separatable~~ data unit in the container.	+	Each codec packet shall be stored in exactly one "container packet" and one "container packet" must not contain more then one codec packet. "container packet" here means the smallest separable data unit in the container.

DonDiego: spelling

2008-02-04T13:18:16Z

spelling

← Older revision		Revision as of 13:18, 4 February 2008
Line 57:		Line 57:
	===Codec Identifier:===		===Codec Identifier:===
	{\| border="1" cellpadding="4"		{\| border="1" cellpadding="4"
-	! ~~xiph-~~codec	+	! Xiph codec
-	! ~~4-cc id~~	+	! fourcc ID
-	! long id	+	! long ID
	\|-		\|-
	\| Vorbis		\| Vorbis
Line 83:		Line 83:
	\|}		\|}

-	If the container uses 4-character codes, the ~~4-cc~~ identifier from the table above shall be used. If the container uses arbitrary length strings as identifiers, then the long id from the table above shall be used.	+	If the container uses 4-character codes, the fourcc identifier from the table above shall be used. If the container uses arbitrary length strings as identifiers, then the long ID from the table above shall be used.

	===Examples and Discussions about specific containers===		===Examples and Discussions about specific containers===
Line 137:		Line 137:
	WAV does not provide the necessary packet separation / framing, so storing Xiph codecs in it is outside the scope of this appendix.		WAV does not provide the necessary packet separation / framing, so storing Xiph codecs in it is outside the scope of this appendix.

-	====Example and Discussion of the ~~Mov~~ container====	+	====Example and Discussion of the MOV container====
	A single glbl atom shall be placed in the stsd atom in which the the global header shall be stored.		A single glbl atom shall be placed in the stsd atom in which the the global header shall be stored.

DonDiego: Add borders and cellpadding to make tables more readable.

2008-02-04T13:13:40Z

Add borders and cellpadding to make tables more readable.

← Older revision		Revision as of 13:13, 4 February 2008
Line 28:		Line 28:

	====Constants:====		====Constants:====
-	{\|	+	{\| border="1" cellpadding="4"
	! Codec		! Codec
	! ID1		! ID1
Line 56:		Line 56:

	===Codec Identifier:===		===Codec Identifier:===
-	{\|	+	{\| border="1" cellpadding="4"
	! xiph-codec		! xiph-codec
	! 4-cc id		! 4-cc id

DonDiego: misc spelling/wording/punctuation fixes

2008-02-04T13:08:56Z

misc spelling/wording/punctuation fixes

← Older revision		Revision as of 13:08, 4 February 2008
Line 1:		Line 1:
	==Abstract==		==Abstract==
-	This page documents how to embed the different Xiph codecs like Vorbis or Theora in containers other than Ogg. It's still in the ~~drating~~ stage, and most of it was taken from a [http://svn.mplayerhq.hu/nut/docs/oggless-xiph-codecs.txt?revision=486&pathrev=577 version] that was previously a part of the NUT Subversion repository.	+	This page documents how to embed the different Xiph codecs like Vorbis or Theora in containers other than Ogg. It's still in the drafting stage, and most of it was taken from a [http://svn.mplayerhq.hu/nut/docs/oggless-xiph-codecs.txt?revision=486&pathrev=577 version] that was previously a part of the NUT Subversion repository.
	Said document was originally authored by Michael Niedermayer.		Said document was originally authored by Michael Niedermayer.

Line 7:		Line 7:

	==Status==		==Status==
-	~~Misses information~~ on how to convert losslessly from one format to another, as ~~well timestamping of~~ Ogg. Regardless, it is mostly finished and likely won't be ~~further~~ updated.	+	Information on how to convert losslessly from one format to another is missing, as is Ogg timestamping. Regardless, it is mostly finished and likely won't be updated further.

	==Minimum container requirements==		==Minimum container requirements==
	This appendix only explains how to store Xiph codecs in containers which		This appendix only explains how to store Xiph codecs in containers which
-	support at least one global header per stream, can separate individual codec packets and in principle support the codec~~, so~~ for example in the case of Vorbis that would be variable bitrate and variable number of samples/packet. Storage in other containers is outside the scope of this appendix.	+	support at least one global header per stream, can separate individual codec packets and in principle support the codec. So for example in the case of Vorbis, that would be variable bitrate and variable number of samples/packet. Storage in other containers is outside the scope of this appendix.

	===Global header:===		===Global header:===
-	If the container can store 3 headers per stream in an unambiguous and ordered way then they shall be stored in that way~~, if~~ OTOH the container is only capable ~~to store~~ a single global header then the 3 codec headers shall be concatenated without any additional header, footer or separator between them to recover the 3 headers from such a global header the following procedure shall be used:	+	If the container can store 3 headers per stream in an unambiguous and ordered way then they shall be stored in that way. If OTOH the container is only capable of storing a single global header, then the 3 codec headers shall be concatenated without any additional header, footer or separator between them. To recover the 3 headers from such a global header the following procedure shall be used:
-	: 1) ~~search~~ for the 1st occurrence of ID1 ~~the~~ found match and the following ID1_LEN bytes are the 1st header packet	+
		+	: 1) Search for the 1st occurrence of ID1. The found match and the following ID1_LEN bytes are the 1st header packet.
	: 2) search for the 1st occurrence of ID2 after here		: 2) search for the 1st occurrence of ID2 after here
	:: 3) read an unsigned integer of 32 bits and skip that many bytes		:: 3) read an unsigned integer of 32 bits and skip that many bytes
Line 24:		Line 25:
	:: 7) skip 1 byte		:: 7) skip 1 byte
	: 8) the match in 2) and what follows until here is the 2nd header packet		: 8) the match in 2) and what follows until here is the 2nd header packet
-	: 9) ~~search~~ for the 1st occurrence of ID3 after here ~~the~~ matching part and what follows is the 3rd header packet	+	: 9) Search for the 1st occurrence of ID3 after here. The matching part and what follows is the 3rd header packet.

	====Constants:====		====Constants:====
Line 47:		Line 48:
	\|}		\|}

-	If the container needs an identifier for the global header, for example a ~~4cc~~ for a global header chunk then glbl shall be used.	+	If the container needs an identifier for the global header, for example a fourcc for a global header chunk then glbl shall be used.


	===Storing packets:===		===Storing packets:===
-	Each codec packet shall be stored in exactly one "container packet" and one "container packet" must not contain more then one codec packet "container packet" here means the smallest separatable ~~unit of~~ data in the container.	+	Each codec packet shall be stored in exactly one "container packet" and one "container packet" must not contain more then one codec packet. "container packet" here means the smallest separatable data unit in the container.


Line 82:		Line 83:
	\|}		\|}

-	If the container uses 4-character codes 4-cc identifier from the table above shall be used if the container uses arbitrary length strings as identifiers, then the long id from the table above shall be used.	+	If the container uses 4-character codes, the 4-cc identifier from the table above shall be used. If the container uses arbitrary length strings as identifiers, then the long id from the table above shall be used.

	===Examples and Discussions about specific containers===		===Examples and Discussions about specific containers===
Line 89:		Line 90:

	====Example and Discussion of the AVI container====		====Example and Discussion of the AVI container====
-	AVI supports everything needed to store Vorbis, this does not mean that all ~~application~~ will support Vorbis in AVI, as Vorbis is rather different from other audio codecs commonly stored in AVI.	+	AVI supports everything needed to store Vorbis, this does not mean that all applications will support Vorbis in AVI, as Vorbis is rather different from other audio codecs commonly stored in AVI.

	AVI supports a single global header like WAV does, the 3 Vorbis headers		AVI supports a single global header like WAV does, the 3 Vorbis headers
Line 95:		Line 96:
	becomes problematic.		becomes problematic.

-	AVI does not have timestamps, but each chunk has a constant duration, while Vorbis packets can have one of 2 durations~~, if~~ now the AVI header is ~~setup so~~ that each AVI chunk has the same duration as the smaller duration of the 2 possibilities in Vorbis then simply inserting empty AVI chunks will allow every AVI chunk to have the correct duration~~, this~~ is of course not the most beautiful solution but it is the only way to keep things exact. Additionally, note that empty chunks have been used since ages in AVI to lengthen the duration of video chunks.	+	AVI does not have timestamps, but each chunk has a constant duration,
		+	while Vorbis packets can have one of 2 durations.
		+	If now the AVI header is set up in a way that each AVI chunk has the
		+	same duration as the smaller duration of the 2 possibilities in Vorbis,
		+	then simply inserting empty AVI chunks will allow every AVI chunk to
		+	have the correct duration.
		+	This is of course not the most beautiful solution but it is the only way
		+	to keep things exact.
		+	Additionally, note that empty chunks have been used since ages in AVI to
		+	lengthen the duration of video chunks.

	Some Links:		Some Links:
Line 108:		Line 118:

	====Example and Discussion of the Matroska container====		====Example and Discussion of the Matroska container====
-	Matroska supports storing 3 headers using a codec specific format~~, which~~ should be used for storing the 3 headers.	+	Matroska supports storing 3 headers using a codec-specific format.
		+	This should be used for storing the 3 headers.

	Note that the above procedure to split one header into 3 works with the		Note that the above procedure to split one header into 3 works with the
-	Vorbis-Matroska specific format too.	+	Vorbis-Matroska-specific format, too.

	====Example and Discussion of the NUT container====		====Example and Discussion of the NUT container====
	NUT supports a single global header per stream so the 1<->3 merge/split		NUT supports a single global header per stream so the 1<->3 merge/split
-	procedure above must be used~~, except~~ that ~~theres~~ nothing special with	+	procedure above must be used. Except that there is nothing special with
	storing Xiph codecs in NUT.		storing Xiph codecs in NUT.

	====Example and Discussion of MPEG-PS / MPEG-TS container====		====Example and Discussion of MPEG-PS / MPEG-TS container====
-	These containers neither support a global header nor provide the ~~neccessary~~ packet separation / framing~~, so storing~~ Xiph codecs in them is outside the scope of this appendix.	+	These containers neither support a global header nor do they provide
		+	the necessary packet separation / framing.
		+	Storing Xiph codecs in them is thus outside the scope of this appendix.

	====Example and Discussion of WAV container====		====Example and Discussion of WAV container====

DonDiego: Update link to original document with a stable URL, it will be removed from the HEAD revision of the NUT Subversion repository now that it has found a better place here.

2008-02-04T12:43:30Z

Update link to original document with a stable URL, it will be removed from the HEAD revision of the NUT Subversion repository now that it has found a better place here.

← Older revision		Revision as of 12:43, 4 February 2008
Line 1:		Line 1:
	==Abstract==		==Abstract==
-	This page documents how to embed the different Xiph codecs like Vorbis or Theora in containers other than Ogg. It's still in the drating stage, and most of it was taken from ~~the~~ [http://svn.mplayerhq.hu/nut/docs/oggless-xiph-codecs.txt?~~view~~=~~log~~&pathrev=577 ~~MPlayer SVN~~], authored by Michael Niedermayer.	+	This page documents how to embed the different Xiph codecs like Vorbis or Theora in containers other than Ogg. It's still in the drating stage, and most of it was taken from a [http://svn.mplayerhq.hu/nut/docs/oggless-xiph-codecs.txt?revision=486&pathrev=577 version] that was previously a part of the NUT Subversion repository.
		+	Said document was originally authored by Michael Niedermayer.

	==Current Version==		==Current Version==

Michaelni: Update link to prevent breakage when svn.mplayerhq txt is removed

2008-02-04T12:34:49Z

Update link to prevent breakage when svn.mplayerhq txt is removed

← Older revision		Revision as of 12:34, 4 February 2008
Line 1:		Line 1:
	==Abstract==		==Abstract==
-	This page documents how to embed the different Xiph codecs like Vorbis or Theora in containers other than Ogg. It's still in the drating stage, and most of it was taken from the [http://svn.mplayerhq.hu/nut/docs/oggless-xiph-codecs.txt?view=log MPlayer SVN], authored by Michael Niedermayer.	+	This page documents how to embed the different Xiph codecs like Vorbis or Theora in containers other than Ogg. It's still in the drating stage, and most of it was taken from the [http://svn.mplayerhq.hu/nut/docs/oggless-xiph-codecs.txt?view=log&pathrev=577 MPlayer SVN], authored by Michael Niedermayer.

	==Current Version==		==Current Version==

Saoshyant: /* Status */

2008-01-25T18:08:25Z

Status

← Older revision		Revision as of 18:08, 25 January 2008
Line 6:		Line 6:

	==Status==		==Status==
-	Misses information on how to convert losslessly from one format to another, as well timestamping of Ogg. Regardless, it is mostly finished and won't be ~~much updated~~ further.	+	Misses information on how to convert losslessly from one format to another, as well timestamping of Ogg. Regardless, it is mostly finished and likely won't be further updated.

	==Minimum container requirements==		==Minimum container requirements==

Saoshyant at 02:24, 21 July 2007

2007-07-21T02:24:32Z

Show changes