Re: [AVT] Comments on draft-ietf-avt-rtp-svc-07.txt

[<Ye-Kui.Wang at nokia.com>]

>>6) Session multiplexing, page 16
>>
>>  "Each RTP session requires a separate signaling and has a separate  
>> Timestamp, Sequence Number, and SSRC space."
>>
>>  I am unclear about what is meant by a separate Timestamp 
>space. Does  
>> this mean that the encoded values are different (for security 
>> purposes)  but are based on the same clock, or does it mean 
>that they 
>> are different  and based on different clocks.
>>
>>  Presumably the former is the intention. I can not see how the 
>> non-CL-DON  decoding order recovery method could work if the latter 
>> were the  intention.
>>
>>  The intention is that timestamp values are independent for the RTP  
>> sessions. I think different RTP sessions should use the same clock, 
>> but  probably that should not be mandated - when considering the 
>> potential  use cases with parallel encoding devices with 
>different clocks.
>>  Different clocks certainly adds difficulties for the 
>non-CL-DON mode 
>> to  work, but it should still be possible, after the 
>timestamp values 
>> of  different sessions are mapped to a same clock.
>
>RTP 3550 mandates that separate streams each has separate 
>Timestamp, Sequence Number, and SSRC spaces, so the quote 
>above is merely repeating this requirement.
>
>Allowing for different base clocks (drift, offset, rate, etc) 
>among the separate streams would be... fun, though possible.  
>Normally you *do* need to account for different clocks (at 
>least in synchronizing streams), but for this case 
>(enhancement layers, part of a defined multi-session entity, 
>where all the layers come from one theoretical source (I 
>assume?)), you could make an argument for the clock bases (not 
>the values!) being tied.
>

Agreed - as I thought earlier. 

>The point about different encoding devices - the encoder 
>doesn't set the time of the frame; the time it was sampled 
>does.  Assuming they came from the same sampled source, that 
>isn't an issue.
>

You are right. 

>Also, is there something somewhere else that states that the 
>timestamp rate negotiated for each stream via signalling has 
>to be the same?  There should be, even though it seems 
>obvious.  Just because 90000 is the 'default', don't assume it 
>will always be used or required.
>

I thought about the same. Maybe this should go to the signaling draft
(draft-ietf-mmusic-decoding-dependency).

>
>"requires a separate signaling" is awkward and may be 
>confusing; I'd use something like "Each RTP session is 
>negotiated as a separate stream via signalling, such as 
>separate m= lines in SDP (RFC xxxx)".  Not a huge point. 
>

Agreed. 

BR, YK
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
http://www.ietf.org/mailman/listinfo/avt