Re: [rtcweb] Plan for MTI video codec?

Stephan Wenger <stewe@stewe.org> Thu, 23 October 2014 17:10 UTC

Return-Path: <stewe@stewe.org>
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 CC84E1ACD9E for <rtcweb@ietfa.amsl.com>; Thu, 23 Oct 2014 10:10:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 ZeQKMoez8fml for <rtcweb@ietfa.amsl.com>; Thu, 23 Oct 2014 10:10:49 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0141.outbound.protection.outlook.com [207.46.100.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 423A11ACE19 for <rtcweb@ietf.org>; Thu, 23 Oct 2014 10:10:43 -0700 (PDT)
Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB364.namprd07.prod.outlook.com (10.141.75.13) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Thu, 23 Oct 2014 17:10:41 +0000
Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.72]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.72]) with mapi id 15.00.1049.012; Thu, 23 Oct 2014 17:10:41 +0000
From: Stephan Wenger <stewe@stewe.org>
To: Stephan Wenger <stewe@stewe.org>, Watson Ladd <watsonbladd@gmail.com>, Alexandre GOUAILLARD <agouaillard@gmail.com>
Thread-Topic: [rtcweb] Plan for MTI video codec?
Thread-Index: AQHOrixjgMwfvYrSbUqrcWE5foJ0c5wzqjdjgAAvKoCAAddnAIAAAwiAgAAJmQCAAQDrgIACFIiAgAEvmwCAAAgMAIAACFqAgAAAiICAACAFgIAEXFwAgAFnCIA=
Date: Thu, 23 Oct 2014 17:10:41 +0000
Message-ID: <D06E846C.49DDB%stewe@stewe.org>
References: <CAGTXFp-HVJDwd86207PNM2QVYO4Z_K4WF-KarnRs1fb7nvy4zA@mail.gmail.com> <CA+9kkMDfES8gpi0-PTXpCnQHjFYUSF2r44TNzH5B4UfDGo8PtA@mail.gmail.com> <CAGTXFp8O-7ACksk3v3f=KjCkcDb4e8G=t-e=EJ1503vt7TkpCQ@mail.gmail.com> <CAGTXFp867AMUZ_fEKxG9uAoR1H1AirVHi3-ayJ=KTQk9L+C7+g@mail.gmail.com> <CA+9kkMAZufR7gUrwkS7Tf5GOfg+ZtsZWGcn-8YLCvnmYnTgfFw@mail.gmail.com> <544035DE.8000606@matthew.at> <CABkgnnUNgWaauS6-nZ5fcExjsMPy4ZGPXaahduzA39=iqh9+fQ@mail.gmail.com> <D5D11F2B-9E32-4932-A601-F1D7FD50C706@gmail.com> <544117FB.6050706@alvestrand.no> <CAHgZEq6GTk5ei+LLpWPM5povpieompD66VU9F+u7--WJVgapaQ@mail.gmail.com> <CA+23+fGWnWd0QEeCmZ=6BmJkPrUVW6cZ0jwmXA+fM88=_+_NWw@mail.gmail.com> <CAOW+2dugTtfLhk0VuJOk7OPEonGBApMjY93EZocH90RbX6X22w@mail.gmail.com> <CAHgZEq5t4-Cot9XkU_pfyfi0TBCUxfT79ZvpiLW=X5_KUQh5dA@mail.gmail.com> <CACsn0ck_VtMnf6740rh0ku1Qct7s-xrJEfokg6oufEi4wgrYAw@mail.gmail.com> <D069AC57.49A8E%stewe@stewe.org> <D06D5403.49D1D%stewe@stewe.org>
In-Reply-To: <D06D5403.49D1D%stewe@stewe.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [50.174.124.226]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR07MB364;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 0373D94D15
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(24454002)(51704005)(479174003)(377454003)(120916001)(122556002)(99396003)(20776003)(64706001)(86362001)(92566001)(92726001)(101416001)(76176999)(50986999)(54356999)(16601075003)(15202345003)(31966008)(97736003)(4396001)(105586002)(77096002)(19580405001)(19580395003)(40100003)(93886004)(85306004)(36756003)(66066001)(76482002)(2656002)(80022003)(46102003)(21056001)(106116001)(106356001)(85852003)(95666004)(99286002)(87936001)(107046002)(15975445006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR07MB364; H:CO1PR07MB363.namprd07.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en;
Content-Type: text/plain; charset="euc-kr"
Content-ID: <716B49CCFAB8C9488197A228F4A4D804@namprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EkSKP3G-458Wa8oKnM-J8vi9m04
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Plan for MTI video codec?
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: Thu, 23 Oct 2014 17:10:56 -0000

Another correction: the MPEG doc number below is wrong (typo).  The
correct number is M34971.
Stephan

On 10/22/14, 12:45 PM, "Stephan Wenger" <stewe@stewe.org> wrote:

>Hi,
>I have to make one correction in the light of information that has
>surfaced at the MPEG meeting currently ongoing in Strasbourg.  (I’m not at
>that meeting this time, but a colleague is and she briefed me.)
>Nokia has made MPEG and ISO/IEC officially aware that they are not willing
>to license essential patents under RAND terms.  For those with MPEG
>document access, please see M34917.  The official declaration is dated
>9/19/2014, and is not yet available from the respective databases, as ISO
>is apparently changing its recordation infrastructure.
>My understanding of the joint ITU/ISO/IEC patent policy is that no
>standard can be issued that has a type 3 declaration against it.  To the
>best of my knowledge, ISO has no established procedure how to deal with
>type 3 (non-RAND) declarations and still keep the standard project going.
>Unlike, for example, W3C and its Patent Advisory Groups.
>The declaration does not list specific patents. To the best of my
>knowledge, such info is not required (only desired) for ISO and IEC
>standardization work--one of the few differences in patent policy
>guidelines between ITU and ISO/IEC.
>Therefore, I have to row back on my previous statement of likeliness of
>having an ISO number for VP8 anytime soon.  At this point, I just don’t
>know whether, if ever, that will happen.
>Regards,
>Stephan
>
>
>On 10/19/14, 6:10 PM, "Stephan Wenger" <stewe@stewe.org> wrote:
>
>>Hi,
>>
>>On 10/19/14, 9:15 AM, "Watson Ladd" <watsonbladd@gmail.com> wrote:
>>
>>>On Sun, Oct 19, 2014 at 9:13 AM, Alexandre GOUAILLARD
>>><agouaillard@gmail.com> wrote:
>>>> @jonathan,
>>>>
>>>> while you are right and availability of 264 implementation or hardware
>>>> acceleration has improved, it has never been reported as a problem in
>>>>the
>>>> previous pool by anyone. The 264 royalties, and the VP8 IP risks were,
>>>> AFAIR, the main reasons used by individuals to justify their
>>>>positions.
>>>> Today, nothing has changed with respect to those two items (even
>>>>though
>>>> providing open264 royalties and absorbing the license cost for some
>>>> platforms might have been a set in the right direction). This is why I
>>>>think
>>>> the conditions are not met for a consensus to be reached.
>>>
>>>But now VP8 is going through ISO,
>>
>>... and is is DIS ballot.  Few projects in ISO get stopped at that stage.
>>To me, it¹s pretty clear that VP8 will have an ISO/IEC blessing within a
>>year or two.  Without substantial technical changes.  Given the very
>>limited participation in the relevant subgroup in MPEG, it¹s unclear to
>>me
>>what good that will do, though.
>>
>>>and the people claiming patents on
>>>VP8 have had time to sue, and haven't.
>>
>>That¹s factually incorrect.  To the best of my knowledge, what would be
>>factually correct is this: in two cases, companies have been sued over
>>patents allegedly reading on VP8 in the context of the wider ³smartphone
>>wars² lawsuits, and the defendants have won non-infringement rulings in
>>the first instance (though, last I looked, appeals were pending in both
>>cases).  At least one other case was settled on undisclosed terms.  Some
>>of these cases were widely reported in the press, others are a little bit
>>harder to find without access to legal search tools.
>>
>>>That's evidence that some
>>>concerns are overblown.
>>
>>And that depends on your viewpoint.
>>
>>Stephan
>>
>>>
>>>>
>>>> Alex.
>>>>
>>>>
>>>> On Sun, Oct 19, 2014 at 11:43 PM, Bernard Aboba
>>>><bernard.aboba@gmail.com>
>>>> wrote:
>>>>>
>>>>> "And its one of the issues holding up wider adoption of the
>>>>>technology"
>>>>>
>>>>> [BA] Specifying an MTI encoder/decoder is not sufficient for
>>>>> interoperability.  It is also necessary to specify the transport in
>>>>>enough
>>>>> detail to allow independent implementations that interoperate well
>>>>>enough to
>>>>> be usable in a wide variety of scenarios, including wireless networks
>>>>>where
>>>>> loss is commonly experienced.
>>>>>
>>>>> We made the mistake of having an MTI discussion previously with not
>>>>>enough
>>>>> details on that subject, particularly with respect to H.264.
>>>>> draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best.
>>>>>
>>>>> So if we are to have the discussion again, it should occur in the
>>>>>context
>>>>> of detailed specifications and interoperability reports.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg
>>>>><jdrosen@jdrosen.net>
>>>>> wrote:
>>>>>>
>>>>>> I'm in favor of taking another run at this.
>>>>>>
>>>>>> The working group has repeatedly said that an MTI codec is something
>>>>>>we
>>>>>> need to produce. And its one of the issues holding up wider adoption
>>>>>>of the
>>>>>> technology (not the only one for sure).
>>>>>>
>>>>>> And things have changed since the last meeting, a year ago now
>>>>>>(November
>>>>>> in Vancouver). Cisco's open264 plugin shipped and now just recently
>>>>>>is
>>>>>> integrated into Firefox. iOS8 shipped with APIs for H264. There are
>>>>>>other
>>>>>> things worth noting. Will this change the minds of everyone? Surely
>>>>>>not.
>>>>>> Will it sway enough for us to achieve rough consensus? Maybe. IMHO -
>>>>>>worth
>>>>>> finding out.
>>>>>>
>>>>>> On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD
>>>>>> <agouaillard@gmail.com> wrote:
>>>>>>>
>>>>>>> +1 to not having MTI codec discussion unless some progress has been
>>>>>>>made
>>>>>>> on VP8 at MPEG. Any news on that? I'm sharing harald's  feeling
>>>>>>>that
>>>>>>>there
>>>>>>> was no change on the members position.
>>>>>>>
>>>>>>> On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand
>>>>>>> <harald@alvestrand.no> wrote:
>>>>>>>>
>>>>>>>> On 10/17/2014 12:02 AM, Bernard Aboba wrote:
>>>>>>>>>
>>>>>>>>> One thing we could do instead of wasting time on MTI is to
>>>>>>>>>actually
>>>>>>>>> make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video,
>>>>>>>>>so
>>>>>>>>>we could
>>>>>>>>> actually interoperate regardless of the codec.
>>>>>>>>
>>>>>>>>
>>>>>>>> The big argument for an MTI is actually the one stated in
>>>>>>>>-overview: It
>>>>>>>> guards against interoperability failure.
>>>>>>>>
>>>>>>>> I would like to have an ecosystem where one can field a box,
>>>>>>>>connect it
>>>>>>>> to everything else, and run well for *some* level of "well" - and
>>>>>>>>I
>>>>>>>>would
>>>>>>>> prefer that ecosystem to be one where it's possible to field the
>>>>>>>>box without
>>>>>>>> making prior arrangements with anyone about licenses.
>>>>>>>>
>>>>>>>> This argument hasn't changed one whit since last time we discussed
>>>>>>>>it.
>>>>>>>> And I don't see much movement on the specifics of the proposals
>>>>>>>>either.
>>>>>>>>
>>>>>>>> We'll have to interoperate well with the codecs we field. So using
>>>>>>>>some
>>>>>>>> time to discuss draft-ietf-rtcweb-video seems to make sense. (And
>>>>>>>>4.1 isn't
>>>>>>>> finished either. There's one sentence that needs to be removed.)
>>>>>>>>
>>>>>>>> I wouldn't say I'd be happy to not discuss this in Honolulu. But
>>>>>>>>I'd
>>>>>>>> prefer to re-discuss based on the knowledge that some significant
>>>>>>>>players
>>>>>>>> have actually changed their minds.
>>>>>>>>
>>>>>>>> At the moment, I don't see signs that any of the poll respondents
>>>>>>>>have
>>>>>>>> said "I have changed my mind".
>>>>>>>>
>>>>>>>> Harald
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Oct 16, 2014, at 2:28 PM, Martin Thomson
>>>>>>>>>> <martin.thomson@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at>
>>>>>>>>>>> wrote:
>>>>>>>>>>> And that's because something substantive has changed, or simply
>>>>>>>>>>> because
>>>>>>>>>>> wasting the WG time on this again is more entertaining than
>>>>>>>>>>>actually
>>>>>>>>>>> finishing a specification that can be independently implemented
>>>>>>>>>>>by
>>>>>>>>>>> all
>>>>>>>>>>> browser vendors? (A specification that we are nowhere near
>>>>>>>>>>>having,
>>>>>>>>>>> as far as
>>>>>>>>>>> I can tell)
>>>>>>>>>>
>>>>>>>>>> Personally, I've found the reprieve from this fight refreshing.
>>>>>>>>>>And
>>>>>>>>>> it would appear that we've made some real progress as a result.
>>>>>>>>>>I'd
>>>>>>>>>> suggest that if we don't have new information, we continue to
>>>>>>>>>>spend
>>>>>>>>>> our time productively.  If we can't find topics to occupy our
>>>>>>>>>>meeting
>>>>>>>>>> agenda time, then maybe we can free an agenda slot.
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Alex. Gouaillard, PhD, PhD, MBA
>>>>>>>
>>>>>>> 
>>>>>>>--------------------------------------------------------------------
>>>>>>>-
>>>>>>>-
>>>>>>>--------------
>>>>>>> CTO - Temasys Communications, S'pore / Mountain View
>>>>>>> President - CoSMo Software, Cambridge, MA
>>>>>>>
>>>>>>> 
>>>>>>>--------------------------------------------------------------------
>>>>>>>-
>>>>>>>-
>>>>>>>--------------
>>>>>>> sg.linkedin.com/agouaillard
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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 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 list
>>>> rtcweb@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>>
>>>
>>>
>>>-- 
>>>"Those who would give up Essential Liberty to purchase a little
>>>Temporary Safety deserve neither  Liberty nor Safety."
>>>-- Benjamin Franklin
>>>
>>>_______________________________________________
>>>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
>