Subject: Re: [AVT] I-D Action:draft-lennox-avt-rtp-layered-encoding-timestamps-00.txt

From: Colin Perkins <[email-masked]>
Date: Fri, 4 Jul 2008 08:32:18 +0100

On 12 Jun 2008, at 22:12, Jonathan Lennox wrote:
> Colin Perkins wrote:
>> I have no particular objection to this proposal in itself, but I
>> believe that using the same SSRC across multiple layers is
>> undesirable, and when different SSRC values are used for each layer,
>> this proposal offers no benefit.
>>
>> While using the same SSRC for each layer is simpler for some case, it
>> makes multiplexing several layers onto the same session difficult
>> (the suggestion below to demultiplex based on the RTP payload type
>> doesn't work). Since managing multiple UDP ports is difficult, I
>> would expect that multiplexing several layers onto the same port,
>> with media-aware RTP translators dropping layers at network
>> boundaries to perform adaptation, to be a common use case, and not
>> something we should break.
>
> The question is if there's any benefit to multiplexing layers into an
> RTP session by placing them in separate RTP streams, as opposed to  
> doing
> so in a payload-specific manner within a single stream.  It's  
> certainly
> the case that for H.264 SVC, SSRC-based layer multiplexing within a
> session was present for a few revisions of the payload draft, but was
> dropped for lack of a convincing use case.
>
> The compelling reason for splitting a media stream across multiple RTP
> streams is when you actually want different transport-layer  
> behavior for
> the streams, for example when the layers are distributed over  
> different
> multicast groups.  In this case the streams obviously have to go into
> different RTP sessions, and RFC 3550 SSRC-alignment applies.
>
> The case of adaptation at network boundaries is certainly a common use
> case, but a media-aware network element can operate (in RTP  
> terminology)
> as a mixer, rather than as a translator, and drop layers from  
> within an
> RTP stream (fixing up sequence numbers to compensate).  Since it's
> media-aware, it necessarily understands the payload format.  This  
> avoids
> problems of stream association and SSRC collision, especially if  
> you're
> also sending multiple distinct media sources over the session.

Sure, at the expense of more complexity in the adaptation device  
(both in terms of computation, and specification since this is a  
media specific, rather than a general mechanism).

-- 
Colin Perkins
http://csperkins.org/

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