Subject: Re: [AVT] [Fwd: I-DAction:draft-schierl-avt-rtp-multi-session-transmission-00.txt]

From: Thomas Schierl <[email-masked]>
Date: Fri, 14 Nov 2008 07:57:42 +0100

Hi Ye-Kui,

Thanks for your feedback!

[email-masked] wrote:
> Good draft! Just a few comments:
>
> - There is one problem that is common for all timing based data
> alignment methods (documented in sections 7.1, 7.2.1, 7.2.1, 7.2.3, and
> 7.2.4) but has not been mentioned in the draft. The timing based methods
> themselves do not always work for encoding schemes wherein the decoding
> order of coded data units is different from the output/playout order
> (i.e. media timestamp order). Cases wherein the methods do not work well
> include transporting media with pure temporal scalability using
> multi-session transmission and when some packet loss patterns happen
> (see detailed discussions in
> http://research.nokia.com/files/SVC_cross_layer_decoder_order_recovery.p
> pt). Thus, these methods may have to be used together with some payload
> specific mechanisms, e.g. Empty NAL units as used by the NI-T and NI-TC
> modes defined in the SVC payload draft, to make them complete.
>   
We discussed this problem before and the outcome was that this is nature 
of RTP synchronization.
Anyway, these issues should be mentioned in a general draft on multi 
session transmission. So, I try to include them in the next version.
> - Note that in SVC, an enhancement may also be independent of the base
> layer, similar as in MVC that a non-base view may be independent of the
> base view. In addition, even though the current MVC codec may not fly,
> it is likely some kind of multiview codecs will fly in the future.
> Therefore, mandating using of a single SSRC may not be ideal, even
> though that might be OK for now for SVC, for simplicity. However, if
> possible, to have a complete and future-proof design would be desirable.
> Therefore,.it should worth a discussion on potential issues and
> solutions of using multiple SSRC values for different RTP sessions
> transporting one scalable/embeded bitstream.  
>   
During the SVC work we had extensive discussions on using or not using 
SSRC for multiplexing. In draft-wenger-avt-rtp-svc-03.txt, we even 
included this feature. The outcome of all the discussions was not to go 
that way for different reasons. As far as I can remember for SVC there 
was the use case of light weight adaptation based on SSRC instead of 
consuming a transport address for each multiplexing point as done for 
session multiplexing.

Beside this, I cannot see a strong use case for SSRC multiplexing in MVC.

Assuming that we have a layer/view not depending on any of the other 
layers/views in multi session transmission: Such a "independent" session 
would not have any dependency to the other sessions of the same SVC/MVC 
stream. We may point this out as a special case in the SVC and MVC 
drafts. Thus it would be meaningful to exclude such a session from the 
multi session transmission and the dependency signaling. Further, this 
would mean to also assign a different SSRC to such a session.

> - In multi-session transmission of scalable/embeded speech and audio,
> e.g. G.718, though different layers may have different sampling rates,
> there is no problem to use a common RTP timestamp clockrate, as is the
> case in
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-g718-00.txt.
>   
This is an important point, which additionally motivates the RTP 
timestamp alignment. It is at least not an argument against it, what I 
was thinking before.

Best regards,

Thomas

-- 
Thomas Schierl
--------------
Fraunhofer HHI

----
Visit us at

MEDICA 2008 / Duesseldorf, Germany / 19 - 22 November 2008 / Hall 16, Booth D55
http://www.medica.de

SOCCEREX 2008 / Gauteng, South Africa / 23 - 26 November 2008 / Booth V1-B1 a
http://www.soccerex.com

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

---

From: <[email-masked]>
Date: Fri, 14 Nov 2008 10:55:30 +0200

>Beside this, I cannot see a strong use case for SSRC 

I am not advocating SSRC multiplexing, but just pointing out that for
both SVC and MVC, there can be layers/views not dependent on the base
layer/view, therefore, mandating that all the RTP sessions in
multi-session transmission use thd same SSRC might be ideal for some use
cases. 

>would mean to also assign a different SSRC to such a session.

This is a very good point. An independent session or an independent
subset of sessions can be handled independently also in signaling. For
example, if there are two sets of independent sessions, and they are not
subscribed simultaneously by any receiver, then they should use
different SSRC values, and SSRC collision detection and re-generation
should be done based on the "base session" of each set, because the
sending and receiving of each set is independent. However, if they are
subscribed simultaneously by at least one receiver (e.g. a gateway that
will further separate the sets to different receivers), then even they
are independent from decoding relation, they are not independent for
sending and receiving, the same SSRC value should be used, and SSRC
collision detection and re-generation should be done based on the real
base session of the union of the two sets.

I think the above approach will resolve the SSRC issue for both SVC and
MVC. Please share your opinion whether we should implement this into
both drafts. 

BR, YK

---

From: Colin Perkins <[email-masked]>
Date: Mon, 17 Nov 2008 22:09:04 +0000

On 28 Oct 2008, at 12:31, Thomas Schierl wrote:
> As you may have already noticed, we submitted yesterday the eagerly  
> awaited draft on multi-session and multi-source related issues.
>
> There will be a presentation and a discussion at the next meeting  
> during one of the avt sessions.

Section 7.1.1.3 and 7.1.1.4 imply that a system must use the system  
real-time clock (Unix gettimeofday() or its equivalent on Windows) to  
generate the NTP-format clock used in RTCP SR packets. It then notes  
that this often has lower accuracy than desired. I don't see that  
requirement in the RTP specification: you need to use the same clock  
to generate the NTP wall-clock timestamps in all sessions to be  
synchronised, but RTP doesn't care what clock is used - you can use a  
different clock if that better meets your accuracy goals.

Equally, I don't see any problem delaying an RTCP packet until the  
next clock tick, to get an accurate timestamp, if that's easier to  
implement.

It might be useful to document implementation techniques somewhere,  
if there is evidence that SR timestamp are being widely mis-implemented.

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