Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

[Gaelle Martin-Cocher <[e-mail]>]

There was a single hum for the three categories (browser, non-browser, compatible endpoints), right?

That makes a lot of sense for non-browser entities that are in fact WebRTC-compatible enpoints (apps, or gateways or else) to push the burden on the browser vendors as those entities will need to interact with browsers.  Hence "hum"...

I think it would make a lot of sense to have different "hums" or questions for the two different categories.
That will bring clarity on what the "non-browser" yet WebRTC endpoint is, versus what the WebRTC-compatible endpoint is (let aside gateways).
It is not clear to me that we would have had the same results for each category if there was two (or three) different questions.

Gaëlle


-----Original Message-----
From: rtcweb [mailto:[e-mail]] On Behalf Of Timothy B. Terriberry
Sent: Wednesday, December 03, 2014 7:22 PM
To: [e-mail]
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

Gaelle Martin-Cocher wrote:
> a) How can the group composed by a vast majority of non-browser vendors force a decision on browser vendors against their statements?
>
> b)I don't think there was enough discussion on "non-browser" entities. I believe the two topics (browser/non-browser) should have been separated. There was quite a few objections on a non-browser having to implement both codecs, at the meeting and on the list prior to the meeting.

Let me see if I can follow the logic here. There was a "vast majority of non-browser vendors" making this decision, but the overwhelming consensus achieved in the hum in Honolulu does not demonstrate that objections from non-browser vendors are "in the rough".

_______________________________________________
rtcweb mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtcweb