Dear Ye Kui, all,
just to highlight that my purpose was just to highlight a possible
critical scenario considering the already existing solutions and
emphasize what in my (negligible... :) ) opinion was the best solution.
I'm aware that making changes to the SVC RTP payload draft (and perhaps
to the SVC video coding spec...) isn't maybe the best step to perform at
this stage and that we could simply rely on already existing solutions.
Anyway, any further opinion would be very appreciated.
Thanks,
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 3:09 PM
Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC
temporal scalable bitstream - Packet loss
See also inline. I removed overhead text to make reading easier.
The issue is now pretty clear. The question is whether to change the
payload structures to associate a 16-bit layer specific RTP sequence
number to each NAL unit, or rely on existing solutions.
Personally I think we should not make the change to the SVC RTP payload
draft as the change is needed to all types of packets. So Daniele you
would like to have this?
Does anyone else there has an opinion?
BR, YK
- 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.
Right. My misunderstanding that you meant to any 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.
[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?
Yes, that's right.
[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.
After parsing slice header you then know the value of frame_num and
picture order count values. Then together with RTP sequence number
should be able to detect loss of pictures and slices. This is simply as
the two solutions mentioned earlier.
--
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