Re: [rtcweb] H.261

[cowwoc <[e-mail]>]

Stefan,

You are beating a dead horse. No one is arguing that H.261 is 
technically superior to H.264. I'll repeat what I just posted on another 
thread:

Just so there is no confusion: if you manage to convince us that X is 
"strictly better" than H.261 then I'd jump on board. I was trying to 
explain that many people are trying to remove H.261 as an option by 
explaining how bad it is. Going down this road won't change our minds 
because we already agree that it is a shitty codec.

The only way to convince us that X is "strictly better" than H.261 is to 
talk about X (not H.261) and demonstrate that it meets our IPR 
requirements. Do that, and you will have my vote (and probably that of 
others).

Gili

On 23/11/2013 11:29 PM, Stefan Slivinski wrote:
> I don't want to make any assumptions as to why their particular use case failed at 20+ participants.  Maybe it was bandwidth related, maybe it was because intel quicksync doesn't support VP8.  I don't know and I'm not going to speculate.  What I do know is intel quicksync is capable of decoding H.264 at 4K without breaking a sweat.  4K is more than 80x (yes, eighty times) the resolution of H.261.  So H.261 isn't likely to have helped them here.
>
> What few seem to acknowledge is that companies like intel, TI, qualcomm, broadcom (just to name a few) have spent hundreds of millions (if not billions) of dollars adding hardware accelerate for H.264 to their chips.  Purpose designed hardware will always be faster and require less power than software implementations and no one is spending anything supporting H.261 hardware acceleration.
>
> H.261 does not have any technical advantage whether it be bitrate, performance, power consumption or otherwise over H.264 on any modern media processor
>
> -----Original Message-----
> From: rtcweb [mailto:[e-mail]] On Behalf Of cowwoc
> Sent: Friday, November 22, 2013 11:23 PM
> To: [e-mail]
> Subject: Re: [rtcweb] H.261
>
> Stefan,
>
> At the conference, they mentioned that you cannot implement online video classes (with 20+ participants) unless you reduce the resolution and frame rate of non-speakering participants. Meaning, even without having to do any transcoding (they use VP8 across the board) there is insufficient bandwidth and CPU to handle 20 incoming video streams at HD resolutions. So what you do is host non-speakers at tiny resolutions and
> 3 fps.
>
> H.261 could handle those non-speakers just fine (in fact, it would be preferable as it reduces CPU usage). Furthermore, if you chose to transcode, you'd be dealing with tiny resolutions and 3fps. In both cases, the use of H.261 or transcoding is not the bottleneck.
>
> Gili
>
> On 22/11/2013 8:42 PM, Stefan Slivinski wrote:
>> Just for fun, let's play out the H.261 scenario as the great savior of webrtc that some claim it is:
>>
>> Let's say through some divine miracle we manage to all agree to make H.261 the one and only MTI codec.  The rationale being of course that no one will ever use it because it is of course terrible, but we need it to get around those pesky patent/license terms with VP8/H.264 respectively.
>>
>> Alright fast forward, Chrome adds H.261 but continues to use VP8.  IE uses H.261 and H.264, Safari uses H.261 and H.264 and Firefox does H.261, H.264 and VP8.  So far so good.  Chrome can talk using VP8 to Firefox, Safari can talk H.264 to IE, Firefox can either H.264 or VP8 to everyone.  As long as Chrome users don't try to call IE or Safari, we're in good shape, otherwise we need to transcode using some undefined cloud based transcoder service or just use H.261.
>>
>> So we're still in good shape.  Now let's consider the multiway case.  I heard a use case at the conference on Tuesday where a university was using webrtc to enable video online classes.  So let's assume there are 20 people in the class.  19 people in the class love Chrome, so they join the class from chrome and are all sending each other VP8.  But of course there's always one person that has to be difficult and they decide they prefer IE.  So what now?   Well the IE person doesn't understand any of the 19 VP8 streams and the 19 chrome users don't understand the 1 H.264 stream.  So we can now utilize that same undefined cloud transcoding service to convert each of the 19 VP8 streams to H.264 and the 1 H.264 stream to VP8....or we can use H.261.
>>
>> My guess is H.261 is going to get used a lot more than anyone thinks.
>>
>> -----Original Message-----
>> From: rtcweb [mailto:[e-mail]] On Behalf Of Adam Roach
>> Sent: Friday, November 22, 2013 5:37 PM
>> To: Ron; [e-mail]
>> Subject: Re: [rtcweb] H.261
>>
>> On 11/22/13 18:35, Ron wrote:
>>> The whole point of many distros is to supply binaries, often built
>>> many times for many different system architectures.
>> And the overwhelming majority of these do so by including a list of repositories from which the binaries can be downloaded.
>>
>> I'm 100% confident that we could convince Cisco to serve up RPMs, DPKGs, and whatever else is needed for these distros, targeting whatever platforms are required. Now, whether we can get the distro maintainers to add a single line to their list of repos -- because that's all it would take -- is a different issue. But at that point, it's just a matter of the distro maintainers being intransigent rather than any real technical or legal barrier.
>>
>> /a
>> _______________________________________________
>> 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