Re: [rtcweb] Alternative Proposal for Dynamic Codec Parameter Change (Was: Re: Resolution negotiation - a contribution)

[Magnus Westerlund <[e-mail]>]

On 2012-04-25 05:20, Justin Uberti wrote:
> On Tue, Apr 24, 2012 at 10:25 AM, Magnus Westerlund
> <[e-mail] <mailto:[e-mail]>>
> wrote:
> 
>     A) Using COP and using SDP based signaling for the dynamic changes are
>     two quite different models in relation to how the interaction happens.
> 
>     For COP this all happens in the browser, normally initiated by the
>     browser's own determination that a COP request or notification is
>     needed. Harald's proposal appears to require that the JS initiate a
>     renegotiation. This puts a requirement on the implementation to listen
>     to the correct callbacks to know when changes happens, such as window
>     resize. To my knowledge there are not yet any proposals for how the
>     browser can initiate a JSEP renegotiation.
> 
> 
> Maybe I misunderstand what you are saying, but the application will
> definitely know when the browser size changes, and can then trigger a
> JSEP renegotiation by calling createOffer and shipping it off.

Yes, they can but that requires them to write code to do this. With COP
the browser can do it and it works well for all applications, not only
the ones that have implementors that are aware of the need to do this.

I am proposing a mechanism that makes the default behavior if you care
nothing about controlling or optimizing this behavior in your JS to be
good. In addition JS that wants to control it can affect the behavior
through generic mechanisms, such as controlling the video element. And
if clear need is shown and some functionality is missing, W3C can create
an API to provide explicit control.

> 
> I have the opposite concern - how can the browser know when the
> application makes a change, for instance to display a participant in a
> large view versus a small view? This may be possible if using a <video/>
> for display, but I don't think it will be possible when using WebGL for
> rendering, where the size of the view will be dictated only by the
> geometry of the scene.

What I understand from my colleagues is that all rendering of video have
to go through a video element, even if not displayed directly. Thus the
application can control the size of the video element used and possibly
consumed by WebGL to be included in rendering. Thus the application will
have control over this even when COP is being used.

Can you be more specific on any particular usage that you think would
have issues?



> 
>     But I am worried that using SDP and with an API that requires the
>     application to listen for triggers that could benefit from a codec
>     parameter renegotiation. This will likely only result in good behavior
>     for the JS application implementors that are really good and find out
>     what listeners and what signaling tricks are needed with JSEP to get
>     good performance. I would much rather prefer good behavior by default in
>     simple applications, i.e. using the default behavior that the browser
>     implementor have put in.
> 
> 
> The issue here is that this behavior needs to be sufficiently specified,
> or else we will have many different behaviors, none of which can be
> fully overridden by the app. I worry this will make life hard for people
> trying to develop sophisticated apps.


I agree that it needs to be clearly specified. But COP appears to be
less prone to complete failures by using target values. Then at least it
will receive video that can be used, even if not optimal. imageattr can
result in failures in the negotiation requiring at minimal a second
round potentially no agreed on acceptable resolution then that is
clearly sub-optimal. That is even without considering involving JS
mainipulating this.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------