Oggless: Difference between revisions
(theora support) |
Lovebug356 (talk | contribs) m (typo's) |
||
| Line 1: | Line 1: | ||
The text below is supposed to be a | The text below is supposed to be a start point for discussions and is ATM identical to [http://svn.mplayerhq.hu/nut/docs/oggless-xiph-codecs.txt?view=log] | ||
==Abstract== | ==Abstract== | ||
| Line 11: | Line 11: | ||
<!-- ==License== | <!-- ==License== | ||
GPL + GFDL + anything | GPL + GFDL + anything needed to turn this into a open standard like a RFC~ | ||
(License should not be stated yet, or it will be a mess to change later) --> | (License should not be stated yet, or it will be a mess to change later) --> | ||
==Minimum container | ==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 | support at least one global header per stream, can separate individual codec | ||
| Line 24: | Line 24: | ||
FIXME non vorbis/theora | FIXME non vorbis/theora | ||
===Global header:=== | ===Global header:=== | ||
If the container can store 3 headers per stream in an | 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 | 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 | capable to store a single global header then the 3 codec headers shall be | ||
| Line 30: | Line 30: | ||
to recover the 3 headers from such a global header the following procedure | to recover the 3 headers from such a global header the following procedure | ||
shall be used: | shall be used: | ||
: 1) search for the 1st | : 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 | : 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 | ||
:: 4) [user_comment_list_length] = read an unsigned integer of 32 bits | :: 4) [user_comment_list_length] = read an unsigned integer of 32 bits | ||
| Line 39: | Line 39: | ||
:: 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 | : 9) search for the 1st occurrence of ID3 after here the matching part and what follows is the 3rd header packet | ||
====Constants:==== | ====Constants:==== | ||
| Line 62: | Line 62: | ||
|} | |} | ||
if the container needs an | if the container needs an identifier for the global header, for example a 4cc | ||
for a global header chunk then glbl shall be used | for a global header chunk then glbl shall be used | ||
| Line 73: | Line 73: | ||
===Codec | ===Codec Identifier:=== | ||
{| | {| | ||
! xiph-codec | ! xiph-codec | ||
| Line 101: | Line 101: | ||
|} | |} | ||
if the container uses 4-character codes 4-cc | if the container uses 4-character codes 4-cc identifier from the table above | ||
shall be used | shall be used | ||
if the container uses arbitrary length strings as | if the container uses arbitrary length strings as identifiers then the long | ||
id from the table above shall be used | id from the table above shall be used | ||
===Examples and | ===Examples and Discussions about specific containers=== | ||
What follows are some notes about specific containers, these notes are just | What follows are some notes about specific containers, these notes are just | ||
informative as they just repeat what is written above or in the | informative as they just repeat what is written above or in the | ||
| Line 113: | Line 113: | ||
====Example and | ====Example and Discussion of the avi container==== | ||
avi supports everything needed to store vorbis, this does not mean that all | 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 | application will support vorbis in avi as vorbis is rather different from | ||
| Line 127: | Line 127: | ||
the 2 possibilities in vorbis then simply inserting empty avi chunks will | 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 | allow every avi chunk to have the correct duration, this is of course | ||
not the most | 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 | exact, additionally note, that empty chunks have been used since ages | ||
in avi to lengthen the duration of video chunks | in avi to lengthen the duration of video chunks | ||
====Example and | ====Example and Discussion of the asf container==== | ||
asf supports a single global header per stream and has timestamps so | asf supports a single global header per stream and has timestamps so | ||
storing xiph codecs in it should be possible but asf is patented and | storing xiph codecs in it should be possible but asf is patented and | ||
| Line 139: | Line 139: | ||
====Example and | ====Example and Discussion of the matroska container==== | ||
matroska supports storing 3 headers using a codec specific | matroska supports storing 3 headers using a codec specific | ||
format, which should be used for storing the 3 headers | format, which should be used for storing the 3 headers | ||
| Line 146: | Line 146: | ||
====Example and | ====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 theres nothing special with | ||
| Line 152: | Line 152: | ||
====Example and | ====Example and Discussion of mpeg-ps / mpeg-ts container==== | ||
These containers neither support a global header nor provide the neccessary | These containers neither support a global header nor provide the neccessary | ||
packet separation / framing, so storing xiph codecs in them is outside the | packet separation / framing, so storing xiph codecs in them is outside the | ||
| Line 158: | Line 158: | ||
====Example and | ====Example and Discussion of wav container==== | ||
wav does not provide the | wav does not provide the necessary packet separation / framing, so storing | ||
xiph codecs in it is outside the scope of this appendix | xiph codecs in it is outside the scope of this appendix | ||
====Example and | ====Example and Discussion of the mov container==== | ||
a single glbl atom shall be placed in the stsd atom in which the the global | a single glbl atom shall be placed in the stsd atom in which the the global | ||
header shall be stored | header shall be stored | ||
Revision as of 11:31, 28 May 2007
The text below is supposed to be a start point for discussions and is ATM identical to [1]
Abstract
Embedding xiph codecs like vorbis in containers other than ogg
Current Version
- 2007-05-23
Status
This is a proposal being discussed. It's currently not ready to be used on real-life situations.
Minimum container requirements
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
FIXME non vorbis/theora
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:
- 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
- 3) read an unsigned integer of 32 bits and skip that many bytes
- 4) [user_comment_list_length] = read an unsigned integer of 32 bits
- 5) iterate [user_comment_list_length] times {
- 6) read an unsigned integer of 32 bits and skip that many bytes
- }
- 7) skip 1 byte
- 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
Constants:
| Codec | ID1 | ID2 | ID3 | ID1_LEN |
|---|---|---|---|---|
| Vorbis | 0x01,'v','o','r','b','i','s' | 0x03,'v','o','r','b','i','s' | 0x05,'v','o','r','b','i','s' | 23 |
| Theora | 0x80,'t','h','e','o','r','a' | 0x81,'t','h','e','o','r','a' | 0x82,'t','h','e','o','r','a' | 35 |
if the container needs an identifier for the global header, for example a 4cc for a global header chunk then glbl shall be used
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
Codec Identifier:
| xiph-codec | 4-cc id | long id |
|---|---|---|
| Vorbis | vrbs | vorbis |
| Theora | ther | theora |
| Tarkin | trkn | tarkin |
| Flac | flac | flac |
| Speex | spex | speex |
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
Examples and Discussions about specific containers
What follows are some notes about specific containers, these notes are just informative as they just repeat what is written above or in the specification of the specific 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 a single global header like wav does, the 3 vorbis headers shall be stored in it and only in it as described above dwSampleSize must be set to zero as vorbis is vbr, many applications do this incorrectly for other vbr codecs and consequently vbr audio in avi 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
Example and Discussion of the asf container
asf supports a single global header per stream and has timestamps so storing xiph codecs in it should be possible but asf is patented and microsoft has already threatened individuals so we strongly urge you to avoid this 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 Note, the above procedure to split one header into 3 works with the vorbis-matroska specific format too
Example and Discussion of the nut container
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 storing xiph codecs in nut
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
Example and Discussion of wav container
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
a single glbl atom shall be placed in the stsd atom in which the the global header shall be stored