[video-codec] MPEG IVC, Re: Charter issues from BoF

Rob Glidden <rob.glidden@sbcglobal.net> Mon, 10 December 2012 21:06 UTC

Return-Path: <rob.glidden@sbcglobal.net>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B4DCE21F868F for <video-codec@ietfa.amsl.com>; Mon, 10 Dec 2012 13:06:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 0z2JGauOzIfJ for <video-codec@ietfa.amsl.com>; Mon, 10 Dec 2012 13:06:05 -0800 (PST)
Received: from nm26.access.bullet.mail.mud.yahoo.com (nm26.access.bullet.mail.mud.yahoo.com []) by ietfa.amsl.com (Postfix) with ESMTP id 1F0F421F868E for <video-codec@ietf.org>; Mon, 10 Dec 2012 13:06:05 -0800 (PST)
Received: from [] by nm26.access.bullet.mail.mud.yahoo.com with NNFMP; 10 Dec 2012 21:06:04 -0000
Received: from [] by tm3.access.bullet.mail.mud.yahoo.com with NNFMP; 10 Dec 2012 21:06:04 -0000
Received: from [] by smtp112.sbc.mail.mud.yahoo.com with NNFMP; 10 Dec 2012 21:06:04 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1355173564; bh=l6udQ4+N/QOoJybD5G4PL7AWMMagldqsscynvf0ifVY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; b=buZoC8iK/2PAVGWn3+0KhNubtSHmi74rrdzC31CJN8PGdDHj0SwulreDd5Ze1hvhK9BRjOkhogVfF7zVVz42L2/e9/bsJ4Y2I+9y8AwbMP6T5R+fuzWxfqZMqy9ttg9K8bpy6N85Ab2kbXNGhu8kT3WAhbJLW5QwRzyCF0rcUmo=
X-Yahoo-Newman-Id: 543488.7731.bm@smtp112.sbc.mail.mud.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: WTEAF_MVM1ll4txfgqOFDb7kgo1HKnb25RMBV183jmRgylZ W6YAucDV_qEQAP_NSYCQ0rWZZRnBevo9pLwHL3rbI0c7NY1QV0bithm51.9H ZK3InCvvd9UioXIUhPE0kZnkDuHB_Kamgg8oYuKxWgmvgconsm.cvkpoOAcs 7mdYGjRkgsfQl98qU.POibRnyarsjsv3e5a9T7wqCrrpCSzS0gLYaakgwrnJ hyQbXOJDMXzLFJ_7s3nO3_jtmLj_R4rOS.D3M9PzjNw16KV2Y5HbgRAKstcB zCsDYsZeJ3fQCfYCGgsrqCzA7cdPZ67KpnAg0IkyjnQdOziaLIycnM2y7ZJa AQf1Q23zoLwRqkZ9CQugZm7RIRLHbh9JFRrm6WDmp6TzMO6.3_zrMtK9kjjJ mWjWJpv2Ou4QjuJYOmLG4FnawCwTrxH_UBBEmviRWFA7yVW_PQYDXeyJ7Pd2 dpeMBjhxKnywEppC11u5KecswN5J2CLW67ZiyqCuylCCjyXCsft7p6m..PSW G84BTbzV4F4mlbrL43WyH988O1o_hRwO4Vw8lt4egmhZchey0seXd5WQyIFg MQrBaCcK4flIEXfCpkuv5Z7T2x9qsDpNJExS5HI3zXE1y3TPE3YSuUO4B4f_ Rd1YPhUftJPXQi02zP8YOyWASo905mWnaB8yX9tNNBLam94VECXK50uGV9nv 2MV8hk1r6LOXyOrB2T7Z4.QMrWM4Jw.LhjP4.YRI7iK4M
X-Yahoo-SMTP: xflwSnaswBCuS46GvTyhPI4RUJpgPG5UXouB5Vxqo4t9fsHeH0I-
Received: from [] (rob.glidden@ with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 10 Dec 2012 13:06:04 -0800 PST
Message-ID: <50C64EBB.3090804@sbcglobal.net>
Date: Mon, 10 Dec 2012 13:06:03 -0800
From: Rob Glidden <rob.glidden@sbcglobal.net>
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: "Timothy B. Terriberry" <tterribe@xiph.org>
References: <20121106112625.2btpoxrylcgg8w4c@kizuka.merseine.nu> <509AC2B4.3010406@wonderhamster.org> <20121107153423.d93rypvha8w480wc@kizuka.merseine.nu> <50AAC17E.5000208@wonderhamster.org> <50BE9F0E.7070304@xiph.org>
In-Reply-To: <50BE9F0E.7070304@xiph.org>
Content-Type: multipart/alternative; boundary="------------010809090501070901040908"
Cc: video-codec@ietf.org
Subject: [video-codec] MPEG IVC, Re: Charter issues from BoF
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Video codec BoF discussion list <video-codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/video-codec>, <mailto:video-codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/video-codec>
List-Post: <mailto:video-codec@ietf.org>
List-Help: <mailto:video-codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/video-codec>, <mailto:video-codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Dec 2012 21:06:09 -0000

> I've been approached by a couple of people from the MPEG IVC effort who
> think that we can do better than liaison-style collaboration [...]

Indeed, at the last MPEG meeting, decisions were taken to approach IETF 
about potential collaboration in RF codec standardization and to make 
publicly available the IVC Test Model (ITM) v 3.0.

Internet Video Coding (aka "IVC") is a proposal for an RF codec standard 
under active exploration by MPEG.

IVC is roughly based on a patent-scrubbed version of AVS and partly 
inspired by an RF codec activity at Sun called OMC.

IVC is a work-in-progress, and improvements in the test code base and 
additional/alternative/better technologies (if RF vetted) are welcome.

There is a lot to discuss about how collaboration could proceed so I 
won't try to put it all in one email.   But in the spirit of "rough 
consensus and working code" and links below, here's a start.


MPEG 102 Meeting Resolutions, section 15.2 Internet Video Codec:

MPEG Liaison Statement to IETF RTCWeb WG and IETF video-codec BoF on the 
progress of IVC and WebVC:

IVC public repository:
- URL: http://wg11.sc29.org/ivcpublic/repos/
- Read-Only User: ivcpublic
- Read-Only Password: ivcpublic
- (posted on IVC AHG alias)

IVC Ad Hoc group alias:
- http://mpeg.chiariglione.org/meetings/shanghai12/shanghai_ahg.htm

ISO, SC29, MPEG procedures:
- http://www.itscj.ipsj.or.jp/sc29/29w7proc.htm, in particular:
- ISO/IEC Directives Part 1: Procedures for the technical work (9th 
edition, 2012)
- ISO/IEC Directives Supplement - Procedures specific to JTC 1 (3rd 
edition, 2012)
- Common Patent Policy for ITU-T/ITU-R/ISO/IEC
- Guidelines for Implementation of the Common Patent Policy for 

Ad Hoc Group rules:
- SC29: Section 1.14, ISO/IEC Directives, Part 1 Supplement --- 
Procedures specific to JTC 1
- MPEG: http://mpeg.chiariglione.org/ad-hoc_groups.php


On 12/4/2012 5:10 PM, Timothy B. Terriberry wrote:
> Spencer Dawkins wrote:
>> I'm not seeing a problem yet for this proposed working group, but I am
>> remembering that "the Internet" covers a LOT of different points in the
>> "speed/delay/reliability" space, from interconnected data centers to
>> environments that are slightly better-connected than DTNRG networks :-)
>> ... it would be great to be clear on what environments are being 
>> targeted.
> This is good advice. My primary interest is public, consumer-level, 
> best-effort networks (i.e., where people run browsers). I can try to 
> add some language to the charter to that effect if no one objects to 
> that being the focus.
>> program. I'd love for a chartered videocodec working group to have a
>> good plan for liaison relationships, and I say that without reference to
>> any other IETF working group having, or not having, a good plan for
>> liaison relationships :-)
> I've been approached by a couple of people from the MPEG IVC effort 
> who think that we can do better than liaison-style collaboration, but 
> I'm not sure what the best approach is here, yet. I will try to 
> encourage them to post their thoughts on the list.
>> I'd suggest the proposed working group community discuss whether it's
>> worth producing a video codec that is known to not be RF, early in the
>> process.
> There is some difficulty in deciding what "known to not be RF" means. 
> Some people would take the existence of an IPR disclosure---any IPR 
> disclosure---that does not make that IPR available under RF terms to 
> be an indication that the work is not RF... and in the case that the 
> disclosure is by the author of the technique in question, this is very 
> compelling. Other people are willing to investigate the real risk 
> associated with those disclosures, evaluate the effectiveness of 
> design-arounds (which do not incur an obligation to update that 
> disclosure), etc.
> Experience with Opus suggests to me that this should be handled by WG 
> consensus on a case-by-case basis, instead of with an iron-clad rule 
> in the charter. This was discussed a fair bit at the bar BoF in 
> Vancouver, and the "developed under the IPR rules of the IETF" 
> language that's currently in the charter was strongly suggested to me 
> as the best way to phrase this.
> Speaking personally, I would not support publishing as an RFC any 
> codec that I did not believe was RF.
>> I'm not saying that I have an opinion about "one codec or many", I'm
>> saying it would be helpful to understand whether one codec could meet
>> the need for a codec that's "optimized for the Internet", before
>> deciding whether to produce more than one codec.
> I think it can. The biggest challenge comes in deciding whether or not 
> to support coding tools that are not robust in the face of packet 
> loss. This includes, for example, anything which makes decisions about 
> what values to read from the bitstream based on the decoded, 
> reconstructed pixels. In the presence of loss, making one of those 
> decisions incorrectly would corrupt the rest of the frame.
> To illustrate this, one of the items mentioned in the VP9 presentation 
> included scoring candidate motion vectors by matching the 
> (already-decoded) edge pixels from neighboring blocks to the reference 
> frame at the same offset. I believe this is okay in its current form, 
> because the codebook used to decode the motion vector residual has no 
> dependency on the value of the MV being used as a predictor. But if we 
> wanted to use a scheme that _did_ depend on that value, we'd have to 
> give up the ability to look at those pixels in neighboring blocks. 
> I've had in mind for a while now a coding scheme which allows you to 
> code a MV relative to two different predictors, but unlike the normal 
> approach of "code which predictor is closer, and then code an offset 
> relative to that predictor," doesn't introduce any redundancy in the 
> coding. This depends on exactly what those two predictors are 
> (consider the case where they're the same, for example), so it 
> wouldn't be compatible with this VP9 technique for deriving the list 
> of predictors.
> But even in this case, we could pick which of the two approaches works 
> better on average, or even allow both techniques to be used, and 
> switch between them. Video frames have enough bits to make this kind 
> of switching at the frame or even smaller levels quite practical, and 
> you could pick up quite a lot of alternate algorithms like this before 
> it made sense to give up all the things that _are_ common in the two 
> use cases and have two completely separate codecs.
>> If I'm understanding what other people are saying, I'm not hearing "need
>> old technology where patents have expired" as a strategy for video
>> codecs, but It might be helpful for the proposed working group community
>> to be clear on how much new technology people are planning to define,
>> early on.
> I think we should be doing both things. If you look carefully at some 
> of the drafts that have already been submitted, you'll see some of the 
> references are _very_ old. There's a lot of research out there that's 
> been around for a long time, but never made it into a widely deployed 
> codec. Sometimes that's for very good reasons. Sometimes it's because 
> design decisions which were important at the time have become less so 
> as Moore's law has changed the best operating point on the chip 
> area/clock speed/power usage frontier. Sometimes it's because the 
> technique introduced practical problems which are solvable, but no one 
> ever attempted to solve them.
> We (Mozilla) are also exploring ways we can actually publish solid 
> information about why we think the the codec will be royalty-free 
> (once it is finished). As you may know, it is normally not in our 
> interest to do so (it is basically mapping out your defense, or at 
> least part of it, to any potential litigants), but it may wind up 
> being worth the trade-off.
>> I hope this is helpful. And again, I think the important thing is that
>> the proposed working group community take Cullen's suggestions
>> seriously, more than what the community decides about them.
> I think this (and Cullen's feedback generally) has been very helpful. 
> I hope to submit an updated version of the charter incorporating a 
> bunch of the feedback received thus far before next week.
> _______________________________________________
> video-codec mailing list
> video-codec@ietf.org
> https://www.ietf.org/mailman/listinfo/video-codec