[rtcweb] VP8 / H.264 conversion without transcoding

Gili <cowwoc@bbs.darktech.org> Thu, 21 November 2013 02:14 UTC

Return-Path: <cowwoc@bbs.darktech.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id B0D961ADBCC for <rtcweb@ietfa.amsl.com>; Wed, 20 Nov 2013 18:14:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id egyKIfveWUlf for <rtcweb@ietfa.amsl.com>; Wed, 20 Nov 2013 18:14:09 -0800 (PST)
Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 10BF11ACC88 for <rtcweb@ietf.org>; Wed, 20 Nov 2013 18:14:09 -0800 (PST)
Received: by mail-pd0-f177.google.com with SMTP id q10so5266478pdj.36 for <rtcweb@ietf.org>; Wed, 20 Nov 2013 18:14:01 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type; bh=lC9LmxIWjgseeYfh7OBpJaBuOGSJ6xy+Ai9PMD+5oWs=; b=U/nPMjCRox22WvqxymaVMBTNzS38viCaBYjHle08Sd10eYnXoJn5shD4783ecC18KE D9fKawzc+rQkx/Cna5+BiJfHrvSE1hYnboSf2Tio9VDDy9pg5102euqCRhvwxyiX9Bl3 RhlpoU9lLfl4j+zP3INYblg3Im7OQ9Y75WoriXF/OFo3qda6x1F2kVyv+lAcA5bDEHym 66slp70Myzzx0J4cuEH8gy39OXt4nPVxsSUjLcWKi470ACheZll2PfCa4FT7j5wFeGK3 XuPgmUic63LVV47ZB2sfQlURxCAFpnfbaLFhTwa+qgXHApfFNCl7suqAj67xssd9q8+y 44sw==
X-Gm-Message-State: ALoCoQkTciEGWK7k9yHK2CEJEzVurBjO0i0B0Mfp8MqBNOTe+YX7h1TKp5kk0rup9iTHBuxxGdrX
X-Received: by with SMTP id tr1mr3668507pab.163.1385000041371; Wed, 20 Nov 2013 18:14:01 -0800 (PST)
Received: from [] (sccc-66-78-236-243.smartcity.com. []) by mx.google.com with ESMTPSA id tu6sm41387506pbc.41.2013. for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Nov 2013 18:14:00 -0800 (PST)
Message-ID: <528D6C63.7050607@bbs.darktech.org>
Date: Wed, 20 Nov 2013 18:13:55 -0800
From: Gili <cowwoc@bbs.darktech.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: rtcweb@ietf.org
Content-Type: multipart/alternative; boundary="------------090608080602030802010303"
Subject: [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 02:14:10 -0000


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:

 1. If the video is not being re-encoded, do H.264 royalties apply?
 2. 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)?