Subject: [AVT] Comments on draft-wenger-avt-rtp-svc-02

From: Jonathan Lennox <[email-masked]>
Date: Fri, 07 Jul 2006 16:05:15 -0400

I like this revision of the draft -- the design principles section in
particular is very helpful.  I have a few comments it.

For the last item in the design principles ("packet integrity needs to be
preserved end-to-end"), it's unclear to me whether this is intended to mean
that you have end-to-end authentication if you're using SRTP.  If so, this
would seem to conflict with the earlier point that MANEs terminate RTP
sessions.

The idea of the PACSI, to identify the SVC parameters of an
H.264/AVC-compatible slice, seems good, but I have a few questions about it.

First of all, since PACSIs can only be put into aggregation packets, there
doesn't seem to be any way to associate a PACSI NAL unit with a fragmented
slice.  Have you given any thought on how you'd identify the SVC parameters
of a fragmented H.264/AVC-compatible slice?

Secondly, I know there's work ongoing in JVT to add somewhat similar
functionality to the SVC specification itself, through a "suffix NAL unit",
an SVC NAL unit without slice data which follows a corresponding
H.264/AVC-compatible NAL unit.  (Indeed, I believe Ye-Kui Wang is working on
this.)  This seems to address a similar problem as the PACSI NAL unit does.
What's the relationship between the PACSI and the suffix NAL unit -- in
particular, is there guidance about when you should use one or the other?

In section 7 (packetization rules), it says "Non-VCL NAL units SHALL be
transmitted out-of-band or in a separate session for the current state of
this specification."  This seems over-restrictive to me.  If a stream needs
to change its parameter sets (for example, for video switching), how are the
new parameter sets to be transmitted?

(It's also not clear what "for the current state of this specification"
means in this sentence.)

On a somewhat broader question, I'm wondering whether you envision MANEs as
needing to keep packet reordering buffers.

I believe that the order of the RTP sequence numbers of the packets sent out
by a MANE must correspond to the order of the packets the MANE receives.
For non-interleaved mode this is obviously true; for interleaved mode, a
MANE has some flexibility about reordering RTP packets, but there are still
many constraints with respect to fragmentation units and the need not to
exceed the size of the stream's interleaving buffer.

If packets of an SVC stream arrive at a MANE out of order, it seems like the
MANE won't know, on receiving the earlier packet, whether the later packet
is one that will be sent (and thus a gap should be left in the RTP sequence
numbers), or one that will be dropped (and thus a gap should presumably not
be left, so the receiver doesn't interpret it as an unintentional erasure).
Have you considered this case, and how do you envision it being addressed?

--
Jonathan Lennox -- Layered Media
[email-masked]

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

---

From: <[email-masked]>
Date: Mon, 10 Jul 2006 13:29:01 +0300

Hi Jonathan,

See my responses inline. 

>For the last item in the design principles ("packet integrity needs to 
>be preserved end-to-end"), it's unclear to me whether this is intended 
>to mean that you have end-to-end authentication if you're using SRTP.  
>If so, this would seem to conflict with the earlier point that MANEs 
>terminate RTP sessions.
>

My understanding is that "end-to-end" can mean endpoint to endpoint but
also endpoint to MANE. I think that the "end-to-end" in "packet
integrity needs to be preserved end-to-end" means the latter.

>First of all, since PACSIs can only be put into aggregation packets, 
>there doesn't seem to be any way to associate a PACSI NAL unit with a 
>fragmented slice.  Have you given any thought on how you'd identify the

>SVC parameters of a fragmented H.264/AVC-compatible slice?
>

Your point is valid. Currently there is no way to indicate the SVC
parameters of a fragmented AVC-compatible slice in the corresponding RTP
packet. Frankly, I did not thought about this before. One possible
solution is to allow to aggregate PACSI and a fragmented unit.
Alternatively, to design a new type of FU where the SVC parameters are
signaled. However, maybe we need to think about whether there are
compelling use cases for this. What do you have in mind for both the use
cases and the design?

>functionality to the SVC specification itself, through a "suffix NAL 
>unit", an SVC NAL unit without slice data which follows a corresponding

>H.264/AVC-compatible NAL unit.
>(Indeed, I believe Ye-Kui Wang is working on

That's true. 

>particular, is there guidance about when you should use one or the 

Good comment again. The suffix NAL unit can only be applied to
AVC-compatible NAL units in the bitstream level, while the PACSI NAL
unit can be applied to any NAL units in the RTP stream level. Therefore,
when encapsulating AVC base layer only, it is not a must to use PACSI to
indicate the SVC parameters if the suffix NAL unit is encapsulated in
the same RTP packet. However, using of PACSI could still be helpful, as
the SVC parameters would be easier to fetch. When encapsulating an
aggregation packet containing SVC NAL units, the PACSI NAL unit would be
helpful to tell the overall SVC parameters of the all the aggregated NAL
units, while using suffix NAL unit cannot achieve the same purpose. 

>transmitted out-of-band or in a separate session for the current state 
>of this specification."  This seems over-restrictive to me.  If a 
>stream needs to change its parameter sets (for example, for video 
>switching), how are the new parameter sets to be transmitted?
>

Again, you are right. This aspect was left as an open issue in the
internal document among the authors. In the final version, we must allow
in-band transmission of non-VCL NAL units, including parameter sets as
well as SEI messages. 

>
>On a somewhat broader question, I'm wondering whether you envision 
>MANEs as needing to keep packet reordering buffers.
>
>I believe that the order of the RTP sequence numbers of the packets 
>sent out by a MANE must correspond to the order of the packets the MANE

>receives.
>For non-interleaved mode this is obviously true; for interleaved mode, 
>a MANE has some flexibility about reordering RTP packets, but there are

>still many constraints with respect to fragmentation units and the need

>not to exceed the size of the stream's interleaving buffer.
>

Personally I think a powerful MANE could change the original
transmission order or even the packetization mode, as the end-to-end may
mean original sender to MANE and MANE to receiver. 

>If packets of an SVC stream arrive at a MANE out of order, it seems 
>like the MANE won't know, on receiving the earlier packet, whether the 
>later packet is one that will be sent (and thus a gap should be left in

>the RTP sequence numbers), or one that will be dropped (and thus a gap 
>should presumably not be left, so the receiver doesn't interpret it as 
>an unintentional erasure).

I consider this as an implementation issue - how the MANE receive,
manipulate and send the stream is entirely dependent on what purposes it
wants to achieve. 

BR, YK