[theora-dev] Changes to Ogg format IETF I-D
dan at on2.com
Thu Feb 13 23:48:59 PST 2003
(truly my last HTML post) -- thanks to Silvia and all who were involved in this effort. It's a good karma thing.
From: Silvia.Pfeiffer at csiro.au [mailto:Silvia.Pfeiffer at csiro.au]
Sent: Fri 2/14/2003 2:22 AM
To: theora-dev at xiph.org; vorbis-dev at xiph.org; xiphmont at xiph.org
Subject: [theora-dev] Changes to Ogg format IETF I-D
yeah, I've finally collected all your feedback on my I-D on the Ogg
encapsulation format, many thanks to all of you! Below, I've listed the
changes that I have made to the previous version and the attachment
contains the complete new I-D. If there are any more change requests,
please send me wording proposals as it's easier to include. :)
Monty, in case you are doing any changes to Ogg Version 0, such as
specifying more clearly the granule_pos format or how the temporal
synchronisation between different concurrently multiplexed bitstreams
has to work, you'd better tell us now. The IETF has a closing data of
Monday, 3rd March for submission of I-Ds for their next meeting. At that
meeting they will move the Ogg file format I-D to RFC provided I submit
an update on time.
I really like this document now and I hear it's already being used as
reference for implementations. Good stuff!
Here's the list of changes:
1) Changed all of "capable to" into "able to" or "capable of" :
As Ralph Giles noted:
>> It is capable to interleave different binary...
>Is this an au-ism? 'capable of interleaving' is the usual phase in us
>english. The whole sentence is a little awkward, but I can't come up
>with anything better.
Sorry, I'm not a native speaker, therefore the german-ism :)
2) The main paragraph of trouble (the one that stopped it going forward
to RFC at the IETF) merged several feedbacks and changed to (Section 4):
< The bos page contains information to uniquely
< identify the codec type and MAY contain information to set up the
< decoding process. The bos page SHOULD also contain information about
< the encoded media - for example, for audio, it should contain sample
< rate and number of channels. By convention, the first bytes of the
< bos page contain magic data that uniquely identify the required
< codec. It is the responsibility of anyone fielding a new codec to
< make sure it is possible to reliably distinguish his/her codec from
< all other codecs in use. There is no fixed way to detect the end of
< the codec-identifying marker. The format of the bos page is
< dependent on the codec and therefore MUST be given in the
< encapsulation specification of that logical bitstream type. An
< example for such a media mapping is "Ogg Vorbis", which provides the
< name and revision of the Vorbis codec, the audio rate and the audio
< quality on the Ogg Vorbis bos page. It is identified by the string
< "vorbis" at the beginning of the bos.
3) The paragraph of constant trouble re Theora changed to using the word
"Theora" only for the video codec (Section 4):
< Another example is the upcoming "Ogg Theora"
< specification which encapsulates Theora-encoded video data and
< usually comes multiplexed with a Vorbis stream for an Ogg containing
< synchronised audio and video. As Ogg does not specify temporal
< relationships between the encapsulated concurrently multiplexed
< bitstreams, the temporal synchronisation between the audio and video
< stream will be specified in this media mapping.
4) Section 6.3 (Suggestion by Ralph Giles):
s/media frame/packet/ ?
5) Section 6.4 (Suggestion by Raph Giles):
6) Also in Section 6.4 I made the meaning of granule_pos less restricted
and included the "-1" meaning previously forgotten (thanks to Conrad
< For example, for an audio stream it MAY contain the total number
< of PCM samples encoded after including all frames finished on
< this page. For a video stream it MAY contain the total number of
< video frames encoded after this page.
< A special value of -1 (in
< two's complement) indicates that no packets finish on this page.
7) Added the word "unique" to the serial number in Section 6.5.
8) Updated the reference to the application/ogg MIME type I-D (this will
have to change again as soon as the RFC number is announced).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7582 bytes
Url : http://lists.xiph.org/pipermail/theora-dev/attachments/20030214/1c721d10/winmail-0001.bin
More information about the Theora-dev