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

[<[e-mail]>]

 
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)'; [e-mail]; Thomas Schierl
>Cc: [e-mail]
>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:[e-mail]]
>>Sent: Sunday, August 19, 2007 8:55 PM
>>To: Wang Ye-Kui (Nokia-NRC/Tampere); [e-mail]; Thomas Schierl
>>Cc: [e-mail]
>>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
>>[phone]  (tel/fax)
>>
>>----- Original Message -----
>>From: <[e-mail]>
>>To: <[e-mail]>
>>Cc: <[e-mail]>; <[e-mail]>
>>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: [e-mail]; [e-mail]
>>>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:[e-mail]]
>>>>Sent: Saturday, August 18, 2007 9:07 PM
>>>>To: Wang Ye-Kui (Nokia-NRC/Tampere)
>>>>Cc: [e-mail]; [e-mail]
>>>>Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC 
>>>>temporalscalable bitstream - Packet loss
>>>>
>>>>On 18 Aug 2007, at 18:36, <[e-mail]> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt