Re: [rtcweb] H.264 -- Decoder only specification

Roman Shpount <roman@telurix.com> Wed, 11 December 2013 20:14 UTC

Return-Path: <roman@telurix.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 BC9211AE1BB for <rtcweb@ietfa.amsl.com>; Wed, 11 Dec 2013 12:14:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 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, SPF_PASS=-0.001] 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 myjuWz4dyo9w for <rtcweb@ietfa.amsl.com>; Wed, 11 Dec 2013 12:14:07 -0800 (PST)
Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7130E1AE1BE for <rtcweb@ietf.org>; Wed, 11 Dec 2013 12:14:07 -0800 (PST)
Received: by mail-wg0-f51.google.com with SMTP id b13so6888006wgh.6 for <rtcweb@ietf.org>; Wed, 11 Dec 2013 12: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:mime-version:date:message-id:subject:from:to:cc :content-type; bh=7iH5khQ8goBb5rv0tgoNsms51iURz3vl7PMrwWvtUw0=; b=fj1EidmukZKyBuHzvaKREWbVXpdJwhq6G8DBh9j23+aoj48MzGot3TXai1mLSEFx2R bept4hZAlxvFdHuEvTRgu1O1ffFE1Fh/M5RoPfxvGFaFB0aYiGM97gxwIR0DxTWmMevN ryi4mB6EDbicEqGKWRE3wLmS6MZKNWZLBAuzFBAHJEsSn1yEsgRzXXPyXy+2j1/dV8ny dZylmxIZ6XVEPj4BRKbrUg4FZxQIyjNeFIaD1exNBF0qFx0yB/XyCmqenQ5VYnm7ZhG6 zI90VHnjzNIwPbxiLnkRRT30lrzrm4zxSombM082iHVyJ9kZ26HC+OPh0/EyUOt8Y4MG CBHg==
X-Gm-Message-State: ALoCoQlMMZH0BuWiygmPoIODp6zxbZnGKIyzPbB+PohOg3s0zEMuMBznmjcgcEiH6OCYuIZp+DyD
X-Received: by 10.180.39.43 with SMTP id m11mr1715540wik.8.1386792840272; Wed, 11 Dec 2013 12:14:00 -0800 (PST)
Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by mx.google.com with ESMTPSA id bk7sm18111529wib.10.2013.12.11.12.13.59 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Dec 2013 12:13:59 -0800 (PST)
Received: by mail-wi0-f181.google.com with SMTP id hq4so1461599wib.8 for <rtcweb@ietf.org>; Wed, 11 Dec 2013 12:13:58 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.36.40 with SMTP id n8mr25908073wij.54.1386792838281; Wed, 11 Dec 2013 12:13:58 -0800 (PST)
Received: by 10.217.88.133 with HTTP; Wed, 11 Dec 2013 12:13:58 -0800 (PST)
Date: Wed, 11 Dec 2013 15:13:58 -0500
Message-ID: <CAD5OKxswVxrhjitpkji6+oN--uAk6qJ371+PYwJfidznzxNhTQ@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="e89a8f5030d280bfd404ed47defa"
Cc: Cullen Jennings <fluffy@cisco.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] H.264 -- Decoder only specification
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: Wed, 11 Dec 2013 20:14:09 -0000

Changing subject to keep this out of the straw poll

On Wed, Dec 11, 2013 at 2:44 PM, DRAGE, Keith (Keith) <
keith.drage@alcatel-lucent.com> wrote:

>  I was of the understanding that the statement:
>
> "Encoder is not specified by the standard and there are no obligations
> for MPEG members to declare anything, so you are more then likely exposed
> to addition IPR risks when implementing a good encoder. "
>
> applied to pretty much every videocodec under the sum, and was not
> specific to H.264.
>
> The general method of specifying videocodecs is to specify the decoder
> only. I'd certainly thought seen a statement of that sort previously on the
> list; have I understood it wrong?
>
> Essentially if you do anything innovative that is not covered by the
> standard, you stand a chance of contravening IPR of someone who thought of
> it before you did and then patented it.
>
>
I am comparing it here with VP8 where Google provides the IPR rights to
everything used in their implementation, including both encoder and
decoder. Their reference encoder is good enough for production use and it
is in fact used with no or minimal modifications in real communication
applications. For H.264, if you need a production quality encoder, you need
to use an encoder implementation which is doing something non-trivial,
unspecified by the standard, and innovative, which is likely to have
additional IPR licensing requirements. The same applies to all the other
H.XXX video codecs, which do not include a usable encoder implementation as
a part of the standard.

_____________
Roman Shpount