[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,
please see inline.
BR,
Daniele
Daniele Renzi
bSoft -- www.bsoft.info
+39-0733-57707 (tel/fax)
----- Original Message -----
From: <Ye-Kui.Wang at nokia.com>
To: <daniele at bsoft.info>
Cc: <avt at ietf.org>
Sent: Tuesday, August 21, 2007 1:36 PM
Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC temporal
scalable bitstream - Packet loss
Hi Daniele,
See inline, please.
BR, YK
-----Original Message-----
From: ext daniele renzi (bsoft) [mailto:daniele at bsoft.info]
Sent: Tuesday, August 21, 2007 2:12 PM
To: Wang Ye-Kui (Nokia-NRC/Tampere)
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,
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.
[DR] Ok. Error from myself as well...:)
- 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.
[DR] That's why such layer-specific sequence number parameter should be
added to any NALU, not to any packet .
This way if you loose a packet you can track the loss of NALUs for any
layer.
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.
[DR] The layer ID could be simply inferred by combining the DTQ values, then
not added as a field in the payload header. Isn't that correct?
Anyway, you are right that things could get complicated, but in any case
this would be just a computational problem for the streamer (keeping
multiple variables for the various sequence numbers, looping over layers,
etc.) and not a big burden for the RTP payload (16 bits per NALU), unless
one encapsulate several NALUs in the same packet.
A 1-bit flag could be even used to signal that such 16-bits field is present
or not.
- 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.
[DR] You are right.
- 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.
[DR] I agree with you, even though I still can't see how the adapter could
deduce a loss by simply parsing the slice header and do not decoding the
rest of the stream, e.g. estimating the number of decoded macroblocks and
comparing it to the total number of MBs per picture or to first_mb_in_slice.
BR, YK
Thanks
BR,
Daniele
Daniele Renzi
bSoft -- www.bsoft.info
+39-0733-57707 (tel/fax)
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.484 / Virus Database: 269.12.1/963 - Release Date: 20/08/2007
17:44
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt