Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them)

Jonathan Rosenberg <jdrosen@jdrosen.net> Tue, 04 November 2014 15:17 UTC

Return-Path: <jdrosen@jdrosen.net>
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 694431A8983 for <rtcweb@ietfa.amsl.com>; Tue, 4 Nov 2014 07:17:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=no
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 7kjnF1XhQpmD for <rtcweb@ietfa.amsl.com>; Tue, 4 Nov 2014 07:17:11 -0800 (PST)
Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [70.39.232.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85B131A8978 for <rtcweb@ietf.org>; Tue, 4 Nov 2014 07:17:10 -0800 (PST)
Received: from mail-pa0-f50.google.com ([209.85.220.50]:39427) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from <jdrosen@jdrosen.net>) id 1Xlfqz-0003Rv-0q for rtcweb@ietf.org; Tue, 04 Nov 2014 10:17:09 -0500
Received: by mail-pa0-f50.google.com with SMTP id eu11so14474900pac.23 for <rtcweb@ietf.org>; Tue, 04 Nov 2014 07:17:03 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.66.184.47 with SMTP id er15mr50142103pac.5.1415114223150; Tue, 04 Nov 2014 07:17:03 -0800 (PST)
Received: by 10.70.23.36 with HTTP; Tue, 4 Nov 2014 07:17:03 -0800 (PST)
In-Reply-To: <5458E8D6.6090809@gmail.com>
References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <54582599.6070806@alvestrand.no> <CA+23+fEh-SGGXCD6UWNDeK3kRdyg71ZAJF0aTvDpgoWgR1fNew@mail.gmail.com> <545844CC.5010000@matthew.at> <CAHgZEq6K39fXNSaVCtAZXOMB5W6L-0XqKugjtAxkF5p0Q3rHgg@mail.gmail.com> <5458CFDC.4020401@gmail.com> <949EF20990823C4C85C18D59AA11AD8B2703CB@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5458E8D6.6090809@gmail.com>
Date: Tue, 04 Nov 2014 10:17:03 -0500
Message-ID: <CA+23+fFPBp+qdPi2o_uT2jkwDkoVLucyMKjiPBfh+0zZ+rOkQQ@mail.gmail.com>
From: Jonathan Rosenberg <jdrosen@jdrosen.net>
To: miconda@gmail.com
Content-Type: multipart/alternative; boundary="047d7bdc9c8696cbc7050709f434"
X-OutGoing-Spam-Status: No, score=0.6
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jdrosen.net
X-Get-Message-Sender-Via: ecbiz71.inmotionhosting.com: authenticated_id: jdrosen+jdrosen.net/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nv-KJGeqv49RzdBeszHqfAeHIGg
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them)
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: Tue, 04 Nov 2014 15:17:16 -0000

Matthew,

You wrote:
"A "substantive change" would be *any* of the parties who participate in
these discussions having a different position than before."

Let us not forget that this working group is a large set of people, many of
whom are not amongst the frequent posters and/or highly opinionated folks
on this and other threads. While the changes over the last year are
unlikely to sway the opinions of those who are entrenched, they may make
enough difference to folks in the middle. Enough, at least, for us to
achieve rough consensus, since that is the best we can hope for.

Given the importance of this issue to making webRTC viable in the market,
and given the relatively low cost of running a brief discussion (updates
only!) and hum at IETF, I see only a possibility of great progress and
almost no negative costs to trying.

-Jonathan R.


On Tue, Nov 4, 2014 at 9:55 AM, Daniel-Constantin Mierla <miconda@gmail.com>
wrote:

>  I don't find anything contrary to the RFC paragraph you refer to. No
> technology (video codec in this case) is superior enough to the other for
> taking that in consideration (there were results from tests over tests and
> re-tests done by various entities), nothing changed, so this is not an
> excuse/reason to be considered. I did use 'I' not 'IETF' for my opinions,
> there is no 'equate' but 'expect'. Also, no IPR assumptions, just stated
> that nothing relevant changed related to them, given the conclusions from
> the past discussions.
>
> I did read most of the RFCs out there and worked for the past almost 15
> years with the specs from IETF, therefore to be clear, my 'expect' comes
> from how IETF worked so far and I hope the future activity still tries to
> follow the 'preferred' guidelines rather than the 'exceptions'.
>
> Those being said, unless you can point case by case the specific parts in
> my initial opinions, I don't really get what you targeted with your answer.
>
> Daniel
>
>
> On 04/11/14 15:03, DRAGE, Keith (Keith) wrote:
>
> Your statements about what the IETF should expect are somewhat different
> from the statements in RFC 3979. I quote:
>
>
>    In general, IETF working groups prefer technologies with no known IPR
>    claims or, for technologies with claims against them, an offer of
>    royalty-free licensing.  But IETF working groups have the discretion
>    to adopt technology with a commitment of fair and non-discriminatory
>    terms, or even with no licensing commitment, if they feel that this
>    technology is superior enough to alternatives with fewer IPR claims
>    or free licensing to outweigh the potential cost of the licenses.
>
>
>
>  You are perfectly entitled to have your own personal view of what you desire, but please do not equate your desires with IETF policy in this area.
>
> I'd also note you are making your own assumptions about the IPR encumbrance of various solutions, and those assumptions may not match those of other participants. IETF itself does not evaluate IPR encumbrance.
>
> regards
>
>
>
> Keith Drage
>
>
>  ------------------------------
> *From:* rtcweb [mailto:rtcweb-bounces@ietf.org <rtcweb-bounces@ietf.org>] *On
> Behalf Of *Daniel-Constantin Mierla
> *Sent:* 04 November 2014 13:09
> *To:* Alexandre GOUAILLARD; Matthew Kaufman
> *Cc:* rtcweb@ietf.org
> *Subject:* Re: [rtcweb] The MTI Codec Questions (what to ask and how to
> ask them)
>
>  If there are groups of people willing to discuss the evolution of the
> surrounding environment around video codecs, that's their time, can be done
> anywhere at their wish.
>
> Related to the substance of webrtc MTI, there is nothing new out there
> relevant to the video codecs constraints. No change from MPEG-LA on H.264
> costs and restrictions for use freely by everyone (including the open
> source space), as expected when having to implement an open standard from
> IETF. No final decisions on patent claims to VP8.
>
> Let's hope soon there will be news about:
> - MPEG-LA makes H.264 completely free
> - VP8 pattent claims get to a final decision in court, so either they are
> dismissed there or they can be dealt differently
> - a new completely free video codec shows up
>
> I expect IETF is going to stand against monopolistic trends and particular
> business interests, being the standardization body for open protocols in an
> open internet. It is no excuse to release/propose IETF standards that force
> someone either to pay to or be tracked by specific group of interests.
>
> Let's not forget that not so many years ago there were completely
> different communication means -- under monopoly, with high costs and very
> rigid -- without open standards with no barriers for anyone, the level of
> innovation we benefited in the past years wouldn't have happened.
>
> Daniel
>
>
> On 04/11/14 06:44, Alexandre GOUAILLARD wrote:
>
> Apple had 264, but there was no API to make 264 HW acceleration available
> to developers. It was mentioned as one of the reason why cisco open264 felt
> short of addressing some concerns voiced in the MTI pool. the iOS 8's 264
> API changed this.
>
>  In any case, I support the chair decision to try to revisit the question.
>
> On Tue, Nov 4, 2014 at 11:15 AM, Matthew Kaufman <matthew@matthew.at>
> wrote:
>
>> A "substantive change" would be *any* of the parties who participate in
>> these discussions having a different position than before.
>>
>> Yes, Cisco, who already supported H.264 and had announced an intention to
>> ship an open source and binary module, shipped H.264.
>>
>> And Firefox, reluctant supporter of H.264 when available but preferring
>> VP8 and some future even more free codec that isn't yet shipped, is
>> reluctantly supporting H.264 when available.
>>
>> And iOS 8 has H.264, but of course Apple already had access to that H.264
>> if they were to put WEBRTC into their browser...
>>
>> Etc.
>>
>> Where's the "Google has decided to pull their support for VP8 and fully
>> back H.264 for real-time communications on the web" announcement? Or the
>> "Microsoft open-sources Internet Explorer, adds native VP8 to Windows"
>> announcement? Or the "MPEG-LA drops all fees for H.264 encoding and
>> decoding" announcement? Or really *anything* that substantially changes
>> things from where we were six months ago?
>>
>> I don't get the desire to spend time on this topic... and I especially
>> don't understand the call to pack as many people into a room as possible to
>> conduct a hum, when the outcome will need to be discussed and confirmed on
>> the list anyway.
>>
>> Matthew Kaufman
>>
>>
>> On 11/3/14, 5:13 PM, Jonathan Rosenberg wrote:
>>
>> Matthew,
>>
>>  You wrote:
>> "I'm going to ask what I asked when I first saw this on the agenda: What
>> has substantively changed since then?
>>
>> As far as I can tell, nothing.:
>>
>>  Actually several things have substantively changed since then. The list
>> includes but is not limited to:
>>
>>  * Cisco shipped its H264 open source and binary module
>> * Firefox is using the Cisco binary module and as such Firefox now
>> supports both H264 and VP8
>> * IOS8 has shipped with API support for H264 (you may recall that lack of
>> a solution for H264 on IOS was an objection many had regarding the Cisco
>> h264 binary module solution; this is now addressed)
>> * there has been progress in the ongoing legal proceedings around VP8
>> * there are new IPR statements regarding VP8 in ongoing standards
>> processes
>>
>>
>>  I think this is far beyond "nothing". And given the importance of this
>> topic to progress on adoption of webRTC, it warrants discussion at the mic.
>>
>>  -Jonathan R.
>>
>>
>> On Mon, Nov 3, 2014 at 8:02 PM, Harald Alvestrand <harald@alvestrand.no>
>> wrote:
>>
>>>  Hm.
>>>
>>> I don’t think there’s much value in revisiting the “one codec”
>>> alternatives. We tried that, and know that we found no consensus. Nobody’s
>>> changed their minds.
>>>
>>> It would be very sad if we give up on interoperability for WebRTC
>>> devices. Accepting “either” means that there will be 2 groups of them, and
>>> they need a gateway to talk to each other, even when they can all talk to
>>> all compatible browsers. Having an MTI would be better - but one purpose of
>>> the “device” category is to allow fully compliant devices that don’t need
>>> the kind of corporate backing a browser needs - which means that licensed
>>> codecs are an issue. We’ve had that discussion before.
>>>
>>> Of course, WebRTC-compatible devices (as currently defined) can do
>>> whatever they want.
>>>
>>> But still, it seems that there’s a chance that discussing this again is
>>> worth it. We might find an agreement this time.
>>>
>>> Harald
>>>
>>>
>>>
>>>
>>> On 11/03/2014 03:32 PM, Sean Turner wrote:
>>>
>>> All,
>>>
>>> One of the remaining major technical decisions for the RTCweb WG is which codec(s) should be  MTI.  The issue has been on hold for over 6 months and the original plan to was the re-attempt determining consensus at the IETF 91.  To make the best use of the WG’s face-to-face time at IETF 91, we want to give the WG ample time to digest/discuss the questions the chairs intend to ask the WG concerning the MTI codec (or codecs).  We want to know before the meeting whether to ask the questions and then what questions to ask - in other words we want to inform the WG of the questions before the WG session so as to not waste time debating what questions should be asked.
>>>
>>> Without further ado, these are the proposed questions:
>>>
>>> Question #0 (hum)
>>>
>>> Do you want to discuss this issue at this meeting?
>>>
>>> Question #1 (stand up)
>>>
>>> Please stand (or signal in the jabber chat) if you will be part of that consensus process for this question. If you're here to read email or watch the show, we want to know that your sitting throughout this isn't expressing opinions for the consensus process.
>>>
>>>     To many this might seem like a silly question,
>>>     but the chairs believe the problem is well enough
>>>     understood by those actively involved WG
>>>     participants so we would like to confirm this
>>>     understanding.  The chairs will also use to the
>>>     determine the informed pool of WG participants.
>>>
>>> Question #2 (hum)
>>>
>>> Do you believe we need an MTI codec to avoid negotiation failures?
>>>
>>>     Previous attempts at determining the MTI did not
>>>     yield a result but did confirm that there is a desire
>>>     for an MTI to avoid negotiation failures.   Recently,
>>>     some on the mailing list have expressed an interest
>>>     in postponing this discussion until after IETF 91.  The
>>>     purpose of this question is to reconfirm the original
>>>     consensus.
>>>
>>> Question #3 (open mic)
>>>
>>> Are there any codecs that were not included in the previous consensus calls that warrant consideration?  If yes, which one and why.
>>>
>>>     The assumption is that the viable codecs are a) VP8,
>>>     b) H.264, or c) VP8 and H.264.  This is based on the
>>>     extensive poll results from the last consensus calls.
>>>     But time has passed so we need to entertain the ever
>>>     so slight possibility that another codec has miraculously
>>>     appeared.  Remember, we want to ensure we’re going
>>>     to get maximum interoperability.
>>>
>>> Question #4 (open mic)
>>>
>>> Are there any new or unaddressed technical issues that will not allow us to narrow the field to VP8 and H.264?
>>>
>>>     We do not want to revisit previous discussions; we only
>>>     want new or unaddressed technical issues and will throttle
>>>     the discussion accordingly.  We’ll rely on WG participants
>>>     and our former RAI AD (Mr. Sparks) for help in this area.
>>>
>>>     We believe the technical discussion will fall into two
>>>     buckets:
>>>       - New or unresolved technical points.
>>>       - Licensing.  WRT licensing, the IETF tries not discuss
>>>         whether IPR is valid, but an IPR issue that can be used
>>>         as input to the decision making process is if enough
>>>         people say they can’t/won’t implement because of the IPR.
>>>
>>> Question #5 (hum)
>>>
>>> With respect to the MTI codec:
>>>     - Who can live with a requirement that WebRTC User Agents
>>>       MUST support  both VP8 and H.264 and WebRTC devices
>>>       MUST support  either VP8 or H.264?
>>>     - Who can live with a requirement that all endpoints MUST support VP8?
>>>     - Who can live with a requirement that all endpoints MUST support H.264?
>>>
>>> Thanks for your time,
>>> t/c/s
>>> _______________________________________________
>>> rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>>
>>>
>>>   --
>>> Surveillance is pervasive. Go Dark.
>>>
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>>
>>
>>
>>  --
>>  Jonathan Rosenberg, Ph.D.
>> jdrosen@jdrosen.net
>> http://www.jdrosen.net
>>
>>
>> _______________________________________________
>> rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>
>
>  --
>  Alex. Gouaillard, PhD, PhD, MBA
>
> ------------------------------------------------------------------------------------
> CTO - Temasys Communications, S'pore / Mountain View
> President - CoSMo Software, Cambridge, MA
>
> ------------------------------------------------------------------------------------
> sg.linkedin.com/agouaillard
>
>    -
>
>
>
> _______________________________________________
> rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb
>
>
> --
> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>
>
> --
> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>
> Kamailio Advanced Training, Nov 24-27, Berlin - http://www.asipto.com
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>


-- 
Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net
http://www.jdrosen.net