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

Hi Ye-Kui,

Thanks for your feedback!

Ye-Kui.Wang@nokia.com 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
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt