[NUT-devel] Re: [Vorbis-dev] minor Vorbis specification amendment proposal

[Michael Niedermayer]

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