[vorbis-dev] Re: Final Ogg 1.0 submission to IETF

[Silvia.Pfeiffer at csiro.au]

Dear Monty, all

thanks everybody for your help. Feedback on Monty's changes are 
interspersed below, though they came too late for my submission to the 
IETF. I've saved them in my local document copy and will include them 
when the document moves to the next stage, i.e. to be proofread by the 
RFC editor.

The submitted document will soon appear at 
http://www.ietf.org/internet-drafts/draft-pfeiffer-ogg-fileformat-02.txt 
It has applied the changes that I received from others, including 
spell-checking, extending the requirements list, and correcting the 
application/ogg MIME type paragraph.

Thanks again to everyone for their involvement!

Cheers,

Silvia.

<p><p><p>Monty wrote:
> typo  s/eos/bos/

-> Fixed.

> Also... a logical bitstream may have more than one header; the
> 'intitial header' that is on a page by itself as bos is described
> correctly.  Ogg mandates this header.  However, Ogg also allows but
> does not require subsequent secondary headers for logical streams and
> these must also preceed any data in any stream.  These subsequent
> headers are framed into an integral number of pages (a page will not
> contain both secondary header and data packets).  Vorbis, for example,
> uses three headers per logical stream.
> 
> So.... a physical stream link begins with the initial headers of all
> logical streams (one per page), followed by the subsidary headers of
> all streams (framed into an integral number of pages), followed by
> pages containing data packets.

-> I've included those comments:
  Ogg also allows but does not require secondary header pages after the 
bos page for logical bitstreams and these must also preceed any data in 
any stream.  These subsequent header pages are framed into an integral 
number of pages, which will not contain any data packets. So, a physical 
bitstream begins with the bos pages of all logical bitstreams containing 
one initial header per page, followed by the subsidary header pages of 
all streams, followed by pages containing data packets.

-> I've also expanded the vorbis example:
An example for 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. Ogg Vorbis also uses two additional header 
pages per logical bitstream. The Ogg Vorbis bos page starts with the 
byte 0x01, followed by "vorbis" (a total of 7 bytes of identifier).

>>   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.
> 
> 
> It might be worth noting that in the mappings proposed right now
> (audio and video), pages from various logical streams must be
> interleaved in chronological order.  This is not set by Ogg itself as
> you note, but may well be the specified convention in every practical
> use.

-> I've added a sentence:
To enable streaming, pages from various logical bitstreams will 
typically be interleaved in chronological order.
--> does that make sense?

<p>> 
>>   From Ogg's perspective, packets can be of any arbitrary size.  A
>>   specific media mapping will define how to group or break up packets
>>   from a specific media encoder.  A nominal page size of approximately
>>   4-8 kByte is RECOMMENDED for latency reasons.
> 
> 
> In fact, the 4-8kB figure makes sense mostly for single-type
> streams. The recommended page size will depend on media mapping, and
> for video it may well be something like '4-8kB or one second of
> decoded data, whichever is smaller'.

-> I've deleted the recommendation for futureproofness - hope that's ok :)

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.