Re: [rtcweb] VP8 / H.264 conversion without transcoding

Cullen Jennings <> Thu, 21 November 2013 18:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CECE61AE1CE for <>; Thu, 21 Nov 2013 10:45:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id In0zBgryVmWs for <>; Thu, 21 Nov 2013 10:45:34 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0C9291AE0A0 for <>; Thu, 21 Nov 2013 10:45:34 -0800 (PST)
Received: from (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id A7947509B5; Thu, 21 Nov 2013 13:45:26 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Cullen Jennings <>
In-Reply-To: <>
Date: Thu, 21 Nov 2013 10:46:02 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>, <> <>
To: Bossiel <>
X-Mailer: Apple Mail (2.1510)
Subject: Re: [rtcweb] VP8 / H.264 conversion without transcoding
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Nov 2013 18:45:36 -0000

It's a cool demo and I talked to the team that did it. This is only possible because VP8 and H.264 are very similar codecs. The idea is to not redo the motion vector computations or the DCT but just reuse the values from one format in the other since they are the same. They hope that this can provide reduce the CPU by 1/3 from a full decode then re-encode. It also help reduce loss of quality for video. Other people have talked about this idea over the years and many people think it can give a 2 to 3 speed up so that seems consistent with their goals. 

It still requires the same bandwidth, and has similar other impacts. I can not see any way that it would not require MPEG-LA IPR for 264. 

On Nov 21, 2013, at 6:27 AM, Mo Zanaty (mzanaty) <> wrote:

> This probably refers to an intelligent transcoder versus a brute force transcoder. An intelligent transcoder harvests more data during decoding than just the raw output pixels, and uses this extra data to ease encoding. Data like block partitions, motion vectors, intra modes, quantization parameters, etc.
> This is common for common conversions, like MPEG2 to H.264. VP8 and H.264 are much closer formats, so this can significantly improve transcoder performance.
> However, this is strictly a performance optimization, with no impact on IPR or licensing issues.
> Mo
> On Nov 21, 2013, at 2:51 AM, "Bossiel" <> wrote:
> This could be true if they can also walk on water and change it into wine.
> To be serious, no it's not possible.
> Mamadou
> Sent from my iPhone
> On Nov 21, 2013, at 3:13, Gili <> wrote:
>> Hi,
>> I'm at the WebRTC World conference. If I understood correctly, Zingaya just demoed what they claim is a VP8 to H.264 bridge that converts the video without transcoding. My interpretation is that they convert the surrounding packet format without re-encoding the actual video. Someone who understands codec internals (I don't) might want to validate this claim, because it could have a significant impact on the MTI debate.
>> It sounds far fetched, but imagine the possibilities:
>> 	• If the video is not being re-encoded, do H.264 royalties apply?
>> 	• If the conversion is really cheap, is it feasible to connect a H.264 peer to a VP8 peer and have one of them convert in-line (no MCU)?
>> Gili
>> _______________________________________________
>> rtcweb mailing list
> _______________________________________________
> rtcweb mailing list
> _______________________________________________
> rtcweb mailing list