Re: [AVT] RTP streaming and adaptation to AVC of an SVC temporal scalable bitstream - Packet loss
"daniele renzi \(bsoft\)" <daniele@bsoft.info> Sun, 19 August 2007 17:55 UTC
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMozn-0005Jg-EH; Sun, 19 Aug 2007 13:55:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMozl-0005Ja-OG for avt@ietf.org; Sun, 19 Aug 2007 13:55:25 -0400
Received: from smtpd4.aruba.it ([62.149.128.209] helo=smtp6.aruba.it) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IMozi-0002he-84 for avt@ietf.org; Sun, 19 Aug 2007 13:55:25 -0400
Received: (qmail 23534 invoked by uid 89); 19 Aug 2007 17:55:18 -0000
Received: by simscan 1.1.0 ppid: 23508, pid: 23518, t: 0.1913s scanners: clamav: 0.90.3/m:43/d:3378
Received: from unknown (HELO bsoft007) (daniele@bsoft.info@87.13.174.76) by smtp6.aruba.it with SMTP; 19 Aug 2007 17:55:18 -0000
Message-ID: <002201c7e28a$168c34c0$0301a8c0@bsoft007>
From: "daniele renzi (bsoft)" <daniele@bsoft.info>
To: Ye-Kui.Wang@nokia.com, csp@csperkins.org, Thomas Schierl <schierl@hhi.fhg.de>
References: <009001c7e0dc$b114dd30$11010a0a@bsoft007> <1C1F3D15859526459B4DD0A7A9B2268B03BE988B@trebe101.NOE.Nokia.com> <78541B84-1BC4-4586-9B2D-A8E8A7707416@csperkins.org> <1C1F3D15859526459B4DD0A7A9B2268B03BE988E@trebe101.NOE.Nokia.com>
Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC temporal scalable bitstream - Packet loss
Date: Sun, 19 Aug 2007 19:55:10 +0200
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-Spam-Rating: smtp6.aruba.it 1.6.2 0/1000/N
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Errors-To: avt-bounces@ietf.org
Dear Ye-Kui, Colin, Thomas, all, many thanks for your clarifications. Anyway, I'd like to define precisely the scenario. Indeed, as Ye-Kui specified, the SVCtoAVC adapter assign new sequence numbers to the outgoing stream. Here is the problem: if a packet is lost in the incoming stream, it would be good if the adapter reported this anyway to the receiver, even though the packet loss was in a different RTP *segment* (I'm not sure if that can be defined as a *session*...), as in any case there has been a loss between the sender and the receiver that should be handled by the receiver itself. But the adapter cannot say whether this loss affected the base layer or an enhancement layer, as the prefix NALU could have been lost and with it the scalability information (temporal_id). Then it could assert that the sequence number gap in the incoming stream is due to a loss in the enhancement layer (then do nothing) even when this isn't true, or viceversa. We're trying to get a solution (maybe different than forcing the insertion of a sequence number gap in the outgoing stream) to make the receiver able to handle a loss in both the RTP *segments*. I'll try to evaluate the Thomas' proposal and have a better look to RFC-3550 and draft-ietf-avt-topologies-06.txt. Thanks again. Best regards, Daniele Daniele Renzi bSoft -- www.bsoft.info +39-0733-57707 (tel/fax) ----- Original Message ----- From: <Ye-Kui.Wang@nokia.com> To: <csp@csperkins.org> Cc: <daniele@bsoft.info>; <avt@ietf.org> Sent: Sunday, August 19, 2007 7:34 AM Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC temporalscalable bitstream - Packet loss OK, forget about my naïve question, because I found the following sentence in RFC 3550, "If multiple data packets are re-encoded into one, or vice versa, a translator MUST assign new sequence numbers to the outgoing packets." BR, YK >-----Original Message----- >From: Wang Ye-Kui (Nokia-NRC/Tampere) >Sent: Sunday, August 19, 2007 12:59 AM >To: 'ext Colin Perkins' >Cc: daniele@bsoft.info; avt@ietf.org >Subject: RE: [AVT] RTP streaming and adaptation to AVC of an >SVC temporalscalable bitstream - Packet loss > > >Hi Colin, > >Thanks for your clarification. But according to the following >sentence copied from Daniele's email, > >"... then the SVCtoAVC adapter doesn't know whether this loss >has to be signaled to the receiver, i.e. whether it must >insert a sequence number gap in the outcoming RTP stream...", > >the SVCtoAVC adapter uses a different RTP sequence number >value space for the outcoming RTP steam than the incoming RTP >stream. Is this what a translator can do? It is not clear how >the SVCtoAVC adapter handles the CC, SSRC and CSRC fields and >RTCP traffic, though. > >BR, YK > >>-----Original Message----- >>From: ext Colin Perkins [mailto:csp@csperkins.org] >>Sent: Saturday, August 18, 2007 9:07 PM >>To: Wang Ye-Kui (Nokia-NRC/Tampere) >>Cc: daniele@bsoft.info; avt@ietf.org >>Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC >>temporalscalable bitstream - Packet loss >> >>On 18 Aug 2007, at 18:36, <Ye-Kui.Wang@nokia.com> wrote: >>> In your example the SVCtoAVC adapter is an RTP mixer, which >>terminates >>> the RTP session between the sender and itself and restarts >>another RTP >>> session between itself and the receiver. >>> Therefore the RTP sequence number needs to be updated for the base >>> layer packets anyway. >> >>If the SVCtoAVC adapter is a transcoder from an SVC stream to an AVC >>stream, it will be an RTP translator, not an RTP mixer. >>Neither an RTP translator or a RTP mixer terminate the RTP >session. RFC >>3550 and draft-ietf-avt-topologies-06.txt discuss this in more detail. >> >>-- >>Colin Perkins >>http://csperkins.org/ >> >> >> -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.484 / Virus Database: 269.12.0/961 - Release Date: 19/08/2007 07:27 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt
- [AVT] RTP streaming and adaptation to AVC of an S… daniele renzi (bsoft)
- RE: [AVT] RTP streaming and adaptation to AVC of … Thomas Schierl
- RE: [AVT] RTP streaming and adaptation to AVC of … Ye-Kui.Wang
- Re: [AVT] RTP streaming and adaptation to AVC of … Colin Perkins
- RE: [AVT] RTP streaming and adaptation to AVC of … Ye-Kui.Wang
- RE: [AVT] RTP streaming and adaptation to AVC of … Ye-Kui.Wang
- Re: [AVT] RTP streaming and adaptation to AVC of … daniele renzi (bsoft)
- RE: [AVT] RTP streaming and adaptation to AVC of … Ye-Kui.Wang
- RE: [AVT] RTP streaming and adaptation to AVC of … Ye-Kui.Wang
- Re: [AVT] RTP streaming and adaptation to AVC of … daniele renzi (bsoft)
- RE: [AVT] RTP streaming and adaptation to AVC of … Ye-Kui.Wang
- RE: [AVT] RTP streaming and adaptation to AVC of … Ye-Kui.Wang
- Re: [AVT] RTP streaming and adaptation to AVC of … daniele renzi (bsoft)
- Re: [AVT] RTP streaming and adaptation to AVC of … daniele renzi (bsoft)
- RE: [AVT] RTP streaming and adaptation to AVC of … Ye-Kui.Wang
- Re: [AVT] RTP streaming and adaptation to AVC of … daniele renzi (bsoft)
- RE: [AVT] RTP streaming and adaptation to AVC of … Ye-Kui.Wang
- Re: [AVT] RTP streaming and adaptation to AVC of … daniele renzi (bsoft)
- Re: [AVT] RTP streaming and adaptation to AVC of … Thomas Wiegand
- Re: [AVT] RTP streaming and adaptation to AVC of … daniele renzi (bsoft)
- [AVT] Interop issue with H263-1998 Franceschini Guido
- RE: [AVT] Interop issue with H263-1998 Gary Sullivan
- Re: [AVT] Interop issue with H263-1998 Randell Jesup
- Re: [AVT] Interop issue with H263-1998 Colin Perkins
- Re: [AVT] Interop issue with H263-1998 Randell Jesup
- RE: [AVT] Interop issue with H263-1998 Even, Roni
- Re: [AVT] Interop issue with H263-1998 Randell Jesup
- RE: [AVT] Interop issue with H263-1998 Even, Roni
- RE: [AVT] Interop issue with H263-1998 Franceschini Guido
- RE: [AVT] Interop issue with H263-1998 Even, Roni
- RE: [AVT] Interop issue with H263-1998 Franceschini Guido
- RE: [AVT] Interop issue with H263-1998 Even, Roni
- RE: [AVT] Interop issue with H263-1998 Franceschini Guido