Re: [rtcweb] H.261

Why not just run the codec at the same bitrates that the other codecs would
of been using anyway? That wouldn't increase the costs of bandwidth.

On 27 November 2013 08:39, Hrishikesh Kulkarni <rishi@turtleyogi.com> wrote:

> On Fri, Nov 22, 2013 at 10:23 PM, Justin Uberti <juberti@google.com>wrote:
>
>> For 1:many with MCU, I don't understand why you wouldn't do #2, i.e.
>> transcode. As stated earlier, the bandwidth costs of using an inefficient
>> codec (which any MCU service will incur) exceed the CPU cost of transcode.
>>
>
> Good point on bandwidth costs. But you need to transcode if the decoding
> endpoints/browsers dont support the codec or the bitrate of the source.
> This applies to audio and video. If the source video is 720p@800kbpswhich could then "transrated" into multiple bitrates at 500kbps or
> downsized to 480p@300kbps. We did this for audio when Chrome was on isac
> and Firefox was on opus.
>
>
>>
>>
>> On Fri, Nov 22, 2013 at 4:47 AM, <bryandonnovan@gmail.com> wrote:
>>
>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>