Re: [rtcweb] H.261

[[e-mail]]

The point that I was making (perhaps not very clearly) is that in many use
cases, the common codec is much more important than that 30% number would
suggest.  My priority is having an efficient common video codec.  I would
transcode as a last resort.

Also, my concern with transcoding is not cost, but scalability.  I can find
a dedicated server for a couple hundred dollars per month that would give
me 100TB of bandwidth.  If I had to transcode, then I would run out of cpu
cycles long before I ran out of bandwidth.  If I only have to route packets
and transcrypt, then the balance between cpu and bandwidth allows much more
efficient resource utilization.

Perhaps the math on cpu vs bandwidth cost that you are referring to was
based on AWS -- I use dedicated hardware.


On Fri, Nov 22, 2013 at 8:53 AM, Justin Uberti <[e-mail]> 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.
>
>
> On Fri, Nov 22, 2013 at 4:47 AM, <[e-mail]> 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 <[e-mail]> 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)" <[e-mail]>
>>> Date: Thursday, November 21, 2013 at 9:17 PM
>>> To: Basil Mohamed Gohar <[e-mail]>
>>> Cc: "[e-mail]" <[e-mail]>
>>> Subject: [rtcweb] H.261
>>>
>>> On 11/21/13 12:48, Basil Mohamed Gohar <[e-mail]>
>>> 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
>>> [e-mail] https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>