Re: [rtcweb] H.261

Lots of uses will be 1:1 calls, and maybe 30% fallback applies in this
case.  My use of WebRTC involves 1:many group calls in the browser with an
MCU.  For 1:many, the options are 1) fallback to common codec and 2)
transcode.  So, for 1:many we can say that the chance of using the fallback
codec is 100%.  Assuming IE and Safari actually ship WebRTC.

On Thu, Nov 21, 2013 at 10:11 PM, Steve Kann <stevek@stevek.com> wrote:

>
> Mo,
>
> I think we all agree that choosing H.264 or VP8 would be better, but it is
> clear that neither option today has consensus.    Circumstances could
> change in the future, but it seems that OpenH264 was not enough to change
> that circumstance.
>
> I think that where your scenario might go astray is that users won’t
> associate their poor experience with “WebRTC”, or “that web stuff” — they
> will associate it with the brand of the service which they are using at the
> time.
>
> So, for example, if Facebook builds video chat using WebRTC, and they do
> no transcoding, 30% of users might associate their poor video with
> Facebook, but most of them won’t call it “that web shit” — they would say
> Facebook video sucks.
>
> Of course, Facebook could decide to transcode 30% of the time, in which
> case the user would have a different experience.
>
> Facebook obviously just being used as an example service which might
> implement WebRTC video.
>
> -SteveK
>
>
>
> From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
> Date: Thursday, November 21, 2013 at 9:17 PM
> To: Basil Mohamed Gohar <basilgohar@librevideo.org>
> Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
> Subject: [rtcweb] H.261
>
> On 11/21/13 12:48, Basil Mohamed Gohar <basilgohar@librevideo.org> wrote:
>
> Has anyone actually objected to H.261 being the one MTI codec [...] ?
>
>
> Assume this wins and all obey. Chrome does H.261+VP8, Firefox does
> H.261+H.264+VP8, IE does H.261+H.264, Safari does H.261+H.264. According to
> various (incredibly extrapolated, possibly inaccurate and sometimes
> conflicting) sources [1] on who uses what browser, the chance of H.261
> fallback is a whopping 30% [2]. Not the minor insignificant case some had
> assumed.
>
> How will these users react to H.261 QCIF/CIF compared to what they use
> today, say Skype for example? "This web shit really sucks. I’m going back
> to Skype and never trying it again." Is that the first (and perhaps last)
> impression we want from users that try webrtc? Those arguing crappy video
> is better than no video are ignoring the critical importance of first
> impressions. While some may accept crappy video as usable, many more may be
> permanently turned off and tune out even faster than if they got only
> (good) audio. It’s not as if webrtc is the only game in town. Users have
> options, so it needs to be competitive with competitive technology which
> has already set the bar.
>
> We previously narrowed the options down to H.264 and VP8 for good reasons
> over the course of this excruciatingly long decision. Reopening discarded
> tangents like H.261 does not move us forward as a workgroup, and certainly
> does not move webrtc forward as a technology.
>
> Mo
>
> [1] http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
> [2] H.261 fallback % = 2 x VP8-only% x H.264-only% = 2 x Chrome% x (IE% +
> Safari%)
>
> _______________________________________________ rtcweb mailing list
> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>