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

"Mo Zanaty (mzanaty)" <mzanaty@cisco.com> Mon, 04 November 2013 18:52 UTC

Return-Path: <mzanaty@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08CA211E81C4 for <rtcweb@ietfa.amsl.com>; Mon, 4 Nov 2013 10:52:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTDL888pStaA for <rtcweb@ietfa.amsl.com>; Mon, 4 Nov 2013 10:52:50 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 72E3E11E8117 for <rtcweb@ietf.org>; Mon, 4 Nov 2013 10:52:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3199; q=dns/txt; s=iport; t=1383591170; x=1384800770; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=QoO/wBv0rJjhGWIGR1Zb/L+Y5AG5UVA/AGfopdBYv14=; b=lgrQYNp81CruPMlZak1JqPKWc2woFQ4xn8ZHnb7uZIWE85CdWWmI5BIU AQ33DHkLEdvVKWTlMAIdF38Q7L1ZSCCoG+2EyS1T+U8lHyJDZApVzSyMG GgktvzJaWUN44MMdRxxwbp1sp6ocTUf/VhoYeRHQr71gF+1/WPHpne2fN I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhMFALLrd1KtJV2a/2dsb2JhbABZgwc4U75zS4ErFnSCJQEBAQMBAQEBC1cJEA0BCBhVCyUCBAESFIdnBg2+TI8lDS2ELgOYCoEvkFqBaIE+gio
X-IronPort-AV: E=Sophos;i="4.93,634,1378857600"; d="scan'208";a="277506668"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 04 Nov 2013 18:52:49 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA4IqnYC030766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Nov 2013 18:52:49 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 12:52:49 -0600
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: Basil Mohamed Gohar <basilgohar@librevideo.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8
Thread-Index: AQHO2Y8Or0eCM6H8SkuQfdXivrBnVQ==
Date: Mon, 4 Nov 2013 18:52:49 +0000
Message-ID: <CE9D4AC9.1B3F5%mzanaty@cisco.com>
In-Reply-To: <5277DF1C.8080207@librevideo.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.8.130913
x-originating-ip: [10.82.254.33]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <7ACE3E8CD3113542A8FD29AAB05F9282@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Nov 2013 18:52:55 -0000

> 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 <basilgohar@librevideo.org>
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
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb