# HG changeset patch # User michael # Date 1154250781 0 # Node ID d0a35cfca783673f1c33a0e6103b752dce4194d7 # Parent 9757c44cae9a7475d5e5c977b794d188e80a9a14 alex didnt commit his (very incomplete) rfc conversion of my proposal so i commit mine here dont hesitate to fix typos, do rewordimg and so on for controversial changes please disscuss at nut-devel@mphq first diff -r 9757c44cae9a -r d0a35cfca783 DOCS/tech/oggless-xiph-codecs.txt --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/DOCS/tech/oggless-xiph-codecs.txt Sun Jul 30 09:13:01 2006 +0000 @@ -0,0 +1,127 @@ +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 seperate 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 seperator 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 seperateable 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 seperation / 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 seperation / 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