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

[<[e-mail]>]

Hi Daniele,

See inline, please. 

BR, YK 

>-----Original Message-----
>From: ext daniele renzi (bsoft) [mailto:[e-mail]] 
>Sent: Tuesday, August 21, 2007 2:12 PM
>To: Wang Ye-Kui (Nokia-NRC/Tampere)
>Cc: [e-mail]
>Subject: Re: [AVT] RTP streaming and adaptation to AVC of an 
>SVC temporal scalable bitstream - Packet loss
>
>Dear Ye Kui,
>
>I've been doing a little more thinking about the solution of 
>having layer specific sequence numbers and I got the following 
>conclusions (please correct me if something is wrong):
>- each combination of temporal_id (3 bits), dependency_id (3 
>bits) and quality_id (5 bits) completely identify a scalable layer;

An error from myself: quality_id is of 4 bits, not 5 bits. 
Otherwise yes if a scalable layer is defined as a combintion of the
three variables DTQ. In some exotic cases, a scalable layer may also be
a subset of NAL units of a combinaiton of DTQ, e.g. when
region-of-interest (ROI) scalability is in use. 

>- the streamer should keep a separate sequence number variable 
>for any of these layers (combination of temporal_id, 
>dependency_id and quality_id);
>- separate sequence number variables don't mean different 
>fields in the RTP payload header (NALU header), as any NALU 
>belongs to a specific layer and not to other layers (1:1 
>mapping between NALU and layer);
>- so, we'd have just one additional field in the NALU header 
>(16 bit, like sequence number in RTP); this field could be 
>added just to the prefix NALUs syntax to save some bandwidth; 
>this wouldn't make the RTP payload structure that ugly, at 
>least in my opinion...;

This is true if you never encapsulate NALUs with different values of DTQ
in the same packet. But the thing gets complicated when considering
aggregation packets, and more when considering interleaved packetization
mode. But you are right that probably nobody would ever encapsulate NAL
units from the maximum possible number of layers into one packet,
therefore the number of layer specific sequence numbers would never
reach the maximum, 8x8x16. But anyway, then a loop of layers is needed,
and an ID of layer is needed in addition to each sequence number. 

>- I agree that having a prefix NALU for any slice NALU would 
>definitely increase the bandwidth occupation and that for 
>temporal scalability the SEI message based solution could be 
>better; however, this would mean that in any SVC streaming 
>scenario the single RTP session mode must be used in 
>conjunction with the sub-sequence SEI message to prevent 
>packet loss problems when dropping higher layers;

Prefix NAL unit can only be associated with NALUs with dependency_id and
quality_id both equal to 0. 

>- if everything above is correct, I suppose that without this 
>additional layer-specific sequence number field, in any case 
>the smoother way to handle packet losses is transporting 
>different layers of a SVC bitstream in different RTP sessions.
>

The conclusion is correct to me. Yet another solution with single RTP
session, without sub-sequence info SEI message, without PACSI or prefix
NAL unit, is to let the adapter parse the slice header. Then together
with normal RTP sequence number the adapter should be able to detect any
loss of any layer.

BR, YK

>Thanks
>
>BR,
>
>Daniele
>
>Daniele Renzi
>bSoft -- www.bsoft.info
>[phone]  (tel/fax)
>

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