[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] Vorbis RTP issues list for Vienna

At 04:51 PM 7/9/2003 -0700, Aaron Colwell wrote:



On Wed, 9 Jul 2003, John Lazzaro wrote:

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

When stated in these more general terms I can see your point about how
this scenario could be useful. Another use may be a key stream for
encrypted content that changes encryption keys often. You would want this
data to be transmitted reliably and ensure that it gets there before the
data that depends on it arrives.
The keys to the data need to be delivered "at least as reliably" as the data but not necessarily "reliably." Putting keys in the data packet is one such method, but we are not likely to use this method in RTP (poor separation of functions, no third-party key mgt, etc). But there have been proposals for using RTCP or SRTCP. Rather than extend RTCP or SRTCP for this purpose, however, a better approach IMHO is to put the key in the SDP and send it "at least as reliably" as the SRTP. The SDP must of course be authenticated/integrity-checked and encrypted.


I did not mean to actually suggest the use of HTTP as a viable delivery
mechanism instead of RTP. I don't really want more "Shoutcast-esqe
pseudo-streaming" solutions either. I'll be a little more careful with
comments like this.

It's hard to engineer a network where media flows masquerade as something else.

Mark



I'll take a look at the draft that you mentioned and send you any comments
I may have.

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

Hopefully they will embrace these ideas. I think it could simplify client
implementations a bit. If they used just predefined codebooks or only used
one codebook and specified it via SDP, Vorbis would be just like many
other datatypes and would not require a lot of extra work to support in
existing players.

Aaron

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

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



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