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

[Randell Jesup <rjesup at wgate.com>]

<Ye-Kui.Wang at nokia.com> writes:
>Thanks a lot to Mike for another round of careful review and good
>comments. Please see my replies inline, all in this colour.

I couldn't tell which were your comments in all cases, but here are a
few comments:

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

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.

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.


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


>  16) Packetization Rules, page 25
>
>  "... the single NAL unit packetization mode SHOULD NOT be used whenever
>  possible ..."
>
>  
>
>  This probably does not have the intended meaning. To me, when read
>  explicitly as it is written, it is saying that the single NAL unit
>  packetization mode should not be used at every possible opportunity, and
>  instead, occasionally, something else should be done.
>
>  
>
>  Instead, "... use of the single NAL unit packetization mode SHOULD be
>  avoided whenever possible ..."
>
>  
>
>  I don't really see the difference but I believe that your wording is
>  better.

The original wording has an ambiguous meaning.  The new wording is clearer.

-- 
Randell Jesup
rjesup at wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

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