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

Justin Uberti <juberti@google.com> Thu, 21 November 2013 20:25 UTC

Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A481AE1BC for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 12:25:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzJjX-fL5yHk for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 12:25:54 -0800 (PST)
Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE381AE29B for <rtcweb@ietf.org>; Thu, 21 Nov 2013 12:25:54 -0800 (PST)
Received: by mail-vb0-f48.google.com with SMTP id x16so202263vbf.7 for <rtcweb@ietf.org>; Thu, 21 Nov 2013 12:25:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Jh6nZg38CQm3Qgf1absqx7McW2XtH88LfNBw48/vfBk=; b=WkULlRWB4Zf/z8WoCs5kItryGdPPD7MLDPIskbDgZFu2gP/8BsgixE+XYNx4yiyfX4 riHrIL8ZHe7Fak6DemOxWWyVyX+p/XvokQPwg4EyVf8BFUCIbhS5rYPgt3Wr30tJ6DqC c4BaCZIg4uJNovMX1+KR7zVu+33+fNC9YKxo/6m8fnwCgeYZCXwacjv2HsAvRp9wWBFH PYErMQBS2LB9fS73aYBsGJBwDUPhq6WFYgFiyxAYye1FFePGEqg2IKrKpFVUhsLoq1ZK kC46QJShDLlSTvJNN1frftwgvC/LBNfNO0q6emtLKjJVAcKmF+pJADBO/wRMleChACGe KpUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Jh6nZg38CQm3Qgf1absqx7McW2XtH88LfNBw48/vfBk=; b=d3FBpcHubivoBEKPNDFm2MvIm08iCdmAySOU83k5begopSganaie4iURTwxgzyNDYv GPR76dTobPEZUcX1gI3n6Mf9CFK+098AnmxXnSlI36zU7AzXNCcI/1fdOlKSKzXC3KGw 8xK0+dtp/GjlAOHzZjOeCSszl6sK6jZni+1mIPE0YlbZgRYPaFUHjnILhubna7M+29KE Qqy1utaVs37MyLdfziIavb11Ix5erblrIgXC7J5RVAuN2uLRjX+NA6E16e1rXo5VhW5r IdKrUkMrPjel3UdZoVgLk7jd2niwji8DSh91tVV4Jj9iFgSexyeguHYti9RU/ILAsZv3 rwXQ==
X-Gm-Message-State: ALoCoQkQeQIBeXYZ5p+uLZvRGcMxIWyrwF5gS8DILjMQ86Wll7M4SUVy+pZnhMbaNMLvxzYFJWnQRoDVaiBT4AQu3w1VMrSOIUDpfpN4aXCt1nX5mOlvD6lDPU4cIHm5Ut2WMmN5u+WgNc6DqnRXZIQ0t7JY7XV/kLpF8GTlnCW5pFvbh7dI/YeslVzLBuB8DtUZHtKe1GMh
X-Received: by 10.220.199.5 with SMTP id eq5mr7539674vcb.16.1385065547293; Thu, 21 Nov 2013 12:25:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Thu, 21 Nov 2013 12:25:27 -0800 (PST)
In-Reply-To: <528E5E3C.70008@bbs.darktech.org>
References: <528D6C63.7050607@bbs.darktech.org> <13BED03E-6853-4E49-BCCE-1FFB39571D36@yahoo.fr> <5A2BC34D-FE4D-4420-B52F-729087815F37@cisco.com> <E2B29CC6-C499-432C-8242-BD2A506F0BD0@iii.ca> <528E5E3C.70008@bbs.darktech.org>
From: Justin Uberti <juberti@google.com>
Date: Thu, 21 Nov 2013 12:25:27 -0800
Message-ID: <CAOJ7v-1bCe7fEiDgnxhpN5TRV+09pz3dZPhUPXA5G5UJRA+Zjg@mail.gmail.com>
To: Gili <cowwoc@bbs.darktech.org>
Content-Type: multipart/alternative; boundary=047d7b5db26af001f104ebb5b39c
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] VP8 / H.264 conversion without transcoding
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 21 Nov 2013 20:25:58 -0000

Even if we could do this conversion in real-time on a mobile device...
since you have both codecs present, why not just send the desired format in
the first place?


On Thu, Nov 21, 2013 at 11:25 AM, Gili <cowwoc@bbs.darktech.org>; wrote:

> Cullen,
>
> Thanks for the background information. I also remember them saying that we
> are only at the beginning of this process and that they expect more
> performance improvements in the upcoming months.
>
> It would be nice to gauge how far we are from being able to do this kind
> of conversion in real-time on a mobile device (I suspect very far, but it's
> worth asking). This has implications for P2P interoperability between VP8
> and H.264 peers without a middleman.
>
> Gili
>
>
> On 21/11/2013 10:46 AM, Cullen Jennings wrote:
>
>> 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) <mzanaty@cisco.com>;
>> 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" <bossiel@yahoo.fr>; 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 <cowwoc@bbs.darktech.org>; 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@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>