[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] RTP streaming and adaptation to AVC of an SVC temporal scalable bitstream - Packet loss

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 at nokia.com>
To: <csp at csperkins.org>
Cc: <daniele at bsoft.info>; <avt at 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 at bsoft.info; avt at 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 at csperkins.org]
Sent: Saturday, August 18, 2007 9:07 PM
To: Wang Ye-Kui (Nokia-NRC/Tampere)
Cc: daniele at bsoft.info; avt at 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 at 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 at ietf.org
https://www1.ietf.org/mailman/listinfo/avt