[whatwg] Initial video resolution (Re: PeerConnection feedback))

[Harald Alvestrand]

On 04/13/11 13:35, Stefan Håkansson LK wrote:
>
>
> -----Original Message-----
> From: Ian Hickson [mailto:ian at hixie.ch]
> Sent: den 12 april 2011 04:09
> To: whatwg
> Subject: [whatwg] PeerConnection feedback
>
>> On Tue, 29 Mar 2011, Stefan H kansson LK wrote:
>>>>>>> The web application must be able to define the media format to
>>>>>>> be used for the streams sent to a peer.
>>>>>> Shouldn't this be automatic and renegotiated dynamically via SDP
>>>>>> offer/answer?
>>>>> Yes, this should be (re)negotiated via SDP, but what is unclear is
>>>>> how the SDP is populated based on the application's preferences.
>>>> Why would the Web application have any say on this? Surely the user
>>>> agent is in a better position to know what to negotiate, since it will
>>>> be doing the encoding and decoding itself.
>>> The best format of the coded media being streamed from UA a to UA b
>>> depends on a lot of factors. An obvious one is that the codec used is
>>> supported by both UAs.... As you say much of it can be handled without
>>> any involvement from the application.
>>>
>>> But let's say that the app in UA a does "addStream". The application in
>>> UA b (the same application as in UA a) has two<video>  elements, one
>>> using a large display size, one using a small size. The UAs don't know
>>> in which element the stream will be rendered at this stage (that will be
>>> known first when the app in UA b connects the stream to one of the
>>> elements at "onaddstream"), so I don't understand how the UAs can select
>>> a suitable video resolution without the application giving some input.
>>> (Once the stream is being rendered in an element the situation is
>>> different - then UA b has knowledge about the rendering and could
>>> somehow inform UA a.)
>> I had assumed that the video would at first be sent with some more or less
>> arbitrary dimensions (maybe the native ones), and that the receiving UA
>> would then renegotiate the dimensions once the stream was being displayed
>> somewhere. Since the page can let the user change the<video>  size
>> dynamically, it seems the UA would likely need to be able to do that kind
>> of dynamic update anyway.
> Yeah, maybe that's the way to do it. But I think the media should be sent with
> some sensible default resolution initially. Having a very high resolution could
> congest the network, and a very low would give bad user experience until the
> format has been renegotiated.
One possible initial resolution is 0x0 (no video sent); if the initial 
"addStream" callback is called as soon as the ICE negotiation concludes, 
the video recipient can set up the destination path so that it knows 
what a sensible resolution is, and can signal that back.

Of course, this means that after the session negotiation and the ICE 
negotiation, we have to wait for the resolution negotiation before we 
have any video worth showing.