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

["daniele renzi \(bsoft\)" <daniele at bsoft.info>]

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