On 04/13/11 13:35, Stefan Håkansson LK wrote:
-----Original Message-----
From: Ian Hickson [mailto:i...@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.
