Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8

["Mo Zanaty (mzanaty)" <[e-mail]>]

> ffvp8Šhas no known major problems.

There were indeed problems, some rather severe, like bugs in the ON2
encoder implementation that became enshrined in the bitstream itself and
forced decoders to mirror the ON2 encoder bugs. See ³Practical problems²
in Jason¹s old rant at: http://x264dev.multimedia.cx/archives/377

> xvp8Šstalled

Too bad, it would have likely been a very fast/good vp8 encoder. If you
followed that project, you would learn just how similar vp8 and h.264
truly are. (Hint: the base is x264 not libvpx.)

> many hardware VP8 implementations

True for decoders, not yet for encoders, but the latter will improve over
time. Since app devs don¹t understand how to use hardware codecs (there
are unofficial/hacky ways in Android and iOS, and official ways in Android
4.1+), actual interop has not been widely attempted yet despite hardware
support.

> arguably much more complex, (full) H.264 spec

Agreed, the spec sucks as a practical implementers guide, although some
argue that is not its main purpose. I find it silly to need a separate
implementers guide. Both H.264 and VP8 suffer from this, for opposite
reasons; the H.264 spec is far too verbose, the VP8 spec is far too terse,
essentially making the code the spec. Maybe Daala will strike the right
balance? ;)

Mo


On 11/4/13, 12:53 PM, Basil Mohamed Gohar <[e-mail]>
wrote:

On 11/04/2013 12:47 PM, Mo Zanaty (mzanaty) wrote:
> 
> To be fair, H.264 interop has not been a painless endeavor over the
> years, in part due to multiple profiles. Implementers have worked
> through many issues to achieve the nearly universal interop enjoyed
> today across hundreds or thousands of vendors and implementations. VP8
> should have an easier time, since it doesn¹t have multiple profiles,
> packetization modes, etc. But VP8 will go through some of the same pains
> when many implementations flourish (software and hardware). The pain is
> not felt yet since there are only two vendors (Google and Mozilla) in
> close contact using a shared software implementation.
> 
> Mo

To be even more fair, in fact, there are more than just Google and
Mozilla on the VP8 playing field.  The ffmpeg/libav community(-ies?)
have made a successful implementation of a vp8 decoder (ffvp8) that is
also widely deployed and, to the best of my knowledge, has no known
major problems.

There was also the xvp8 project which, while I believe stalled, was not
due to incompatibilities or challenges, just lack of energy for that
project and motivation.

And there have been many hardware VP8 implementations in silicon across
multiple vendors no less, both for encoding and decoding.

And yes, while H.264 no doubt has a larger market segment, to say Google
and Mozilla are the only two players would not be accurate, and the
design and spec have shown they can be implemented widely and without as
much pain as the, arguably much more complex, (full) H.264 spec.

-- 
Libre Video
http://librevideo.org
_______________________________________________
rtcweb mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtcweb