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

From: John Lazzaro <[email-masked]>
Date: Wed, 9 Jul 2003 15:02:42 -0700

> Aaron Colwell <[email-masked]> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: [email-masked]
Date: Thu, 10 Jul 2003 00:25:35 +0100

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

> speak tokens or by GUIDs for the MIME HTTP codebook object.

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

---

From: Aaron Colwell <[email-masked]>
Date: Wed, 9 Jul 2003 16:51:25 -0700 (PDT)

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

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.

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

> 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

---

From: Ross Finlayson <[email-masked]>
Date: Wed, 09 Jul 2003 17:03:03 -0700

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

There doesn't have to be just one 'codebook for streaming'.  Having a small 
number of pre-defined ones would be OK also.  E.g., if there were <= 256 
pre-defined 'codebooks for streaming', then you could use a 1-byte field 
within the RTP payload format to indicate which one.  But I suspect that <= 
16 pre-defined codebooks (i.e., 4 bits) would be enough.

         Ross.

---

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

On Thu, 10 Jul 2003 [email-masked] wrote:

> 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

---

From: Mark Baugher <[email-masked]>
Date: Thu, 10 Jul 2003 06:46:56 -0700

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

>pseudo-streaming" solutions either. I'll be a little more careful with

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

Mark