Re: [rtcweb] Video codec selection - way forward

Maik Merten <> Mon, 18 November 2013 07:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 75DE011E8149 for <>; Sun, 17 Nov 2013 23:56:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5zoXCSNurM3h for <>; Sun, 17 Nov 2013 23:56:40 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4008:c01::231]) by (Postfix) with ESMTP id E065411E80F2 for <>; Sun, 17 Nov 2013 23:56:39 -0800 (PST)
Received: by with SMTP id my13so441718bkb.36 for <>; Sun, 17 Nov 2013 23:56:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=nlyL3s8mEum2H5RkffxfAQ5RQoNRSmya7yMjpvkqS5M=; b=yQ9UFJH2PqK3T4cmcvjhi0qVVu8l4bZHn5jiZ3p6vHC0cPo+qtqCrNUkSo8i5FiAHq umouZWwQqDP9vE1ezb2s+i7fAWZxFP0E7+CobKKxXpOezpJnui26AYNi6oljzRbUfRrW g8WcnJ01FynVuC31D7D8gHu7Vebu37xqSY4AMaZ8puIPpCrVsLvC8rIbPdRxmZUFSR5T dL2xE4AsVJalUmM1ks17x2Idn4UBAFwm8eOqdpnBqGRkae4aBHtbAGOPIeRghgqi47WC PnTU1QFr7pHgv5oAe3zPbKEDHgkLJehrLn+APwv0+b/nwDJJFJ87Ag8Jc5Zu1as5D/n7 qaoA==
X-Received: by with SMTP id pp5mr11572691bkb.14.1384761397892; Sun, 17 Nov 2013 23:56:37 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id qg7sm15639929bkb.6.2013. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Nov 2013 23:56:36 -0800 (PST)
Message-ID: <>
Date: Mon, 18 Nov 2013 08:57:49 +0100
From: Maik Merten <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Video codec selection - way forward
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: Mon, 18 Nov 2013 07:56:42 -0000

Dear Ross,

thanks for providing your thoughts on this proposal. Your analysis quite 
perfectly reflects my reasoning.

I think there is consensus that both H.264 Constrained Baseline and VP8 
are capable of delivering high quality video. However...

  - the camp opposing VP8 fears that Google is not in complete control 
of the surrounding IPR situation
  - the camp opposing H.264 presented diverse examples where H.264's 
licensing is not compatible with their very operating principles

I currently do not see how this can be resolved in such a way that each 
camp is happy.

There apparently is consensus, however, that negotiation failure should 
be avoided and that high video quality is desirable, meaning that 
entities are very welcome to implement both high performance codecs. 
This does not appear to be possible for all participants, so to avoid 
negotiation failure while working around IPR issues something like H.261 
looks quite promising IMO. While some participants rightfully question 
the place such an antique codec may have in our HD world, I'm still 
fully convinced that transmitting CIF video can still be very much 
desirable over forcefully transmitting no video at all: that resolution 
still transports emotions, facial features and sign language (which is 
relevant to those concerned with accessibility).

It can also be demonstrated that objective quality measures such as PSNR 
and SSIM favor transmission of low resolution video over a static black 
picture ;)

Again in a nutshell:

  - nobody is forced to implement a codec they object to on IPR grounds
  - we never have negotiation failure and can always transmit video 
(albeit not always beautiful video)
  - implementations that are always able to transmit high quality video 
do not need to be concerned with implementing a low quality video codec

Best regards,


Am 18.11.2013 07:58, schrieb Ross Finlayson:
>> just wondering if something like
>> "9. All entities SHOULD support both H.264 and VP8. All entities MUST
>> at least implement one of those. Entities that do not support both
>> H.264 and VP8 MUST implement H.261."
>> has already popped up. My reasoning is that implementations supporting
>> both high performance codecs will always negotiate to use on of those
>> - H.261 should never be relevant there.
> This looks promising.  To summarize: You're proposing that each
> implementation MUST implement (at least) one of the following sets of
> codecs:
> {VP8, H.264}
> {VP8, H.261}
> {H.264, H.261}
> This guarantees that there'll never be negotiation failure (between a
> pair of implementations), because the intersection of any two of these
> sets is non-empty.
> It also allows the H.264 camp to avoid any alleged additional IPR risk
> from implementing VP8, because they won't need to implement VP8 (they'll
> need to implement H.261 instead).
> Similarly, it also allows the VP8 camp to avoid any H.264 licensing
> requirements, because they won't need to implement H.264 (they'll need
> to implement H.261 instead).
> And people who are willing to implement both VP8 and H.264 will know
> that they'll always be able to negotiate high-quality video.
> Who knows - this may well be something that we could reach consensus on
> (provided that everyone agrees that there's little IPR risk from H.261)...
> Ross Finlayson
> Live Networks, Inc.
> _______________________________________________
> rtcweb mailing list