Difference between revisions of "Oggless"

From XiphWiki
Jump to: navigation, search
m (format codec identifer table and parsing list so a human can read them)
m (sections and bold text)
Line 1: Line 1:
 
The text below is supposed to be a startpoint for disscussions and is ATM identical to [http://svn.mplayerhq.hu/nut.merged/docs/oggless-xiph-codecs.txt?view=log]
 
The text below is supposed to be a startpoint for disscussions and is ATM identical to [http://svn.mplayerhq.hu/nut.merged/docs/oggless-xiph-codecs.txt?view=log]
  
Ill make the formatting look more sane later today
+
'''Title'''     
 +
Embedding xiph codecs like vorbis in containers other then ogg
  
Title      Embedding xiph codecs like vorbis in containers other then ogg
+
'''Version'''   
 +
2006-07-30 (draft)
  
Version    2006-07-30 (draft)
+
'''Status'''      
 
+
this is not a standard or otherwise accepted by xiph or any other
Status      this is not a standard or otherwise accepted by xiph or any other
+
 
group, one day when we have a fully working implementation, did
 
group, one day when we have a fully working implementation, did
 
enough testing and so on we might submit it to IETF? to become an
 
enough testing and so on we might submit it to IETF? to become an
Line 16: Line 17:
 
other then their own?
 
other then their own?
  
Author     Michael Niedermayer (michaelni at gmx dot at)
+
'''Author'''
 +
Michael Niedermayer (michaelni at gmx dot at)
  
License     GPL + GFDL + anything neeeded to turn this into a open standard
+
'''License'''
like a RFC
+
GPL + GFDL + anything neeeded to turn this into a open standard like a RFC
  
 
Minimum container requirments:
 
Minimum container requirments:
Line 30: Line 32:
  
 
FIXME non vorbis
 
FIXME non vorbis
Global header:
+
===Global header:===
 
If the container can store 3 headers per stream in an unambiguos and ordered
 
If the container can store 3 headers per stream in an unambiguos 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
Line 52: Line 54:
  
  
Storing packets:
+
===Storing packets:===
 
Each codec packet shall be stored in exactly one "container packet"
 
Each codec packet shall be stored in exactly one "container packet"
 
and one "container packet" must not contain more then one codec packet
 
and one "container packet" must not contain more then one codec packet
Line 59: Line 61:
  
  
Codec Identifer:
+
===Codec Identifer:===
 
{|
 
{|
 
! xiph-codec
 
! xiph-codec
Line 93: Line 95:
  
  
Examples and Disscussions about specific containers
+
===Examples and Disscussions 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 99: Line 101:
  
  
Example and Disscussion of the avi container
+
====Example and Disscussion 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 118: Line 120:
  
  
Example and Disscussion of the asf container
+
====Example and Disscussion 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 125: Line 127:
  
  
Example and Disscussion of the matroska container
+
====Example and Disscussion 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 132: Line 134:
  
  
Example and Disscussion of the nut container
+
====Example and Disscussion 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 138: Line 140:
  
  
Example and Disscussion of mpeg-ps / mpeg-ts container
+
====Example and Disscussion 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 144: Line 146:
  
  
Example and Disscussion of wav container
+
====Example and Disscussion of wav container====
 
wav does not provide the neccessary packet separation / framing, so storing  
 
wav does not provide the neccessary 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 Disscussion of the mov container
+
====Example and Disscussion 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:38, 22 May 2007

The text below is supposed to be a startpoint for disscussions and is ATM identical to [1]

Title Embedding xiph codecs like vorbis in containers other then ogg

Version 2006-07-30 (draft)

Status this is not a standard or otherwise accepted by xiph or any other group, one day when we have a fully working implementation, did enough testing and so on we might submit it to IETF? to become an RFC ... furthermore this document has been submitted to vorbis-dev and so far has been ignored, maybe they where too busy maybe xiph wants to prevent their open codecs from being used in containers other then their own?

Author Michael Niedermayer (michaelni at gmx dot at)

License GPL + GFDL + anything neeeded to turn this into a open standard like a RFC

Minimum container requirments: 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

Global header:

If the container can store 3 headers per stream in an unambiguos 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 occurance of 01,'v','o','r','b','i','s' the found match and the following 23 bytes are the 1st header packet
2) search for the 1st occurance of 03,'v','o','r','b','i','s' 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 occurance of 05,'v','o','r','b','i','s' after here the matching part and what follows is the 3rd header packet

if the container needs an identifer 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 Identifer:

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 identifer from the table above shall be used if the container uses arbitrary length strings as identifers then the long id from the table above shall be used


Examples and Disscussions 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 Disscussion 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 beautifull 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 Disscussion 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 Disscussion 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 Disscussion 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 Disscussion 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 Disscussion of wav container

wav does not provide the neccessary packet separation / framing, so storing xiph codecs in it is outside the scope of this appendix


Example and Disscussion of the mov container

a single glbl atom shall be placed in the stsd atom in which the the global header shall be stored