Re: [rtcweb] H.261

[Hrishikesh Kulkarni <[e-mail]>]

In that case the source endpoint/browser needs the bandwidth/compute to
produce many encode streams (different codecs/bitrate). I would rather the
MCU handle the transcoding/transrating.



On Wed, Nov 27, 2013 at 12:25 PM, Leon Geyser <[e-mail]> wrote:

> 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 <[e-mail]>wrote:
>
>> On Fri, Nov 22, 2013 at 10:23 PM, 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.
>>>
>>
>> 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, <[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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>