Re: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-multistream-and-simulcast-00.txt

[Jonathan Lennox <[e-mail]>]

On Jul 5, 2011, at 6:54 AM, Magnus Westerlund wrote:

> WG,
> 
> As an individual Bo Burman and I have written this internet draft that
> discusses multistream and simulcast issues and proposes a set of
> extensions to resolve the issues. Feedback is much appreciated.


Hi, Magnus.

Thank you for writing this draft; I think multi-stream is a very important area of RTP, one that's hasn't had enough attention paid to it.

The draft discusses a number of different issues: multi-stream, simulcast, RTX, FEC, etc., but seems to assume that these are separate-but-related problems that can be solved independently, possibly with different solutions to the different problems.

I don't believe that this is the case; instead, I believe that in practice you will end up with sessions carrying multiple sources, each of which could be be simulcast, with RTX and FEC being used independently for any or all of the simulcast streams.  Thus we need one solution that can handle all these problems at once, including the interactions among them.  (Vidyo has been doing multi-stream with scalable coding for many years.)

As the draft concludes, the multi-stream scenario is best handled by SSRC-multiplexing, as was originally envisioned by RTP.  Given that this is the case, it's not clear to me that it's a good idea to use a separate (and in my opinion, less flexible) mechanism for the specific special case of simulcast.  Instead, given the pressure from groups such as RTCweb to reduce the port consumption of RTP, I'd recommend SSRC-multiplexing across the board.

Note also that in the case of multiple sources which are each independently simulcast, the simulcast structure of different sources could well be different.   (E.g., source A could be available in two resolutions, while source B has only one and source C has three.)  It'd be extremely difficult to map this in session-multiplexed simulcast, whereas for SSRC-multiplexed simulcast it should be no more complex than the single-simulcast-source scenario. 

--
Jonathan Lennox
[e-mail]