Re: [rtcweb] Video codec selection - way forward

Maik Merten <maikmerten@googlemail.com> Mon, 18 November 2013 08:21 UTC

Return-Path: <maikmerten@googlemail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF88711E8162 for <rtcweb@ietfa.amsl.com>; Mon, 18 Nov 2013 00:21:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MowOidoe2HRq for <rtcweb@ietfa.amsl.com>; Mon, 18 Nov 2013 00:21:37 -0800 (PST)
Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 810C111E8149 for <rtcweb@ietf.org>; Mon, 18 Nov 2013 00:21:36 -0800 (PST)
Received: by mail-bk0-f50.google.com with SMTP id e11so1051358bkh.23 for <rtcweb@ietf.org>; Mon, 18 Nov 2013 00:21:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=r82b0XROJZst/7kEgkVpPqzWr0kueNvRrLYjN2UAiRQ=; b=LlBSmDs7BV0sDbFzqTVRujy31olJHMVzvapVxnTxBu5hdy4EAkwX9XZRoRYoP0hwk/ yN6Lg1c+or569VpuosbwGI2ZCG5fd69FWUvOSoGCyV6cbnWEP6kLXjH7YUP/Juxeg+pZ X27lYsm0APlnMaiO0UebfVCYZiFGMW3j6gNXLbyfrjKGppWZSVkhg9zkVKzjl+I34N1h iKZAn8zKnNy6qYQSXwlrbmHJVffqHHhdNYpH5NRX2HdGEnZ0IbReObkWTy2yvjB+rXp0 0om68d4ojBC+Voq0nZLBCw43vVDFqcemqFZy7G5CZfrDrG97e7wnyMFZtu6ydx1suSVc zh/g==
X-Received: by 10.204.103.199 with SMTP id l7mr11612578bko.11.1384762895577; Mon, 18 Nov 2013 00:21:35 -0800 (PST)
Received: from [0.0.0.0] (v2201202116457532.yourvserver.net. [46.38.243.75]) by mx.google.com with ESMTPSA id w9sm15742899bkn.12.2013.11.18.00.21.33 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Nov 2013 00:21:34 -0800 (PST)
Message-ID: <5289CE55.6090004@googlemail.com>
Date: Mon, 18 Nov 2013 09:22:45 +0100
From: Maik Merten <maikmerten@googlemail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <D9C9C6C10CA24644B3A854DB0C12E7D5014C12B5F1@gbplmail03.genband.com> <52891EDB.2050607@googlemail.com> <6A06EACB-69E2-4CE0-BDF2-1FDFD71159D3@gmail.com> <52892DD8.9050105@librevideo.org> <7DB56E1B-C97D-4D39-AA07-C4857CE3470D@gmail.com> <CAGgHUiR68pWTzORF6=R=nSi8zHeA2PxoPX33uxDRrpv6JZtykA@mail.gmail.com> <003e01cee435$be1f3940$3a5dabc0$@gmail.com>
In-Reply-To: <003e01cee435$be1f3940$3a5dabc0$@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 18 Nov 2013 08:21:38 -0000

H.263 seems to be covered by the MPEG-4 Visual patent pool and appears 
to require licensing:

http://www.mpegla.com/main/programs/M4V/Documents/M4VCrossRef.pdf


Maik


Am 18.11.2013 09:11, schrieb Thomas Reisinger:
> Thank you Leon. Why should we go with h.261 (except the lower cpu
> requirements for en/decoding), when we have a very popular royalty free
> h.263 as a common base for most video participants?
>
> Cheers,
>
> Thomas Reisinger
>
> *From:*Leon Geyser [mailto:lgeyser@gmail.com]
> *Sent:* Montag, 18. November 2013 08:13
> *To:* rtcweb@ietf.org
> *Cc:* Basil Mohamed Gohar; Thomas Reisinger
> *Subject:* Re: [rtcweb] Video codec selection - way forward
>
> Hi Thomas,
>
> On this list there seem to be patents listed from 1997 to 2011 for H.263:
>
> http://www.itu.int/net4/ipr/search.aspx?sector=ITU&class=PS&country=-1&org=-1&rec=H.263&prod=H.263&ps_country=-1&opt=-1&field=anokwcvd
>
> On 18 November 2013 08:51, Thomas Reisinger <treising75@gmail.com
> <mailto:treising75@gmail.com>> wrote:
>
>     Team,
>
>     I had the same concerns about the royalty fee, but after some
>     research I think there aren't any more. For h.264 this still
>     applies. H.261 is not acceptable anymore in a HD world as it is
>     today. Maybe somebody else cloud put some light on the royalty fees
>     for h.263. I will continue my research.
>
>     Cheers,
>
>     Thomas Reisinger
>
>
>      > On 17.11.2013, at 21:58, Basil Mohamed Gohar
>     <basilgohar@librevideo.org <mailto:basilgohar@librevideo.org>> wrote:
>      >
>      > Thomas,
>      >
>      > The reason H.261 is even being considered is because it is an
>     old-enough
>      > specification that any patents on it should have now expired.
>       Patents,
>      > and their liability on existing video formats, are amongst the
>     biggest
>      > factors affecting which formats can be adopted into the rtcweb
>     standard.
>      >
>      > H.263 most likely (I haven't checked) still has patents
>     associated with
>      > it that are active and, therefore, present an issue unless the
>      > respective owners of said patents have publicly declared them
>     royalty-free.
>      >
>      >> On 11/17/2013 03:13 PM, Thomas Reisinger wrote:
>      >> Hi,
>      >>
>      >> Instead of h.261, I would recommend h.263 as a common base.
>      >>
>      >> Cheers,
>      >>
>      >> Thomas
>      >> Sent from mobile device
>      >>
>      >>> On 17 Nov 2013, at 20:54, Maik Merten
>     <maikmerten@googlemail.com <mailto:maikmerten@googlemail.com>> wrote:
>      >>>
>      >>> Hello,
>      >>>
>      >>> 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.
>      >>>
>      >>> It appears that all implementors are willing to implement
>     either H.264 or VP8 (but not necessarily both). This obviously means
>     that negotiation failure regarding a high-performance codec is a
>     possiblity. In this case H.261 is actually useful so that basic
>     video calls can still be established (for instance, I guess deaf
>     people may always appreciate a video connection, as long as sign
>     language can be transmitted).
>      >>>
>      >>>
>      >>> Maik
>      >>>
>      >>>
>      >>> Am 14.11.2013 12:37, schrieb Jeremy Fuller:
>      >>>> Hi,
>      >>>> Gaining IETF consensus on making it mandatory to support only
>     H.264 or
>      >>>> only VP8 has clearly failed. I would welcome anyone to share their
>      >>>> thoughts on why they believe this situation will change
>     anytime in the
>      >>>> next few years.  Therefore, can I suggest that we remove items
>     1 and 2
>      >>>> from the list. Hopefully this will speed up the process by
>     focusing
>      >>>> efforts towards gaining agreement on one of the remaining options.
>      >>>> The following alternatives has been proposed:
>      >>>>
>      >>>> 1. All entities MUST support H.264
>      >>>> 2. All entities MUST support VP8
>      >>>> 3. All entities MUST support both H.264 and VP8
>      >>>> 4. Browsers MUST support both H.264 and VP8, other entities MUST
>      >>>>   support at least one of H.264 and VP8
>      >>>> 5. All entities MUST support at least one of H.264 and VP8
>      >>>> 6. All entities MUST support H.261
>      >>>> 7. There is no MTI video codec
>      >>>> 8. All entities MUST support H.261 and all entities MUST
>     support at
>      >>>>   least one of H.264 and VP8
>      >>>>
>      >>>> Regards,
>      >>>> Jeremy Fuller
>      >>>>
>      >>>>
>      >>>> _______________________________________________
>      >>>> rtcweb mailing list
>      >>>> rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>      >>>> https://www.ietf.org/mailman/listinfo/rtcweb
>      >>>>
>      >>>
>      >>>
>      >> _______________________________________________
>      >> rtcweb mailing list
>      >> rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>      >> https://www.ietf.org/mailman/listinfo/rtcweb
>      >>
>      >
>      >
>      > --
>      > Libre Video
>      > http://librevideo.org
>      >
>     _______________________________________________
>     rtcweb mailing list
>     rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>