Re: [AVT] Vorbis RTP issues list for Vienna

[philkerr@elec.gla.ac.uk]

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.

Regards

Phil

Quoting John Lazzaro <lazzaro@CS.Berkeley.EDU>:

> 
> > Aaron Colwell <acolwell@real.com> 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
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
> 




-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt