Re: [rtcweb] Video Codec Selection Plan

Basil Mohamed Gohar <basilgohar@librevideo.org> Wed, 18 September 2013 18:32 UTC

Return-Path: <basilgohar@librevideo.org>
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 2035A11E810B for <rtcweb@ietfa.amsl.com>; Wed, 18 Sep 2013 11:32:23 -0700 (PDT)
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=[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 wfFBkirwL7Xn for <rtcweb@ietfa.amsl.com>; Wed, 18 Sep 2013 11:32:18 -0700 (PDT)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id DA55C11E80F6 for <rtcweb@ietf.org>; Wed, 18 Sep 2013 11:32:17 -0700 (PDT)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 08743658806 for <rtcweb@ietf.org>; Wed, 18 Sep 2013 14:32:16 -0400 (EDT)
Message-ID: <5239F1AD.8010301@librevideo.org>
Date: Wed, 18 Sep 2013 14:32:13 -0400
From: Basil Mohamed Gohar <basilgohar@librevideo.org>
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CA+9kkMAvdtq_gufKmDNCNCL+kKcxyi0MGUoVHetd9_DzbEdEnA@mail.gmail.com> <5238A564.2070601@bbs.darktech.org> <CABcZeBMgW7hX_tbN9NwQ2Wo35cFutgP1gZboseaOCCRZejRpGg@mail.gmail.com> <CAGgHUiQ6HZ=87DeYJV5iihjszFx16NWrwh-Kt4btQ31VkfDNSw@mail.gmail.com> <CACrD=+9EV-MG9E2krZ8O-GQNMZvxN20KsK-JkxEhFSUNsQfobQ@mail.gmail.com>
In-Reply-To: <CACrD=+9EV-MG9E2krZ8O-GQNMZvxN20KsK-JkxEhFSUNsQfobQ@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Video Codec Selection Plan
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: Wed, 18 Sep 2013 18:32:23 -0000

I was thinking if we're going to go with an older, non-IPR-encumbered
codec, Theora is the obvious choice, because it's been around about as
long as anything currently in use and has never had it's IPR seriously
challenged.

The encoder is being actively developed and has long since surpassed
pretty-much everything aside from H.264 and VP8 that are in common use
nowadays.

The fact that it takes much less CPU time to decode compared with other
modern codecs is also a plus.

Theora is also used in Elphel camera devices, so it's been used in
hardware as well (granted, those are not "burned-in-silicon" devices).

Efficiency wise, for talking-head scenarios (a common use case), I think
Theora will likely do quite well.

On 09/18/2013 04:49 AM, Monty Montgomery wrote:
> I'll see your h.261 and raise one Theora.  At least it has one hell of
> an encoder.
> 
> Cheers,
> Monty
> 
> On Wed, Sep 18, 2013 at 4:39 AM, Leon Geyser <lgeyser@gmail.com> wrote:
>> Anyone willing to create a draft for H.261?
>>
>>
>> On 18 September 2013 02:13, Eric Rescorla <ekr@rtfm.com> wrote:
>>>
>>>
>>>
>>>
>>> On Tue, Sep 17, 2013 at 11:54 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:
>>>>
>>>> Hi Ted,
>>>>
>>>>     Seeing as this discussion stems from licensing concerns, I like to
>>>> propose the following alternative:
>>>>
>>>> Mandate a video codec whose IPR has expired. I agree that video quality
>>>> will degrade, which brings me to the next point.
>>>> Provide a negotiation mechanism which would allow peers to "upgrade" to a
>>>> superior (optionally-implemented) video codec.
>>>
>>> Negotiation has always been part of the design. The sole question is which
>>> codec is mandatory to implement, not which is the sole codec to be
>>> mandated.
>>>
>>> -Ekr
>>>
>>>
>>>>     This will allow us to support VP8, VP9, H264, H265 or whatever other
>>>> codec people like without the fear of transcoding or IPR. I believe that in
>>>> most cases negotiation will succeed in upgrading to a superior codec. It
>>>> will also encourage (as opposed to force) vendors to support each other's
>>>> codecs, which is the right way to go in light of the political nature of
>>>> this decision.
>>>>
>>>> Gili
>>>>
>>>>
>>>> 1. If you support H.264 as the mandatory to implement codec or are
>>>> willing to live with it as the MTI, please raise your hand now.
>>>>
>>>> 2. If you support VP8 as the mandatory to implement codec or are
>>>> willing to live with it as the MTI, please raise your hand now.
>>>>
>>>>
>>>> Gili
>>>>
>>>>
>>>> On 13/09/2013 12:52 PM, Ted Hardie wrote:
>>>>
>>>> WG,
>>>>
>>>> The chairs have created a plan for how to perform the Video Codec
>>>> selection in our WG. The chairs are asking for review of our plan on
>>>> how to undertake the mandatory-to-implement video codec selection.
>>>> We'd much prefer to have comments on the mechanics before they begin,
>>>> so please review now.  Proponents of a particular proposal should
>>>> note both the actions required and the timelines proposed.
>>>>
>>>> The main goal of this plan is to hold a consensus call on which of
>>>> the proposed alternatives we as a WG should select at one of the WG
>>>> sessions in Vancouver. Such a consensus call will of course be
>>>> verified on the mailing list for anyone who can't participate. The
>>>> chairs will recuse themselves from judging this particular
>>>> consensus.
>>>>
>>>> In the WG session each codec proposal will be allowed an equal amount
>>>> of time to highlight the arguments for their proposal. After that a
>>>> there will be a slot for discussion and clarifying questions.
>>>>
>>>> To enable the WG participants to get answers to any questions, the
>>>> proposals in draft form and any supporting material MUST be made
>>>> available by 6th of October. This is to ensure that the WG
>>>> participants can verify or object to any claims or statements in
>>>> the proposal material prior to the WG session. We chairs would really
>>>> not like to see the proponents bring up new arguments at their
>>>> presentation. Also the WG participants are expected to raise any
>>>> arguments on the list ahead of time to enable the proponents to
>>>> respond to such arguments.
>>>>
>>>> The proposed consensus questions will be of the following form:
>>>>
>>>> 1. If you support H.264 as the mandatory to implement codec or are
>>>> willing to live with it as the MTI, please raise your hand now.
>>>>
>>>> 2. If you support VP8 as the mandatory to implement codec or are
>>>> willing to live with it as the MTI, please raise your hand now.
>>>>
>>>> You may indicate support on both questions and we encourage you to do
>>>> so if you can live with either, even if you have a preference for one
>>>> over the other.
>>>>
>>>> Additional proposals than the previous ones are welcome, but must be
>>>> submitted as draft and their proponents must notify the chairs no later
>>>> than the 6th of October that they also have a candidate proposal.
>>>>
>>>> In case the WG fails to reach consensus we chairs propose that we use
>>>> the alternative decision process as discussed in RFC3929. The method
>>>> and its usage will be discussed on the list should the WG not
>>>> establish consensus on a proposal for mandatory to implement video codec.
>>>>
>>>> regards,
>>>>
>>>> Magnus,  Cullen, and Ted
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 


-- 
Libre Video
http://librevideo.org