[vorbis-dev] Re: Ogg format and latency

[Silvia.Pfeiffer at csiro.au]

Hi Aaron,

thanks for your thoughts on improving the Ogg encapsulation format. As 
Monty was the person who developed the specification, I am forwarding 
your suggestions to him. Maybe some of these changes can be adopted into 
a future version of the Ogg encapsulation format.

Best Regards,

Silvia.

Aaron Williams wrote:
> Hi Silvia,
> 
> After reading the RFC on the ogg streaming format I see an improvement
> that can be made to reduce encoding latency on the sending end.  It also
> reduces the amount of memory required as well.
> 
> In your page format, you store the segment count and a segment table and a
> CRC in the front of each page.  Having experience with ATM networking and
> some hardware, it is actually better to place any checksums or CRCs at the
> end of a packet.
> 
> Another improvement can be made to the segments.
> 
> Instead of a segment count and a segment table in the beginning, just
> encode the length of each segment at the front of every segment.  Segments
> can be anywhere from 1 to 255 bytes not including the length field.  If
> the length field is zero then this is the end of the page and the CRC
> would immediately follow.
> 
> For a system generating a low-speed Ogg stream it reduces latency in that
> a page can be sent out on a per-segment basis without having to wait for
> the end of a page.  Another benefit is that it is no longer necessary to
> store the entire page in memory.
> 
> When networking, it is always a problem when fields like the length and
> checksum are stored at the beginning of a packet because the entire packet
> must be stored in memory before being sent.  ATM (Asynchronous Transmit
> Mode) AAL5 solved this problem by placing the length and CRC at the end of
> the packet.  In ATM, each packet is chopped up into 48 byte cells where a
> 5 byte header is prepended.  A bit in the 5 byte header indicates that the
> cell is the last cell of a PDU and the last 8 bytes contain a trailer, 2
> unused bytes, a 16-bit length, and a 32-bit CRC.
> 
> The advantage of this is that the latency is reduced for the sending side
> since it can transmit data as soon as it has at least one cells worth of
> data.  When the MTU size is reached it just sets a bit and fills in the
> trailer.  This also means that the sending hardware does not need to store
> potentially 64K of data since it only needs to keep track of the number of
> bytes sent and the running CRC.
> 
> With my proposed change, the page size stays the same, only the segment
> information is distributed throughout the page and the CRC is moved to the
> end.
> 
> If the transport medium is reliable the receiving end can begin decoding
> data before the end of the page is received, as is possible with the
> current Ogg format.
> 
> Sincerely Yours,
> 
> Aaron Williams
> 
> aaronw at doofus.org
> 

--- >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.