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

Mohammed Raad <mohammedsraad@raadtech.com> Thu, 21 November 2013 20:32 UTC

Return-Path: <mohammedsraad@raadtech.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 C1F1F1AE291 for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 12:32:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 Zkybqm_YhIOd for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 12:32:21 -0800 (PST)
Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 182AA1AE27F for <rtcweb@ietf.org>; Thu, 21 Nov 2013 12:32:20 -0800 (PST)
Received: by mail-wg0-f45.google.com with SMTP id a1so281390wgh.12 for <rtcweb@ietf.org>; Thu, 21 Nov 2013 12:32:13 -0800 (PST)
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:date :message-id:subject:from:to:cc:content-type; bh=hzdRETZHS2spv7/m3HFk/uz85nS/Rk+mPu7B9qW+WHY=; b=T+JZvf2h6YwI2wHraGrIcn7d9zfoJiLY6iPrI9cXuhvyQUg0yGW3yFuyWghlFacMc1 E48M6PSqymCze3bp0OpZJEQGtCr5K9l/258L1DGT0U6LEq23/WL6pJVJOZ+fhanA38nA /TaY6uHDieBmS4pBLeOM0TM+vSLyVjPJmci1jC1dh1fk7PZDd7IyDohEKnbj/ITZGSGf SBnPWQ+vHgYxIMynv4ieajNuLBFb/TA8gUykI76jGWyu4sKSkiVdoZSn8Ox2b5fvsaPk 3JmjOt2q2r+Fd/K7bw7a3d7zrP1brfC8YfXBKMoGM2SzMouqdMo4bELQM68wrdzZ1u+U 6UwA==
X-Gm-Message-State: ALoCoQlOIFu/EKCO1+DGUilP4Bt0fvAe0FqMtsMt2UuWsxigHq6Aqkzs1Dy6ADra3+lUgjNaqwyy
MIME-Version: 1.0
X-Received: by 10.194.219.1 with SMTP id pk1mr7088204wjc.36.1385065933870; Thu, 21 Nov 2013 12:32:13 -0800 (PST)
Received: by 10.194.179.166 with HTTP; Thu, 21 Nov 2013 12:32:13 -0800 (PST)
Received: by 10.194.179.166 with HTTP; Thu, 21 Nov 2013 12:32:13 -0800 (PST)
In-Reply-To: <CAOJ7v-1bCe7fEiDgnxhpN5TRV+09pz3dZPhUPXA5G5UJRA+Zjg@mail.gmail.com>
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> <CAOJ7v-1bCe7fEiDgnxhpN5TRV+09pz3dZPhUPXA5G5UJRA+Zjg@mail.gmail.com>
Date: Fri, 22 Nov 2013 07:32:13 +1100
Message-ID: <CA+E6M0=-9czNW3G3N_nQG1z8tBPsD9MFaSR1jEcyjoLgfT_J1Q@mail.gmail.com>
From: Mohammed Raad <mohammedsraad@raadtech.com>
To: Justin Uberti <juberti@google.com>
Content-Type: multipart/alternative; boundary=001a11c1a2f0fab4c904ebb5cac5
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:32:25 -0000

There seems to be a misunderstanding, transcoding really only belongs at
the service provider level. If you have both codecs available there is no
need for it. Also you could simply have one codec with both encoder and
decoder parts and the other with only decoder on your device. That would
mean you dont need transcoding and you dont have both encoders.

Mohammed
On 21 Nov 2013 22:25, "Justin Uberti" <juberti@google.com>; wrote:

> 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
>>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>