Re: [rtcweb] H.261

[Leon Geyser <[e-mail]>]

If we fallback to a software H.261 encoder/decoder then will it really use
so much CPU that devices will be unusable or the battery will deplete
early? I didn't know that H.261 was so CPU intensive...
I also agree with Ron that we shouldn't make a codec like H.264 mandatory
that will anyway be obsoleted by the next best thing in the future.


On 24 November 2013 06:29, Stefan Slivinski <[e-mail]> 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
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>