Vorbis dev - Aug 2000 - Ogg Vorbis Framing

Hi all,

Here are some thoughts on Vorbis framing, which may make it easier to
stream Vorbis in real time.  The suggested changes also move more audio data
closer to the beginning of each page.  A note in the Vorbis framing spec
suggests
a simple 'bandwidth limited' mode whereby important information is
placed at the
front of each page and the end of each page is discarded.  When operating
in 'bandwidth limited' mode, packets modified in this way could offer
slightly
better audio quality.

This message is based on a message I sent to 'Monty' on 29/7.  He
didn't
offer any comments, so I thought I would run it by this mailing list.  Does this
suggestion make sense?

POSITIONING OF LACING VALUES

The format for a Vorbis page is something like:

header,
lacing values,
data.

When building this in hardware, it is necessary to buffer all the lacing values,
then
identify each data segment.  It would be easier if each lacing value appeared at
the
beginning of the relevant segment, avoiding the need for buffering. ie.:

header
lacing value 0
data segment 0
lacing value 1
data segment 1
...
lacing value n
data segment n

Was there a specific reason for having the lacing values collected at the front?
Can you think of any
disadvantages to interleaving lacing values with data, and placing the lacing
value for
a segment at the beginning of that segment? 

In the case of bandwidth limited transmission, where important data is at the
front of a page
and pages are truncated, distributed lacing values would make better use of the
bits
received, as unused lacing values would not be transmitted.

CRC POSITIONING

It is also inconvenient (from an ASIC view) having the CRC at the front of the
page, as
it is necessary to buffer the entire page during encoding, then insert the CRC
at the start of the packet.  Could the CRC be moved to the rear of the packet?
In the case of bandwidth limited transmission, the CRC would be lost, but it is
useless
in this case anyway. When a complete packet has not been received, it is invalid
to talk about doing a CRC calculation, as the CRC will always be wrong.

The background to this is an attempt to sketch out an Ogg Vorbis codec ASIC.
I'm not sure how useful a Vorbis codec ASIC would be (encoding a track in
seconds?
encoding lots of channels in real time?) but it is an interesting exercise.  If
nothing else,
it forces one to think very carefully about the algorithm, highlighting possible
improvements.

Is anyone else out there looking at a Vorbis ASIC?  I guess a response to this
particular
question really belongs in the 'user mailing list'.

Regards
John Dalton

john.dalton@bigfoot.com
Sydney, AU

References:
Vorbis framing spec: http://www.xiph.org/ogg/vorbis/doc/framing.html

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/

> Here are some thoughts on Vorbis framing, which may make it easier to
> stream Vorbis in real time.  The suggested changes also move more audio
data
> closer to the beginning of each page.
You've confused 'pages' and 'packets' throughout your
suggestion.  Your
understanding (or at least description) of how things work is too muddled to
really critique; the description is incorrect at most important points.

A few things to help you go back and look it over again:

a) pages and packets are *not* the same thing
b) you don't truncate *pages*; you truncate *packets* 
c) Ogg format is a frozen stream format meant for storage, local playback and
lossless, noninteractive tranmission.  It is not used for lossy net broadcast; 
we map to RTP/RTSP for that.
d) pages and headers are seperate abstractions; pages layer over formless 
packet data.  We do *not* mix the data.  KISS, thus the header is self
contained, not shot throughout the page.
e) CRC is absolutely essential to page capture.  It's not something you can
take or leave.  You have to have a whole page to compute it regardless.
f)lacing-> packet is not 1 to 1, the same as pages do not necessarily hold
integral packets, etc.  Pages are a capture and marking mechanism only.
> Is anyone else out there looking at a Vorbis ASIC?  I guess a response to
this particular
> question really belongs in the 'user mailing list'.
Actually, a member of OSDN showed us a completed FPGA design yesterday at
linuxworld, which they're taking to custom VLSI.  He plans to post the
complete
plans.

Monty

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/