Re: [rtcweb] Video codec selection - way forward

Leon Geyser <lgeyser@gmail.com> Mon, 18 November 2013 07:13 UTC

Return-Path: <lgeyser@gmail.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 EEF7411E8256 for <rtcweb@ietfa.amsl.com>; Sun, 17 Nov 2013 23:13:33 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 mSDn-0au5m8d for <rtcweb@ietfa.amsl.com>; Sun, 17 Nov 2013 23:13:32 -0800 (PST)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B0E4611E853E for <rtcweb@ietf.org>; Sun, 17 Nov 2013 23:13:26 -0800 (PST)
Received: by mail-lb0-f174.google.com with SMTP id c11so236371lbj.33 for <rtcweb@ietf.org>; Sun, 17 Nov 2013 23:13:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AxjNKDwQ21Z2GiFs0a8YssWP0/iyuL2Dt3Ubw/McIMw=; b=zJhxtPPZzRsZvXxdKeLGTVgyK5u7oxfduBbOn0+uT67/s1j9FSpFRFM9Acg50bFaVy Isk8eYIt7ytGlv1b4dHx54YvxfJL6oJjuxXt3KNFqViRvnMVYF/mSfl0wzWknPGUpKBb UklgkTtxM1Qe+m8cCDIJ6KH9C/5jDX4fYolcdoDUkbRMW0Cu2tCF2sdZ7risF4GWwdjk Dqg4kgqt7N9MOubdclZa6JQ3cLimpdEsbe76CXN+GNE7ftNYR9TvPLP4ivlW0y0oD0fK YzchQwL+nZxVSSz7A0XsYMM0vd8gMIuNSXtIp2lTxNy06p4+PoS00ksRJMa6GcWXV9ot Yp0Q==
MIME-Version: 1.0
X-Received: by 10.112.53.134 with SMTP id b6mr12604166lbp.5.1384758805588; Sun, 17 Nov 2013 23:13:25 -0800 (PST)
Received: by 10.114.168.70 with HTTP; Sun, 17 Nov 2013 23:13:25 -0800 (PST)
In-Reply-To: <7DB56E1B-C97D-4D39-AA07-C4857CE3470D@gmail.com>
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>
Date: Mon, 18 Nov 2013 09:13:25 +0200
Message-ID: <CAGgHUiR68pWTzORF6=R=nSi8zHeA2PxoPX33uxDRrpv6JZtykA@mail.gmail.com>
From: Leon Geyser <lgeyser@gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c3e624b4f0fe04eb6e484e
Cc: Thomas Reisinger <treising75@gmail.com>
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 07:13:34 -0000

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>; 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>;
> 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>;
> 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
> >>>> https://www.ietf.org/mailman/listinfo/rtcweb
> >>>>
> >>>
> >>>
> >> _______________________________________________
> >> rtcweb mailing list
> >> rtcweb@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >>
> >
> >
> > --
> > Libre Video
> > http://librevideo.org
> >
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>