Subject: [AVT] Re: I-D ACTION:draft-xie-avt-rtp-anti-shadow-01.txt

From: Colin Perkins <[email-masked]>
Date: Sun, 4 Sep 2005 12:16:13 +0100

Qiaobing,

On 15 Jul 2005, at 20:50, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
>
>     Title        : RTP Payloads for Anti-shadow Redundancy
>     Author(s)    : Q. Xie, J. Schumacher
>     Filename    : draft-xie-avt-rtp-anti-shadow-01.txt
>     Pages        : 10
>     Date        : 2005-7-15
>
> This document defines a special form of RTP redundant packatization
>    format for multimedia broadcast and multicast services to combat
>    service interruptions caused by losses of large numbers of
>    consecutive media frames.  Along with the payload format, this
>    document also defines the procedures the RTP sender and receiver  
> will
>    need to use to conceal the large frames losses.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-xie-avt-rtp-anti- 
> shadow-01.txt

After reviewing this draft, it's not at all clear to me why you don't  
simply send an additional RTP stream with time offset, with the  
session description listing it as an alternative? Bundling the anti- 
shadow stream with the original stream forces all clients to receive  
the anti-shadow protection, whether or not they need it, and makes it  
difficult for gateways to add/remove protection.

Colin

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

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 15 Sep 2005 16:04:53 -0500

Hi, Colin,

Yes, using a separate RTP steam for the anti-shadow data is indeed an 
alternative to the bundled approach described in the draft. I vaguely 
remember I mentioned this either somewhere in the draft or during my 
presentation at avt.

One question is what would need to be standardized if we take the 
approach where a separate RTP stream is used for the anti-shadow data. 
I'd like to hear your view on this.

regards,
-Qiaobing

Colin Perkins wrote:

>>    document also defines the procedures the RTP sender and receiver  will
>> http://www.ietf.org/internet-drafts/draft-xie-avt-rtp-anti- shadow-01.txt
> 
> 
> simply send an additional RTP stream with time offset, with the  session 
> description listing it as an alternative? Bundling the anti- shadow 
> stream with the original stream forces all clients to receive  the 
> anti-shadow protection, whether or not they need it, and makes it

---

From: Colin Perkins <[email-masked]>
Date: Tue, 27 Sep 2005 18:46:23 +0100

Qiaobing,

On 15 Sep 2005, at 22:04, Qiaobing Xie wrote:
> Yes, using a separate RTP steam for the anti-shadow data is indeed  
> an alternative to the bundled approach described in the draft. I  
> vaguely remember I mentioned this either somewhere in the draft or  
> during my presentation at avt.
>

I'm not sure anything would need to be standardised in that case.  
Aren't the existing mechanisms suitable?

Colin

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 27 Sep 2005 14:08:49 -0500

Colin,

With the separate RTP stream approach, there apparently is no need for a 
new payload format. What I was thinking about is whether something needs 
to be specified in avt so that the sender and receiver can signal each 
other the use of the anti-shadow configuration of the two RTP streams, 
including the amount of forward-shit between the two streams. Is this 
still within avt's scope or should be done in the app space?

regards,
-Qiaobing

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 27 Sep 2005 15:17:39 -0400

This sounds like something you'd signal in SDP, unless the amount of 
forward-shiFt changes dynamically.

---

From: Colin Perkins <[email-masked]>
Date: Tue, 27 Sep 2005 20:18:15 +0100

Qiaobing,

On 27 Sep 2005, at 20:08, Qiaobing Xie wrote:
> With the separate RTP stream approach, there apparently is no need  
> for a new payload format. What I was thinking about is whether  
> something needs to be specified in avt so that the sender and  
> receiver can signal each other the use of the anti-shadow  
> configuration of the two RTP streams, including the amount of  
> forward-shit between the two streams. Is this still within avt's  
> scope or should be done in the app space?

It might be AVT or MMUSIC, if anything is needed. I was expecting the  
usual RTCP synchronisation mechanisms would take care if the forward- 
shift though?

Colin