Re: [AVT] Vorbis RTP issues list for Vienna

[Aaron Colwell <[e-mail]>]

On Thu, 10 Jul 2003 [e-mail] wrote:

> Hi John / Aaron / Ross,
>
> John, yes you are right when you state that the codebooks can change quite
> frequently, between tracks, and this is a function of the codec which the RTP
> stream must cope with.  Your draft-lazzaro-avt-rtp-framing-contrans-01 looks
> like it could offer a good solution and I should track its development more
> closely.
>
> Ross / Aaron, the number of codebooks that can be found 'in the wild' is a
> reasonably large, but not infinite, number and the caching mechanism is
> meant to
> reduce the need to retransmit them each time.  Having a general purpose
> streaming codebook is a reasonable suggestion, John and I discussed
> when we met,
> but it is uncertain if a fully generic one can be produced which will
> cater for all scenarios.

Could a set of codebooks help? Perhaps you could predefine a set of
standard codebooks that are close to ones that are in the wild. For any
codebooks that don't match one of these, a predefined codebook could be
specified, plus some sort of codebook diff. My guess is that if the
predefined codebooks are pretty representative of codebooks in the wild,
the diff should be rather small.

There is still the problem of sending the diff when codebook changes
mid-stream. I can't see a way around this other than either using a
reliable transport for transmitting it or sending the diff's periodically.
The diffs should be much smaller than the actual codebook so periodic
sending of diffs won't be as bad as doing the same with the actual
codebooks. I'll have to think about this a little more.

I think my idea of a codebook translation tool could also help deal with
all the files that are out in the wild. Whoever wants to stream the file
can convert any existing file to one that uses one of the predefined
codebooks.

Aaron

>
> Regards
>
> Phil
>
> Quoting John Lazzaro <[e-mail]>:
>
> >
> > > Aaron Colwell <[e-mail]> writes:
> > > 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.
> >
> > I think its just an instance of a general problem -- transport of
> > hybrid streams with two components:
> >
> >   -- A steady flow of media information that can handle the
> >      occassional packet loss episode gracefully and without
> >      retransmission
> >
> >   -- Occassional chunks of data, which can be sent well ahead of
> >      its need, which needs reliability, and which is synchronous
> >      to the media flow.
> >
> > So, I think its a good idea for RTP to offer solutions that work
> > in this domain.  There are some studio-oriented uses of RTP MIDI
> > which fit into the model, and my motivation for doing
> > draft-lazzaro-avt-rtp-framing-contrans-01 is to support those in
> > a general way, so that when things like Vorbis codebooks come
> > along, RTP has a way to support them.  I really don't think that
> > posing the question as all-or-none -- RTP streaming or Shoutcast-esqe
> > pseudo-streaming -- benefits AVT, it will just spawn more HTTP
> > streaming implementations.
> >
> > That said:
> >
> > > The Vorbis folks
> > > should come up with a "streamable" profile that encodes the audio using
> > > predefined codebooks.
> >
> > This is a good option too -- my guess is that most Vorbis setups
> > will only need one codebook for the life of the stream, and that
> > need will be known in advance.  A URL in the session description
> > to support HTTP download of that one codebook would be a way to
> > go, with perhaps a known set of "standard codebooks" codable by
> > speak tokens or by GUIDs for the MIME HTTP codebook object.
> >
> > -------------------------------------------------------------------------
> > 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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/avt
> >
>
>
>
>
> -------------------------------------------------
> This mail sent through IMP: http://horde.org/imp/
>
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/avt
>

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