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

[Stefan Håkansson LK]

On Wed Apr 13 07:08:21 PDT 2011 Harald Alvestrand wrote
>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.
I think this is an interesting idea. "Don't transmit until someone
consumes". I guess some assessment should be made of how long the extra
wait would be - but the ICE "channel" is available so maybe it would not
be too long.