- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Sun, 17 Apr 2011 15:46:50 +0200
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.
Received on Sunday, 17 April 2011 06:46:50 UTC