Subject: Re: [rtcweb] Support of video with different resolutions

From: Stefan Håkansson LK <[email-masked]>
Date: Wed, 2 Jan 2013 18:15:49 +0100

On 2012-12-21 16:40, Bernard Aboba wrote:
> Christer said:
>
> "If we want to support content sent in different resolutions, the
> question is whether we need to mandate the browser to support a specific
>
> mechanism.  As shown in the note, there are basically 3 mechanisms: SVC,
> simulcast and “local transcoding”."
>
>
> [BA] One of the reasons that "no MTI codec proposal supports SVC" is
> that by definition mandates apply to a wide range of situations, from a
> browser on a mobile device to a desktop scenario involving exchange of
> multiple streams at high bandwidth.  This leads to mandates focusing on
> the "lowest common denominator", which may make it difficult mandate
> browser support for encoding of SVC or simulcast.
>
>
> SVC supports multiple scalability mechanisms:  temporal, spatial and
> quality.  Temporal is the most widely implemented in software (at least
> for H.264/SVC), although there is an open source implementation that
> supports all modes.  In hardware, support for spatial or quality scaling
> is not common.  As a result, a browser on a mobile device could have
> difficulty complying with a mandate to support spatial scaling within
> the encoder.
>
>
> Although cameras on mobile devices are growing increasingly capable,
> unlimited usage LTE plans are still not ubiquitous, which puts a damper
> on sending of simulcast from mobile devices.

I think differently. If you don't support simulcast, you'd send just the 
high resolution stream. Sending a low resolution version of the same 
content does not add that much in terms of transmitted bits.

And, if we get some nice way to signal pause/resume with really short 
latency simulcast could even save bandwidth since it might be quite 
common that only the low resolution version is actually being streamed 
for a large portion of the session.

Another way to look at this is that we already have the following 
requirement:

"F11             The browser MUST be able to transmit streams and
                    data to several peers concurrently.",

and presumably there would be independent rate control for these streams 
(since they may experience different network conditions),

simulcast is in  sense just a special case (the two other peer's are the 
same endpoint).

I would like to see support for simulcast (which in combination with 
processing such as that Randell talks about would enable a nice 
multiparty experience even if SVC is not used).

>
>
> Given the above, it seems hard to mandate any of the above options.
>
>
>
>
>
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 2 Jan 2013 10:32:21 -0800

> simulcast is in  sense just a special case (the two other peer's are the
While I agree that you could model it this way, I think it may be more
appropriate to treat simulcast as its own case, rather than as a special
case of the multiple peer.

Consider this pair of scenarios:

Case one:
There is one endpoint, Zelda, which is sending media via Turn service to
two hosts behind the same NAT (let's call them Scott and Edouard).   There
is independent rate control for the streams sending this media.

Case two:
There is an endpoint, Zelda, which is sending simulcast media to Scott,
which is using a Turn service and is behind a NAT.

Isn't managing fairness going to be potentially very different between case
one and case two?

regards,

Ted

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 3 Jan 2013 00:49:59 +0100

On 2013-01-02 19:32, Ted Hardie wrote:
> On Wed, Jan 2, 2013 at 9:15 AM, Stefan Håkansson LK
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     and presumably there would be independent rate control for these
>     streams (since they may experience different network conditions),
>
>     simulcast is in  sense just a special case (the two other peer's are
>     the same endpoint).
>
>

I agree fully. I was just trying to say that we already have 
requirements covering a large part of what is needed for simulcast, so 
simulcast would not require much more in terms of implementation than 
what we already have agreement on.

But it should be its own case. Apart from the point you make about rate 
control, there is also a tighter requirement on synchronization between 
two versions of the same stream in a simulcast case than what would 
(likely) be needed in a multiple peer case.

> two hosts behind the same NAT (let's call them Scott and Edouard).
> There is independent rate control for the streams sending this media.
>
> Case two:
> Isn't managing fairness going to be potentially very different between
> case one and case two?
>
> regards,
>
> Ted