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

Mohammed Raad <mohammedsraad@raadtech.com> Thu, 21 November 2013 19:01 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 D37811AE265 for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 11:01:07 -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 EdG8Af_oKHBu for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 11:01:05 -0800 (PST)
Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) by ietfa.amsl.com (Postfix) with ESMTP id E3C631AE264 for <rtcweb@ietf.org>; Thu, 21 Nov 2013 11:01:04 -0800 (PST)
Received: by mail-we0-f174.google.com with SMTP id q58so171535wes.33 for <rtcweb@ietf.org>; Thu, 21 Nov 2013 11:00:57 -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=AjAUKkqbjSaUPJUju9qmSnOY7Kqa7DoGHjQ/KjXZNT8=; b=FTZlIKWFd6S2n2KQ9QaHE3Iq3r/55pp10BAeeyLYPRwsoLidWegm1ifJCJoVL7aaFn /+aZXgaACvwCUjDFRWVu8cDMVFW+d7uoXbaXdpTCyeA2Y2dgcOPQ80aQxFVTBcjhibMZ rNWETs8BmJSooqrOwcz2PB017cvLORzupnBB8to9yNX+mKvJhRTaKDyf0aPoAY0rs+Xh pkGf0xWi0nGMtmDBeHJS6QkT75Fu7INGUmSM+e96LymsrnW26L9E6O51WO0JTfVnq5cz A69m90VhikdGsXtJedeZ2ff8CPO0mRwM48ibGGOF6Rgt0roqwBxkFbQOcZSybiSL1IPk uLeg==
X-Gm-Message-State: ALoCoQm0JAEjekydycTA/DxIe4y7C7w2f7AkbVRnAn8tLSJ9SP9VcfeqOlyXMxvs2t0i4bXrLKSe
MIME-Version: 1.0
X-Received: by 10.194.2.108 with SMTP id 12mr2343913wjt.64.1385060457458; Thu, 21 Nov 2013 11:00:57 -0800 (PST)
Received: by 10.194.179.166 with HTTP; Thu, 21 Nov 2013 11:00:57 -0800 (PST)
Received: by 10.194.179.166 with HTTP; Thu, 21 Nov 2013 11:00:57 -0800 (PST)
In-Reply-To: <E2B29CC6-C499-432C-8242-BD2A506F0BD0@iii.ca>
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>
Date: Fri, 22 Nov 2013 06:00:57 +1100
Message-ID: <CA+E6M0kZkVUKim3_NY18BmwyTviMFc6abBLPYVZ46wbPFM-NdA@mail.gmail.com>
From: Mohammed Raad <mohammedsraad@raadtech.com>
To: Cullen Jennings <fluffy@iii.ca>
Content-Type: multipart/alternative; boundary=047d7b3440da8f45cb04ebb4842f
Cc: 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 19:01:08 -0000

Hi,

Typically "smart" transcoding operates at 50 percent complexity or less. We
did a fair bit of this at Dilithium Networks when I was there. There are
also significant memory and delay savings when one operates on the MB level
instead of the picture level. With regards to IPR, there is a significant
number of current patents in this area that are not in any multi
organization patent pool as far as I know. Transcoding in this way also
provides quality advantages over tandem transcoding.

Obviously the more similar the codecs the more one gains. In the case of
VP8 and AVC CBP, there are significant enough differences in essential
elements such as the way quantization is done to make this kind of
transcoding challenging, but it is possible and the numbers mentioned in
the previous post sound about right.

Mohammed
On 21 Nov 2013 20:45, "Cullen Jennings" <fluffy@iii.ca>; 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
>