Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!)

[Tim Panton <[e-mail]>]

On 5 Oct 2011, at 13:51, Stefan Håkansson LK wrote:

> On 2011-10-05 12:03, Tim Panton wrote:
>> It seems to me that by calling WebRTC.SDP.answerFor() - getting the
>> native code
>> to do the 'compatibility matching' you've lost quite a lot of influence
>> over the selection process.
>> Lets say this is a conference app on an android phone - and lets say
>> that the phone supports
>> h 261, h263 and h264 but only has hardware accel for h264....
> 
> To me it seems that the browser (at least the one integrated by the device manufacturer) has a much greater chance of knowing what codecs are HW accelerated than the application - or do you expect a large database where device, version, OS-version, browser, browser version etc. is stored?

I'd expect the app to be able to query the browser - possibly a 'cpu cost' field returned in the list of supported codecs ...

> 
> My preference would rather be that the app hints (as Tim proposed in <http://lists.w3.org/Archives/Public/public-webrtc/2011Oct/0004.html>), the browser proposes (by some kind of offer where the codecs are listed in preference order). If the offers are available to the application (for transport to the other end) it can override it there are objections.

Which to my mind is putting the cart before the horse. The app (as the representative of the user) should take the lead here, not be reduced to
vetoing offers from the all-knowing browser. I know it is largely a philosophical difference, but I think we risk being stuck in a mindset derived from
a world where the core had no access to the user and there was only a single application, so the switch had to do the best it could without any
other input.

Tim.