Subject: [AVT] SVC design team status

From: "Even, Roni" <[email-masked]>
Date: Thu, 10 Apr 2008 15:46:09 +0300

Hi,

I would like to thank the people in the SVC design team for their work efforts.

The design team includes Ye-Kui Wang, Jonathan Lennox, Alex Eleftheriadis, Stephan Wenger, Thomas Wiegand, Thomas Schierl, Mike Nilsson, Peter Amon, Miska Hannuksela, Sam Ganesan.

The SVC design team has come to an agreement under the following assumptions:

*	RFC3984 Mode 0 (Single NAL unit) is not supported in SVC for the enhancement layers.  Implication: endpoints implementing the SVC payload (and are therefore prepared to receive at least one enhancement layer--otherwise they would not be SVC endpoints but RFC3984 endpoints) MUST be prepared to receive STAP-As.
*	Remaining modes to be renamed so not to create association with loaded terminology.  Letters instead of digits (and supposedly the more verbose names of RFC3984--non-interleaved mode vs. interleaved mode) as well

The consensus in the design team is to define three operation modes: 

Mode A: STAP-As allowed, non-interleaved transmission. 

This is what is currently called "classical mode" with mandatory use of "filler NAL units" when multiple RTP sessions are used, AND when type I non-AU-aligned NAL units (as defined in the slide set) occur in the packet stream.  Otherwise, no "filler NAL units" mandated (as they are useless). The "filler NAL unit" is to be specified. The preference is for a new NAL unit that will be part of this specification. Mode A can be used with mode 0, 1, of RFC3984 in the base layer.

Mode B: STAP-As allowed, non-interleaved transmission. 

This is what's currently called "CL-DON mode". Senders must include PACSI NAL unit and CL-DON for each access unit within an RTP session when multiple RTP sessions are used.  Mode B can be used with all modes 0, 1, 2 in the RFC 3984 base layer.  The base layer includes PACSI NAL units and CL-DON. Support for mode 0 in the base layer will be explained in the document.

Mode C: all packet types and interleaving (even across AUs) allowed.  Mode C can be used with all modes of RFC3984 (with PACSI NAL units and CL-DON included as well), or only with mode 2 (to be discussed)

Issue to discuss:

1.	Should FUs be excluded from the enhancement layers. 

2.	Mode C - is it used only with RFC3984 mode 2 streams.

3.	Reserved NAL units - can the number space be extended.

4.	Do we allow mixed modes where some layers are mode A and others are mode B. This will also need SDP support. 

5.	Do we allow MTAPs for mode A, for example in order to aggregate the filler NAL units with succeeding NAL units.

Next phase

Update the SVC payload specification to include the consensus specifying the different modes (terms and text explaining the relations to RFC 3984). Update the specific sections 8.1.1 and 8.1.2.

Define the SDP support for the modes.

The design team will continue with the meetings in order to address the open issues from the email and the ones in the latest draft.

The next meeting is on April 21st (this is Monday and not Tuesday like the previous meetings)

Time: 17:00 Israel (Jerusalem) .  (14:00 GMT, 15:00 London (Israel time is GMT +3, London +2))

Dial in number: +1-678-7955235

 

Thanks

Roni Even

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

---

From: <[email-masked]>
Date: Thu, 10 Apr 2008 14:39:57 +0100

Here are some of my thoughts on these outstanding issues. 

I would like to see minimal differences between modes A and B, so that a
source could generate a bitstream that was compatible with both mode A
receivers and mode B receivers. As the likely applications for SVC are
broadcast (one source to many receivers), this would allow a source to
be able to send to all interested receivers without all of those having
to implement the same mode.

Hence I would support allowing fragmentation units in enhancement layers
for all modes (A, B and C).

In response to item 4, "Do we allow mixed modes where some layers are
mode A and others are mode B", as above I suggest that all layers are
the same, and are signalled as mode A, mode B, mode A+B, or mode C.

In response to item 2, "Mode C - is it used only with RFC3984 mode 2
streams", I would suggest yes. I would seem like a good idea to have the
same mode in each layer, including the base layer, and mode C is
effectively the same as mode 2.

I do not know why mode B should allow a mode 2 base layer? Is there a
real application for this? If the base layer can use mode 2, why should
the enhancement layers not use mode C? This appears to be an unnecessary
difference between modes A and B.

In response to item 5, allowing MTAPs into mode A seems to be making it
like mode C. It also makes it (more) different from mode B. Perhaps
rather than bringing the full MTAP capability into mode A (and mode B if
we are to keep them similar), the solution is to define something that
could be placed in the next aggregation packet to indicate one or more
preceding "type I non-AU-aligned NAL units". This would prevent the full
MTAP capability creeping in while being efficient in terms of the number
of packets generated.

And finally, if fragmentation units are allowed in enhancement layers
for all modes, could the syntax of fragmentation units (in enhancement
layers) be extended so that PASCI-like information could, if desired, be
included? This would improve error resilience for a mode B receiver.

 

Best regards

Mike

Mike Nilsson 
Multimedia Analysis and Coding
BT Group Chief Technology Office
___________________________ 

Sirius House (B54-MH), Room 92 
Adastral Park, Martlesham Heath, Ipswich, IP5 3RE, UK 
Tel:    +44 1473 645413 
Mobile: +44 7917 025433 
Fax:    +44 1908 862365 
Email:  [email-masked] <BLOCKED::mailto:[email-masked]> 

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Even, Roni
Sent: 10 April 2008 13:46
To: [email-masked]
Subject: [AVT] SVC design team status

Hi,

I would like to thank the people in the SVC design team for their work
efforts.

The design team includes Ye-Kui Wang, Jonathan Lennox, Alex
Eleftheriadis, Stephan Wenger, Thomas Wiegand, Thomas Schierl, Mike
Nilsson, Peter Amon, Miska Hannuksela, Sam Ganesan.

The SVC design team has come to an agreement under the following
assumptions:

*	RFC3984 Mode 0 (Single NAL unit) is not supported in SVC for the
enhancement layers.  Implication: endpoints implementing the SVC payload
(and are therefore prepared to receive at least one enhancement
layer--otherwise they would not be SVC endpoints but RFC3984 endpoints)
MUST be prepared to receive STAP-As.
*	Remaining modes to be renamed so not to create association with
loaded terminology.  Letters instead of digits (and supposedly the more
verbose names of RFC3984--non-interleaved mode vs. interleaved mode) as
well

This is what is currently called "classical mode" with mandatory use of
"filler NAL units" when multiple RTP sessions are used, AND when type I
non-AU-aligned NAL units (as defined in the slide set) occur in the
packet stream.  Otherwise, no "filler NAL units" mandated (as they are
useless). The "filler NAL unit" is to be specified. The preference is
for a new NAL unit that will be part of this specification. Mode A can
be used with mode 0, 1, of RFC3984 in the base layer.

This is what's currently called "CL-DON mode". Senders must include
PACSI NAL unit and CL-DON for each access unit within an RTP session
when multiple RTP sessions are used.  Mode B can be used with all modes
0, 1, 2 in the RFC 3984 base layer.  The base layer includes PACSI NAL
units and CL-DON. Support for mode 0 in the base layer will be explained
in the document.

Mode C: all packet types and interleaving (even across AUs) allowed.
Mode C can be used with all modes of RFC3984 (with PACSI NAL units and
CL-DON included as well), or only with mode 2 (to be discussed)

Issue to discuss:

4.	Do we allow mixed modes where some layers are mode A and others
are mode B. This will also need SDP support. 

5.	Do we allow MTAPs for mode A, for example in order to aggregate
the filler NAL units with succeeding NAL units.

Next phase

Update the SVC payload specification to include the consensus specifying
the different modes (terms and text explaining the relations to RFC
3984). Update the specific sections 8.1.1 and 8.1.2.

 

The design team will continue with the meetings in order to address the
open issues from the email and the ones in the latest draft.

The next meeting is on April 21st (this is Monday and not Tuesday like
the previous meetings)

Time: 17:00 Israel (Jerusalem) .  (14:00 GMT, 15:00 London (Israel time
is GMT +3, London +2))

 

Thanks

Roni Even

---

From: Alex Eleftheriadis <[email-masked]>
Date: Mon, 21 Apr 2008 17:04:22 +0300

Some comments inline.

On Apr 10, 2008, at 4:39 PM, <[email-masked]>  
<[email-masked]> wrote:

> I would like to see minimal differences between modes A and B, so  
> that a source could generate a bitstream that was compatible with  
> both mode A receivers and mode B receivers. As the likely  
> applications for SVC are broadcast (one source to many receivers),  
> this would allow a source to be able to send to all interested  
> receivers without all of those having to implement the same mode.
>
>
>
Note that the only shipping application of SVC I am aware of today is  
in videoconferencing. I have not seen any announcement regarding  
broadcast. But the argument is still valid.

> Hence I would support allowing fragmentation units in enhancement  
> layers for all modes (A, B and C).
>
>
>
Makes sense.
> In response to item 4, “Do we allow mixed modes where some layers  
> are mode A and others are mode B”, as above I suggest that all  
> layers are the same, and are signalled as mode A, mode B, mode A+B,  
> or mode C.
>
>

I agree that they should all have the same mode (the original  
question was rhetoric/academic). But what do you mean by mode A+B?
>
>
> In response to item 2, “Mode C – is it used only with RFC3984 mode  
> 2 streams”, I would suggest yes. I would seem like a good idea to  
> have the same mode in each layer, including the base layer, and  
> mode C is effectively the same as mode 2.
>
>
>

I agree.
> I do not know why mode B should allow a mode 2 base layer? Is there  
> a real application for this? If the base layer can use mode 2, why  
> should the enhancement layers not use mode C? This appears to be an  
> unnecessary difference between modes A and B.
>
>
>

I share the concern.
> In response to item 5, allowing MTAPs into mode A seems to be  
> making it like mode C. It also makes it (more) different from mode  
> B. Perhaps rather than bringing the full MTAP capability into mode  
> A (and mode B if we are to keep them similar), the solution is to  
> define something that could be placed in the next aggregation  
> packet to indicate one or more preceding “type I non-AU-aligned NAL  
> units”. This would prevent the full MTAP capability creeping in  
> while being efficient in terms of the number of packets generated.
>
>
>
Right, if the only reason to use MTAPs is to signal these packets,  
maybe a more focused approach is warranted. We should consider this  
when addressing  mode A. But this goes against the design preferene  
of keeping differences between modes A and B to a minimum.
> And finally, if fragmentation units are allowed in enhancement  
> layers for all modes, could the syntax of fragmentation units (in  
> enhancement layers) be extended so that PASCI-like information  
> could, if desired, be included? This would improve error resilience  
> for a mode B receiver.
>
>
>
By PACSI like do you refer to DTQ information? The design from  
RFC3894 uses NALs to insert what is essentially header data into the  
RTP stream. Adding something like this in a FU would deviate from  
that architecture. Not devastating, but it may break fundamental  
assumptions. Ye-Kui et al. should comment on this.

--Alex
> Email:  [email-masked]
>
> From: [email-masked] [mailto:[email-masked]] On Behalf  
> Of Even, Roni
> RFC3984 Mode 0 (Single NAL unit) is not supported in SVC for the  
> enhancement layers.  Implication: endpoints implementing the SVC  
> payload (and are therefore prepared to receive at least one  
> enhancement layer--otherwise they would not be SVC endpoints but  
> RFC3984 endpoints) MUST be prepared to receive STAP-As.
> Remaining modes to be renamed so not to create association with  
> loaded terminology.  Letters instead of digits (and supposedly the  
> more verbose names of RFC3984--non-interleaved mode vs. interleaved  
> mode) as well
>
> This is what is currently called "classical mode" with mandatory  
> use of "filler NAL units" when multiple RTP sessions are used, AND  
> when type I non-AU-aligned NAL units (as defined in the slide set)  
> occur in the packet stream.  Otherwise, no "filler NAL units"  
> mandated (as they are useless). The “filler NAL unit” is to be  
> specified. The preference is for a new NAL unit that will be part  
> of this specification. Mode A can be used with mode 0, 1, of  
> RFC3984 in the base layer.
>
> PACSI NAL unit and CL-DON for each access unit within an RTP  
> session when multiple RTP sessions are used.  Mode B can be used  
> with all modes 0, 1, 2 in the RFC 3984 base layer.  The base layer  
> includes PACSI NAL units and CL-DON. Support for mode 0 in the base  
> layer will be explained in the document.
>
> Mode C: all packet types and interleaving (even across AUs)  
> allowed.  Mode C can be used with all modes of RFC3984 (with PACSI  
> NAL units and CL-DON included as well), or only with mode 2 (to be  
> discussed)
>
>
>
>
>
> Issue to discuss:
>
>
>
> Should FUs be excluded from the enhancement layers.
>
>
> Mode C – is it used only with RFC3984 mode 2 streams.
>
>
> Reserved NAL units – can the number space be extended.
>
>
> Do we allow mixed modes where some layers are mode A and others are  
> mode B. This will also need SDP support.
>
>
> Do we allow MTAPs for mode A, for example in order to aggregate the  
> filler NAL units with succeeding NAL units.
>
>
> Next phase
>
>
>
> Update the SVC payload specification to include the consensus  
> specifying the different modes (terms and text explaining the  
> relations to RFC 3984). Update the specific sections 8.1.1 and 8.1.2.
>
>
>
> The design team will continue with the meetings in order to address  
> the open issues from the email and the ones in the latest draft.
>
>
>