Greetings to all.
I agree with this approach. In the context of the applications we are discussing MST does not appear to be relevant.
The IETF SVC draft does assume some sort of ability to exchange information to select what's called an operation point, and I think it would be useful to be able to do the same here.
I also agree that the semantics for the scalable structure of the bitstream should be that of the stream that will be transmitted, and not what the receiver can decode.
I will be preparing a contribution as a follow up to what is described in COM16-C293-E (Oct. 2009) along those lines.
Best regards.
-- Alex Eleftheriadis alex@vidyo.com
On Jun 28, 2010, at 4:24 PM, stephen botzko wrote:
As the chair of the Q1 SVC Adhoc Group, I have meet informally with several folks, including Vidyo and Tandberg.
Since the IETF SVC draft is now moving into the RFC editor's queue, it is an appropriate time to start working on ITU-T signaling.
There is general consensus that H.32x systems should support the SST mode of SVC that is specified in the current IETF draft. Although Radvision suggested last year that the MST mode also would be required, there seems to be little support for that requirement. The MST mode is intended for multicast, and is considerably more complex than SST.
There is language in H.323 (Annex B) on the use of layered codecs. This text seems more applicable to MST than SST, since SST is sent as a single RTP session. Some normative statements (for instance the way timestamps of the various layers are coordinated) appears to be incompatible with the IETF SVC draft. We also note that there is an analogous RFC in the IETF which also defines the use of layered codecs. This signaling was not employed in the SVC draft.
Athough the Annex B text should be reviewed more carefully, there is general consensus that simple interworking through H.32x<->SIP gateways and in multi-protocol conference bridges is more important than continuing the use of the existing Annex B procedures.
There is also general consensus that attempting to precisely define the various combinations of layers that a receiver is capable of receiving is very complex, and should not be attempted in the signaling.Polycom at least sees the value in being able to actively negotiate which layers are being sent, in a way that is compatible with the current IETF draft. As chair, I believe that most others also support this view. Certainly no one has objected to including this capability. One way this could be accomplished in H.241, is to combine a simple SVC profile capability with a layer negotiation procedure that would be analogous to the set submode procedures.
Please do respond (either to this list or to me personally) on this topic, especially if you have a different view on the topics above, or if you see additional requirements that are not included. I am not planning to hold an audio conference call at this time, but if people see a need for this I will schedule one.
Stephen Botzko Polycom