[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
To be more precise, the adapter may only parse PACSI NAL units in the SVC based solution, as temporal_id is also included in PACSI NAL units.
BR, YK
>-----Original Message-----
>From: Wang Ye-Kui (Nokia-NRC/Tampere)
>Sent: Monday, August 20, 2007 12:16 AM
>To: 'ext daniele renzi (bsoft)'; csp at csperkins.org; Thomas Schierl
>Cc: avt at ietf.org
>Subject: RE: [AVT] RTP streaming and adaptation to AVC of an
>SVC temporal scalable bitstream - Packet loss
>
>
>Yet another solution is to use AVC itself instead of SVC (you
>can also use RFC 3984 instead of the SVC RTP payload draft),
>as you need only temporal scalability. This requires the use
>of sub-sequence information SEI messages. The
>sub_seq_layer_num indicates the temporal layer. You set each
>sub-sequence layer (i.e. temporal layer) as one sub-sequence,
>then the sub_seq_frame_num indicates the frame number of each
>reference frame inside a temporal layer.
>
>In the prefix NAL unit plus PACSI with TL0PicIndex solution,
>the adapter needs to parse prefix NAL units, and the outcoming
>stream can only be of temporal_id equal to 0 (i.e. the lowest
>temporal layer). In the sub-seqence informtion SEI message
>based solution, the adapter needs to parse sub-sequence
>information SEI messages, and the outcoming stream can be of
>any lower temporal layers.
>
>BR, YK
>
>>-----Original Message-----
>>From: ext daniele renzi (bsoft) [mailto:daniele at bsoft.info]
>>Sent: Sunday, August 19, 2007 8:55 PM
>>To: Wang Ye-Kui (Nokia-NRC/Tampere); csp at csperkins.org; Thomas Schierl
>>Cc: avt at ietf.org
>>Subject: 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