Hi Vorbis has 3 "global" header packets, while generic containers generally have only a single global header per stream my proposal to solve this, would be to add a few lines to the vorbis specification to clarify how to convert between the 3 headers and the single header needed for non ogg containers currently (without any standarized way) various groups simply use their own self-invented method to store vorbis in non ogg and consequently either merge the 3 headers as they see fit or just dump them into the file like normal packets leading to problems with random access (seeking) ... all that leads to many problems and incompatibilites Proposed amendment------------ To split a global header from a non ogg container: 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 To convert the 3 header packets to a single one for storege in a non ogg container, simple concatenate the 3 header packets without anything before, after or between them ------------------------------- the proposed spliting method will work with pretty much any way the packets can be merged, it will specifically work with 1. simple concatenation 2. the format in matroska (2<p1 size><p2 size><p1><p2><p3>, sizes stored like packet sizes in ogg) 3. 16/32bit size for packet 0, packet 0, 16/32bit size for packet 1, ... 4. 16bit size for packet 0, 16bit size for packet 1, ..., packet 0, ... 5. 16/32bit size for packet 0, 16/32bit size for packet 1, packet 0, ... one format it could fail with is if the 3 32bit sizes are put infront of the 3 packets, though that would require the packets to be large (giga bytes) for it to fail -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In the past you could go to a library and read, borrow or copy any book Today you'd get arrested for mere telling someone where the library is
On Thu, Jul 20, 2006 at 03:56:48PM +0200, Michael Niedermayer wrote:
Vorbis has 3 "global" header packets, while generic containers generally have only a single global header per stream
I think this is a useful idea, but giving specific parse rules to try on *any* container format seems unwise. I'd rather see an appendix documenting a standard embedding proceedure for various other containers, and perhaps some guidelines for creating new mappings including the parsability information you included. Would you be willing to write up and contribute something like that? -r
Hi On Thu, Jul 20, 2006 at 09:26:24AM -0700, Ralph Giles wrote:
On Thu, Jul 20, 2006 at 03:56:48PM +0200, Michael Niedermayer wrote:
Vorbis has 3 "global" header packets, while generic containers generally have only a single global header per stream
I think this is a useful idea, but giving specific parse rules to try on *any* container format seems unwise.
the suggestion was only for containers which support exactly one global header, for them i see no problem, maybe you could elaborate on what you think is unwise?
I'd rather see an appendix documenting a standard embedding proceedure for various other containers, and perhaps some guidelines for creating new mappings including the parsability information you included.
Would you be willing to write up and contribute something like that?
sure, what else over what i already proposed would be needed? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In the past you could go to a library and read, borrow or copy any book Today you'd get arrested for mere telling someone where the library is
On Thu, Jul 20, 2006 at 08:58:41PM +0200, Michael Niedermayer wrote:
Hi
On Thu, Jul 20, 2006 at 09:26:24AM -0700, Ralph Giles wrote:
On Thu, Jul 20, 2006 at 03:56:48PM +0200, Michael Niedermayer wrote:
Vorbis has 3 "global" header packets, while generic containers generally have only a single global header per stream
I think this is a useful idea, but giving specific parse rules to try on *any* container format seems unwise.
the suggestion was only for containers which support exactly one global header, for them i see no problem, maybe you could elaborate on what you think is unwise?
.....
I'd rather see an appendix documenting a standard embedding proceedure for various other containers, and perhaps some guidelines for creating new mappings including the parsability information you included.
Would you be willing to write up and contribute something like that?
sure, what else over what i already proposed would be needed?
imo you should make it clear that this amendment is in regard to how a decoder implementation should parse a single-block header packet received from a generic demuxer, not what every demuxer should do in order to specially-accommodate vorbis. not sure if they're clear on that matter or not. rich
Hi On Thu, Jul 20, 2006 at 08:58:41PM +0200, Michael Niedermayer wrote:
Hi
On Thu, Jul 20, 2006 at 09:26:24AM -0700, Ralph Giles wrote:
On Thu, Jul 20, 2006 at 03:56:48PM +0200, Michael Niedermayer wrote:
Vorbis has 3 "global" header packets, while generic containers generally have only a single global header per stream
I think this is a useful idea, but giving specific parse rules to try on *any* container format seems unwise.
the suggestion was only for containers which support exactly one global header, for them i see no problem, maybe you could elaborate on what you think is unwise?
I'd rather see an appendix documenting a standard embedding proceedure for various other containers, and perhaps some guidelines for creating new mappings including the parsability information you included.
Would you be willing to write up and contribute something like that?
sure, what else over what i already proposed would be needed?
/me looks around, lots of dead liveless corpses and no awnser ... what about the following: --------- Appendix XYZ embedding vorbis in containers other then ogg Version 2006-07-29 (draft) Author Michael Niedermayer (michaelni at gmx dot at) Minimum container requirments: This appendix only explains how to store vorbis in containers which support at least one global header per stream, can seperate individual vorbis packets and support variable bitrate and variable number of samples/packet Storage of vorbis in other containers is outside the scope of this appendix 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 vorbis 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 Storing packets: Each vorbis packet shall be stored in exactly one "container packet" and one "container packet" must not contain more then one vorbis packet "container packet" here means the smallest seperateable unit of data in the container Codec Identifer: if the container uses 4-character codes then "vrbs" shall be used as identifer if the container uses arbitrary length strings as identifers then "vorbis" shall be used as identifer 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 vorbis 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 vorbis-matroska 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 vorbis 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 vorbis 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 vorbis in it is outside the scope of this appendix Example and Disscussion of the mov container mov/quicktime lacks an unambigous place for a global header so its outside the scope of this appendix [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In the past you could go to a library and read, borrow or copy any book Today you'd get arrested for mere telling someone where the library is
Hi, I tried converting this appendix to an RFC. Also a plan is to make it more commonly appendable to all the Ogg codecs, thus it should be extended with FLAC, Theora and Speex descriptions. Both the XML source (I have used xml2rfc - xml.resource.org) and the converted txt is attached. I am curious about your comments. The rfc could have some rewording, style changes and bla bla. Also other reference bibliographic entries to the formats are needed. -- Alex Beregszaszi | alex@fsn.hu | +36 70 3144424
Hi On Sat, Jul 29, 2006 at 04:26:03PM +0200, Alex Beregszaszi wrote:
Hi,
I tried converting this appendix to an RFC. Also a plan is to make it more commonly appendable to all the Ogg codecs, thus it should be extended with FLAC, Theora and Speex descriptions.
Both the XML source (I have used xml2rfc - xml.resource.org) and the converted txt is attached. I am curious about your comments. The rfc could have some rewording, style changes and bla bla. Also other reference bibliographic entries to the formats are needed.
i like the idea, i also agree that theora, flac, ... should be added [...]
here * read an unsigned integer of 32 bits and skip that many bytes * [user_comment_list_length] = read an unsigned integer of 32 bits * iterate [user_comment_list_length] times { * read an unsigned integer of 32 bits and skip that many bytes * } * skip 1 byte
we should clarify the big/little endianness (IIRC it was little) for a little appendix in the messy vorbis spec it wouldnt have mattered but for a RFC IMHO it does ...
6. Storing packets
theres something missing here ... [...]
8.7. Quicktime / MPEG4
Quicktime lacks an unambigous place for a global header so its outside the scope of this document.
we could add mov to the list of supported containers if we define a chunk for the global header, other codecs have their own codec specific global header chunks too, maybe "glbl" could be used if its not taken yet, but i need to look more carefully at the mov/qt spec so we unambiguosly define and place it about .mp4, that wasnt covered by the quicktime/mov point, it has a ESDS atom into which a global header can be put, but iam not very familiar with the mpeg4-systems / iso-mp4 container specs so i didnt mention it PS: please svn commit it so we can work on it easier ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In the past you could go to a library and read, borrow or copy any book Today you'd get arrested for mere telling someone where the library is
Hi,
i like the idea, i also agree that theora, flac, ... should be added
What about CMML? It just sucks too :) http://wiki.xiph.org/index.php/CMML : * ident header packet (binary blob starting with CMML\0\0\0\0) * secondary header (xml, <?xml...) * data packet (xml, <clip...)
8.7. Quicktime / MPEG4
Quicktime lacks an unambigous place for a global header so its outside the scope of this document.
we could add mov to the list of supported containers if we define a chunk for the global header, other codecs have their own codec specific global header chunks too, maybe "glbl" could be used if its not taken yet, but i need to look more carefully at the mov/qt spec so we unambiguosly define and place it
glbl below trak? vmhd/mdhd/smhd/tkhd are leaf Will some Quicktime fanatic speak up? Mike?
about .mp4, that wasnt covered by the quicktime/mov point, it has a ESDS atom into which a global header can be put, but iam not very familiar with the mpeg4-systems / iso-mp4 container specs so i didnt mention it
That ESDS looks HUGE. -- Alex Beregszaszi | alex@fsn.hu | +36 70 3144424
Hi Alex Beregszaszi wrote:
[...]
Quicktime lacks an unambigous place for a global header so its outside the scope of this document. we could add mov to the list of supported containers if we define a chunk for the global header, other codecs have their own codec specific global header chunks too, maybe "glbl" could be used if its not taken yet, but i need to look more carefully at the mov/qt spec so we unambiguosly define and place it
glbl below trak? vmhd/mdhd/smhd/tkhd are leaf
Humm, IMHO best place is in stsd like every other codec. Decoder specific config atom like 'dvrb'. Is MOV fourcc for vorbis defined ? I can't find it anywhere. 'vrbs' would be nice.
Will some Quicktime fanatic speak up? Mike?
about .mp4, that wasnt covered by the quicktime/mov point, it has a ESDS atom into which a global header can be put, but iam not very familiar with the mpeg4-systems / iso-mp4 container specs so i didnt mention it
That ESDS looks HUGE.
MP4 specs would require it to be in stsd as 'mp4a' and object type set correctly in esds. It seems gpac already does it and uses a object type. That object type should be registered to mp4ra.org I think. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG S.A. http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
Hi On Sun, Jul 30, 2006 at 03:41:38AM +0200, Baptiste Coudurier wrote:
Hi
Alex Beregszaszi wrote:
[...]
Quicktime lacks an unambigous place for a global header so its outside the scope of this document. we could add mov to the list of supported containers if we define a chunk for the global header, other codecs have their own codec specific global header chunks too, maybe "glbl" could be used if its not taken yet, but i need to look more carefully at the mov/qt spec so we unambiguosly define and place it
glbl below trak? vmhd/mdhd/smhd/tkhd are leaf
Humm, IMHO best place is in stsd like every other codec. Decoder
yes
specific config atom like 'dvrb'. Is MOV fourcc for vorbis defined ? I can't find it anywhere. 'vrbs' would be nice.
my post to vorbis-dev/nut-dev contained vrbs and vorbis as 4-cc and n-cc identifers, not sure if they where lost in alexs rfc conversation ...
Will some Quicktime fanatic speak up? Mike?
about .mp4, that wasnt covered by the quicktime/mov point, it has a ESDS atom into which a global header can be put, but iam not very familiar with the mpeg4-systems / iso-mp4 container specs so i didnt mention it
That ESDS looks HUGE.
MP4 specs would require it to be in stsd as 'mp4a' and object type set correctly in esds. It seems gpac already does it and uses a object type. That object type should be registered to mp4ra.org I think.
and we of course should use the same method/id gpac uses if we mention .mp4 at all [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In the past you could go to a library and read, borrow or copy any book Today you'd get arrested for mere telling someone where the library is
Hi,
specific config atom like 'dvrb'. Is MOV fourcc for vorbis defined ? I can't find it anywhere. 'vrbs' would be nice.
my post to vorbis-dev/nut-dev contained vrbs and vorbis as 4-cc and n-cc identifers, not sure if they where lost in alexs rfc conversation
they were not "lost" -- Alex Beregszaszi | alex@fsn.hu | +36 70 3144424
Hi On Sat, Jul 29, 2006 at 11:57:53PM +0200, Alex Beregszaszi wrote:
Hi,
PS: please svn commit it so we can work on it easier ...
What about moving nut.txt from mplayer/DOCS/tech/ to nut/docs/ ?
either is fine for me (= i dont care in what directory nut.txt is as long as its not called alex_the_great/nut.txt or goatse/nut.txt or similar ;) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In the past you could go to a library and read, borrow or copy any book Today you'd get arrested for mere telling someone where the library is
Hi,
What about moving nut.txt from mplayer/DOCS/tech/ to nut/docs/ ?
either is fine for me (= i dont care in what directory nut.txt is as long as its not called alex_the_great/nut.txt or goatse/nut.txt or
Whats your problem? Its for having everything nut related in one place. -- Alex Beregszaszi | alex@fsn.hu | +36 70 3144424
participants (5)
-
Alex Beregszaszi -
Baptiste Coudurier -
Michael Niedermayer -
Ralph Giles -
Rich Felker