Re: [rtcweb] Making both VP8 and H264 MTI

Mohammed Raad <> Wed, 06 November 2013 20:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E0FD721E8192 for <>; Wed, 6 Nov 2013 12:34:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.722
X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=-1.254, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, SARE_URI_MEDS=0.842]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cu2jPCPYe3aZ for <>; Wed, 6 Nov 2013 12:33:59 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 58CA521E818A for <>; Wed, 6 Nov 2013 12:33:58 -0800 (PST)
Received: by with SMTP id x12so28159wgg.28 for <>; Wed, 06 Nov 2013 12:33:58 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=C1N2sVBGGnuLT1ci5dkeptsxmYUBKJzAqg6/MyWTsgs=; b=Se4dwon4dsGdwmT9TF6Hf6Is3HWNqQDRVMoHElDKnrJH5rrJiUgC5ESCULezaNmL/E 4xbjYIAjD0GCbcsbK/p0ejY16uZEDKdEVCLa+SXUDT4AD3KUQnZldPioRPXs5jdm1DS1 oB2F+Ov0IUfrOYOOzge6vC6Yd0ENXouqEsSfGDOV9D/DLXOv7woQ26m9qxsdXZl8Cxuk r6KOxcMFPOYdSJGSJtSZZ2uig2+BPBng8rM9a9NaeHEsWmrKsIQzR6++wE5aXEhiXapl Qzm0yemYI6QjhUC4j4y6exol7+NipPJdEHh9A4hvOWGna+d8WzsJ0oVgqzMjF6rh1rM8 Jxqw==
X-Gm-Message-State: ALoCoQl4UGa000rgrfIV1uBV6wLJ2eVk+Rd7/5e9aBQlNxXXGcAytEWAXbpcyaXSF93CAOfJzrvE
MIME-Version: 1.0
X-Received: by with SMTP id m4mr3991723wiw.59.1383770038146; Wed, 06 Nov 2013 12:33:58 -0800 (PST)
Received: by with HTTP; Wed, 6 Nov 2013 12:33:58 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Thu, 7 Nov 2013 07:33:58 +1100
Message-ID: <>
From: Mohammed Raad <>
Content-Type: multipart/alternative; boundary=f46d043c7f069333e404ea88112d
Subject: Re: [rtcweb] Making both VP8 and H264 MTI
X-Mailman-Version: 2.1.12
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: Wed, 06 Nov 2013 20:34:04 -0000


There isn't much new in the arguments for and against VP8 vs H.264. Its
clear that there are concerns that are beyond how well each codec performs
and whether or not it is free. Although I recognize that the transcoding
option does not address the P2P use case, I do think that the goal of
interoperability can be better achieved through a two phase approach. The
first is enabling end-points to inter-operate through the availability of
transcoding from the service provider. The second is to make one of the
codecs the defacto MTI because of the its higher level of adoption. Yes, we
may never get to a single MTI if we follow this path but at least we will
have endpoints inter-operating. Besides, there are multiple other
difficulties in getting seamless P2P communications working all the time,
so I would suggest focusing on the service provider centered use case first.


On Wed, Nov 6, 2013 at 9:10 PM, cowwoc <> wrote:

> On 06/11/2013 4:30 AM, Daniel-Constantin Mierla wrote:
>> As it stands today, there are well known IPR issues with h264. Cisco's
>> move doesn't lift them.
>> So why to choose it if falls under the rules to remove it?
>     No one says it has to be H.264 and VP8. It could be H.261 and VP8.
>  With both on board, I still expect the majority of the apps will
>> implement only the most convenient for them, eventually expecting the other
>> to have both. Then responsibility is getting divided, like "it's not _only_
>> my fault", blaming the other end point as well.
>     That is a reasonable concern, and one that we need to address.
> Implementations that violate these rules will make it harder for us to
> replace older MTI codecs without breaking backwards compatibility.
> Gili
> _______________________________________________
> rtcweb mailing list

Mohammed Raad, PhD.
P.O. Box 113
NSW 2502 Australia
Phone: +61 414451478