Subject: Re: [AVT] Vorbis RTP issues list for Vienna

From: John Lazzaro <[email-masked]>
Date: Wed, 9 Jul 2003 11:53:30 -0700

> Magnus Westerlund <[email-masked]> writes:
>
> I think that we need to clear consider how to get these codebooks
> transported. A larger than 64kb codebook should neither be transported
> in SDP or in RTCP. I think that using HTTP can clearly be an
> alternative, and only provide the URI to the codebook.
>
> I wouldn't try to transport a codebook over RTCP that results in a
> RTCP packet many time the MTU due to the high number of IP
> fragments. Further such a packet will severely reduce the RTCP report
> rate in both directions.

I may be incorrect here, but from my discussions with Phil earlier
in the year, the codebook issue has these requirements:

 -- May change every few minutes (say, once per song when used for 
    Internet radio apps).
 -- Tightly synchronized with the stream: if you don't have the new
    codebook in time for the first packet that needs it, its a 
    catastrophe.
 -- Reliable reception a must, no built in resiliency if it is
    sent as a stream of UDP packets and some but not all arrive.

One way to handle this is to have two synchronized streams in the
media session: a UDP RTP/AVP stream for the media data, and a
TCP stream (perhaps an RTP/AVP stream if a solution like
draft-lazzaro-avt-rtp-framing-contrans happens, or perhaps an
opaque TCP stream) for the codebooks.  In either case, the
synchronization would happen as lip-sync synchronization happens.

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Ross Finlayson <[email-masked]>
Date: Wed, 09 Jul 2003 12:20:32 -0700

>  -- May change every few minutes (say, once per song when used for

IMHO, this is a flaw in the "Vorbis" architecture.  It would be much better 
to have a fixed, predefined set of codebooks that all receivers would know 
in advance.  Then you'd need to send only a 'codebook id', which should be 
small enough to include in the Vorbis RTP payload format header.

Having to send a complete codebook for each song partially defeats the 
purpose of audio compression.

The Vorbis designers should just figure out a complete set of codebooks 
that are likely to be useful, and settle on those.

         Ross.

---

From: Aaron Colwell <[email-masked]>
Date: Wed, 9 Jul 2003 13:12:17 -0700 (PDT)

I agree with Ross on this. It seems that these codebooks are causing too
many problems that aren't worth dealing with. People have been suggesting
getting the codebooks via HTTP, alternate TCP links, and all sorts of
other methods. If your going to go that far why not just use HTTP to
deliver the data. That way you are guaranteed to get everything in the
right order.

My guess is that other video and audio codecs use predefined tables to
avoid this very problem. Vorbis should do the same. The Vorbis folks
should come up with a "streamable" profile that encodes the audio using
predefined codebooks. Doing this makes all of the complicated codebook
issues go away. They could also create an offline tool that will translate
any Vorbis file into a "streamable" Vorbis file. This idea is similar to
hinting tools used for MPEG4 and 3GPP files.

Aaron