[theora-dev] Changes to Ogg format IETF I-D

[Dan Miller]

(truly my last HTML post) -- thanks to Silvia and all who were involved in this effort.  It's a good karma thing.

        -----Original Message----- 
        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 
        Cc: 
        Subject: [theora-dev] Changes to Ogg format IETF I-D
        
        

        Howdy,
        
        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!
        
        Cheers,
        
        Silvia.
        
        
        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/ ?
        DONE.
        
        
        5) Section 6.4 (Suggestion by Raph Giles):
                 s/It's/Its/
        DONE.
        
        
        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
        Parker):
        
        < 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...
Name: winmail.dat
Type: application/ms-tnef
Size: 7582 bytes
Desc: winmail.dat
Url : http://lists.xiph.org/pipermail/theora-dev/attachments/20030214/1c721d10/winmail-0001.bin