Subject: [AVT] Open issues for the SVC RTP payload format draft

From: <[email-masked]>
Date: Mon, 5 May 2008 02:22:16 +0300

Dear All,

As Roni mentioned earlier, the SVC RTP payload format design team has
made an agreement on decoding order recovery for session multiplexing.
The draft text for the agreed solution is being edited. At the same
time, it would be helpful if remaining open issues can be resolved
through the AVT mailing list. 

Here is the list of open issues that are extracted from the list in
Section 21 of draft-ietf-avt-rtp-svc-08 and that I think could be
resolved independently of other parts. Other open issues in the list in
Section 21 of draft-ietf-avt-rtp-svc-08 belong to at least one of the
following categories: a) resolved, b) connected to the decoding order
recovery issue, and c) need pre-work from the editors. 

1. In the PACSI NAL unit, the presence of the fields TL0PICIDX (8 bits)
and IDRPICID (16 bits) are optional (depends on the value of the Y bit),
and the bits A, P, C, S, and E are always present but their semantics
are specified only when the X bit is equal to 1. Should the presense and
semantics of these fields and bits be mandatory? 

2. Non-VCL NAL units, e.g. SEI messages and parameter sets, may be
needed by an enhancement layer but not the base layer. However,
according to SVC, within an access unit, these non-VCL NAL units must
precede VCL NAL units in decoding order. In session multiplexing, should
non-VCL NAL units be transported in the same session as the layer that
requires the non-VCL NAL unit, or should they be always transported in
the base session? Does it make sense to allow a MANE to include all of
the non-VCL NAL units within all the sessions?

3. Do we need the media type parameter sprop-spatial-resolution for
offering/answering spatial scalable layers?

4. Shall we allow NAL unit types 14 and 15 (i.e. prefix NAL unit and
subset SPS) to be present in the RTP stream carrying the T0 base Layer,
when encapsulated using RFC3984?

5. Do we allow the use of sprop-scalability-info, which contains the
scalability information SEI message, in offer/answer?

Therefore, I suggest that we try to resolve the above open issues first
before the next version of the text is available. 

Here are my opinions to the open issues above, just to have something
for people to bash on :-). 

1. As mandating the presence of TL0PICIDX (8 bits) and IDRPICID (16
bits) requires more bits, and mandating the semantics of the all the
fields and bits requires additional implementation and computataionl
complexities for applications that do not want to use these fields and
bits, I object mandating them. 

2. The payload spec should allow both the optimal way (i.e. a NAL unit
is only carried in the session where the NAL unit is needed) and the
convenient ways (e.g. to put all the non-VCL NAL unit in the base
session).

3. Basically yes - but I need to study some earlier AVT discussions
pointed out by Randell Jesup and some recent 3GPP SA4 discussions.

4. Yes we should allow for that, but we should not mandate that. 

5. Yes, as it provides a flexible yet efficient way for offer/answer.
For example, assme that an SVC bitstream contains 32 operation points,
while the majority of the receivers use only a few (say 4) of them, then
the SDP can contain 4 m lines for the 4 operation points, while other
operation points that are not expressed in the m lines can be found from
the sprop-scalability-info parameter by parsing into the scalability
information SEI message contained. 

BR, YK

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