From nobody Tue Feb  3 14:15:19 2015
Return-Path: <dabenham@gmail.com>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B7B1A8783 for <video-codec@ietfa.amsl.com>; Tue,  3 Feb 2015 14:15:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.005
X-Spam-Level: 
X-Spam-Status: No, score=-1.005 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PLING_QUERY=0.994, SPF_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 G9mBW23GiZEe for <video-codec@ietfa.amsl.com>; Tue,  3 Feb 2015 14:15:15 -0800 (PST)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 899BD1A1AB0 for <video-codec@ietf.org>; Tue,  3 Feb 2015 14:14:35 -0800 (PST)
Received: by mail-ie0-f169.google.com with SMTP id rl12so28844892iec.0 for <video-codec@ietf.org>; Tue, 03 Feb 2015 14:14:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=PjbYDPMv1Zd0DLSvKU8fEmZICQAVAu5qDQtqPDBpKXA=; b=p7l1iCOHhHGze6L/Hf11dJwFiRQWwH4RFIq+97ZHphGrI2qOlfnss9YI2cu45yBYTQ 8/ckQdD3WmIXGJ0wmBOWnzCmoHbh5BD72E9BSdsvkBD75xBMEBeW+0TeRp/zjwMllXtU PYP3cBD7mnXTZFnM37lCWsGpLy82mZJlBSfrCXfY9m/Ez7ZlKWx+sbK4quRWBB8/8JZq cQLxOFJLIKKGnwXyzd/hVzWuvsQhjmit0M9A/4csNZIibj8loUyC1MyzF/H5sV+hVF7I Z7R8lXmRuGe6wbLIS3o4jwVLvhx5rrF/rfgqLsxFomx0NkpLWZlxuS4A1zpVXe2iGIdQ JOdQ==
MIME-Version: 1.0
X-Received: by 10.107.46.213 with SMTP id u82mr31915224iou.68.1423001674741; Tue, 03 Feb 2015 14:14:34 -0800 (PST)
Received: by 10.36.45.130 with HTTP; Tue, 3 Feb 2015 14:14:34 -0800 (PST)
Date: Tue, 3 Feb 2015 14:14:34 -0800
Message-ID: <CAM5V9Z8sy1M9wX4bBu6NhkeKN--XcgVJoLehUNw1B0pGyo2i=w@mail.gmail.com>
From: David Benham <dabenham@gmail.com>
To: video-codec@ietf.org
Content-Type: multipart/alternative; boundary=001a11c15e3e567dc7050e366535
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/lM1WOulrL1DzfGpMtUGschQItJ4>
Subject: [video-codec] Revised Charter video-codec - comments, feedback?!
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 03 Feb 2015 22:15:18 -0000

--001a11c15e3e567dc7050e366535
Content-Type: text/plain; charset=UTF-8

Latest revision proposed below.

For those familiar with the prior version, this revision is shorter as it
attempted to only include items consistent with typical, concise WG
Charter.   Thus you will find of the more technically specific requirements
are deferred to (informational) requirements doc as shown on the milestone
list.  Remaining requirements focus on preforming well even in the chaotic,
real-world Internet, being competitive with the state-of-art of popular
codec(s) when the spec is completed and explicitly stating that verifiable
IPR status (eg, may include research from another entity outside IETF).


Additional polishing is desired ... comments/feedback please!



The following is also online at
https://daala.etherpad.mozilla.org/video-codec-charter
-------------------------------------------------------------------------------------------------------------------------

video-codec-charter

Objectives

This WG is chartered to produce a high-quality video codec that meets the
following conditions:

1. Is competitive with current video codecs in widespread use.

2. Is optimized for use in interactive web applications.

3. Is viewed as having IPR licensing terms that allow it to be widely
implemented and deployed.

To elaborate, this video codec will need to be commercially interesting to
implement by being competitive with the video codecs in widespread use at
the time it is finalized.

This video codec will need to be optimized for the real-world conditions of
the public, best-effort Internet. It should include, but may not be limited
to, the ability to support fast and flexible congestion control and rate
adaptation, the ability to quickly join broadcast streams and the ability
to be optimized for captures of content typically shared in interactive
communications.

The objective is to produce a video codec that can be implemented,
distributed, and deployed by open source and closed source software as well
as implemented in specialized hardware.

The WG will prefer algorithms or tools where there are verifiable reasons
to believe they are RF over algorithms or tools where there is RF
uncertainty or known active IPR claims with royalty liability potential.
The codec specification will document why it believes that each part is
likely to be RF, which will help adoption of the codec. This can include
references to old prior art and/or patent research information.


Process

The core technical considerations for such a codec include, but are not
necessarily limited to, the following:

1. High compression efficiency that is competitive with existing popular
video codecs.

2. Reasonable computational complexity that permits real-time operation on
existing, popular hardware, and efficient implementation in new hardware
designs.

3. Use in interactive applications, such as point-to-point video calls,
multi-party video conferencing, telepresence, teleoperation, and in-game
video chat.

4. Resilient in the real-world transport conditions of the Internet, such as
the flexibility to rapidly respond to changing bandwidth availability
and loss rates, etc.

5. Integratable with common Internet applications and Web APIs (e.g., the
HTML5 <video> tag and WebRTC API, live streaming, adaptive streaming, and
common media-related APIs without depending on any particular API.).

The working group shall heed the preference stated in BCP 79: "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."  This preference cannot guarantee
that the working group will produce an IPR unencumbered codec.


Non-Goals

Optimizing for very low bit rates (typically below 256 kbps) is out of
scope because such work might necessitate specialized optimizations.

It is explicitly not a goal of the working group to produce a codec that
will be mandated for implementation across the entire IETF or Internet
community.

Based on the working group's analysis of the design space, the working
group might determine that it needs to produce a codec with multiple
modes of operation. The WG may produce a codec that is highly configurable,
operating in many different modes with the ability to smoothly be extended
with new modes in the future.


Collaboration

In completing its work, the working group will liaise with other relevant
IETF working groups and SDOs, including PAYLOAD, RMCAT, RTCWEB, MMUSIC, and
other IETF WGs that make use of or handle negotiation of codecs; W3C
working groups including HTML, Device APIs and WebRTC; and ITU-T (Study
group 16) and ISO/IEC (JTC1/SC29 WG11).

It is expected that an open source reference version of the codec will be
developed in parallel with the working group.

The WG will accept and consider in its decision process input received from
external parties concerning IPR risk associated with proposed algorithms.


Deliverables

1. A document that outlines the IPR terms the working group wishes
contributors to the specifications would use to license their IPR.

2. A set of technical requirements and evaluation metrics. The WG may
choose to pursue publication of these in an RFC if it deems that to be
beneficial.

3. Proposed Standard specification of an encoder and decoder where the
normative algorithms are described in English text and not as code.

4. Specification of a storage format for file transfer of the encoded video
as an elementary stream compatible with existing, popular container formats
to support non-interactive (HTTP) streaming, including live encoding and
both progressive and large-chunk downloads. The WG will not develop a new
container format.

5. A collection of test results, either from tests conducted by the working
group or made publicly available elsewhere, characterizing the performance
of the codec. This document shall be informational.


Goals and Milestones

TBD  IPR licensing terms goals (Informational)

TBD  Requirements to IESG, if the WG so chooses (Informational)

TBD  Submit codec specification to IESG (Standards Track)

TBD  Submit storage format specification to IESG (Standards Track)

TBD  Testing document to IESG (Informational)

--001a11c15e3e567dc7050e366535
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Latest revision proposed below. =C2=A0<br><br>For those fa=
miliar with the prior version, this revision is shorter as it attempted to =
only include items consistent with typical, concise WG Charter. =C2=A0 Thus=
 you will find of the more technically specific requirements are deferred t=
o (informational) requirements doc as shown on the milestone list.=C2=A0 Re=
maining requirements focus on preforming well even in the chaotic, real-wor=
ld Internet, being competitive with the state-of-art of popular codec(s) wh=
en the spec is completed and explicitly stating that verifiable IPR status =
(eg, may include research from another entity outside IETF). =C2=A0 =C2=A0 =
=C2=A0<br><br>Additional polishing is desired ... comments/feedback please!=
<br><br><br><br>The following is also online at <a href=3D"https://daala.et=
herpad.mozilla.org/video-codec-charter">https://daala.etherpad.mozilla.org/=
video-codec-charter</a><br>------------------------------------------------=
-------------------------------------------------------------------------<b=
r><br>video-codec-charter<br><br>Objectives<br><br>This WG is chartered to =
produce a high-quality video codec that meets the following conditions:<br>=
<br>1. Is competitive with current video codecs in widespread use.<br><br>2=
. Is optimized for use in interactive web applications.<br><br>3. Is viewed=
 as having IPR licensing terms that allow it to be widely implemented and d=
eployed.<br><br>To elaborate, this video codec will need to be commercially=
 interesting to implement by being competitive with the video codecs in wid=
espread use at the time it is finalized.<br><br>This video codec will need =
to be optimized for the real-world conditions of the public, best-effort In=
ternet. It should include, but may not be limited to, the ability to suppor=
t fast and flexible congestion control and rate adaptation, the ability to =
quickly join broadcast streams and the ability to be optimized for captures=
 of content typically shared in interactive communications. =C2=A0<br><br>T=
he objective is to produce a video codec that can be implemented, distribut=
ed, and deployed by open source and closed source software as well as imple=
mented in specialized hardware.<br><br>The WG will prefer algorithms or too=
ls where there are verifiable reasons to believe they are RF over algorithm=
s or tools where there is RF uncertainty or known active IPR claims with ro=
yalty liability potential. The codec specification will document why it bel=
ieves that each part is likely to be RF, which will help adoption of the co=
dec. This can include references to old prior art and/or patent research in=
formation.<br><br><br>Process<br><br>The core technical considerations for =
such a codec include, but are not necessarily limited to, the following:<br=
><br>1. High compression efficiency that is competitive with existing popul=
ar video codecs.<br><br>2. Reasonable computational complexity that permits=
 real-time operation on existing, popular hardware, and efficient implement=
ation in new hardware designs.<br><br>3. Use in interactive applications, s=
uch as point-to-point video calls, multi-party video conferencing, telepres=
ence, teleoperation, and in-game video chat.<br><br>4. Resilient in the rea=
l-world transport conditions of the Internet, such as<br>the flexibility to=
 rapidly respond to changing bandwidth availability<br>and loss rates, etc.=
<br><br>5. Integratable with common Internet applications and Web APIs (e.g=
., the HTML5 &lt;video&gt; tag and WebRTC API, live streaming, adaptive str=
eaming, and common media-related APIs without depending on any particular A=
PI.).<br><br>The working group shall heed the preference stated in BCP 79: =
&quot;In<br>general, IETF working groups prefer technologies with no known =
IPR<br>claims or, for technologies with claims against them, an offer of<br=
>royalty-free licensing.&quot; =C2=A0This preference cannot guarantee<br>th=
at the working group will produce an IPR unencumbered codec.<br><br><br>Non=
-Goals<br><br>Optimizing for very low bit rates (typically below 256 kbps) =
is out of<br>scope because such work might necessitate specialized optimiza=
tions.<br><br>It is explicitly not a goal of the working group to produce a=
 codec that will be mandated for implementation across the entire IETF or I=
nternet community.<br><br>Based on the working group&#39;s analysis of the =
design space, the working<br>group might determine that it needs to produce=
 a codec with multiple<br>modes of operation. The WG may produce a codec th=
at is highly configurable, operating in many different modes with the abili=
ty to smoothly be extended with new modes in the future.<br><br><br>Collabo=
ration<br><br>In completing its work, the working group will liaise with ot=
her relevant IETF working groups and SDOs, including PAYLOAD, RMCAT, RTCWEB=
, MMUSIC, and other IETF WGs that make use of or handle negotiation of code=
cs; W3C working groups including HTML, Device APIs and WebRTC; and ITU-T (S=
tudy group 16) and ISO/IEC (JTC1/SC29 WG11).<br><br>It is expected that an =
open source reference version of the codec will be developed in parallel wi=
th the working group.<br><br>The WG will accept and consider in its decisio=
n process input received from external parties concerning IPR risk associat=
ed with proposed algorithms.<br><br><br>Deliverables<br><br>1. A document t=
hat outlines the IPR terms the working group wishes contributors to the spe=
cifications would use to license their IPR.<br><br>2. A set of technical re=
quirements and evaluation metrics. The WG may choose to pursue publication =
of these in an RFC if it deems that to be beneficial.<br><br>3. Proposed St=
andard specification of an encoder and decoder where the normative algorith=
ms are described in English text and not as code.<br><br>4. Specification o=
f a storage format for file transfer of the encoded video as an elementary =
stream compatible with existing, popular container formats to support non-i=
nteractive (HTTP) streaming, including live encoding and both progressive a=
nd large-chunk downloads. The WG will not develop a new container format.<b=
r><br>5. A collection of test results, either from tests conducted by the w=
orking group or made publicly available elsewhere, characterizing the perfo=
rmance of the codec. This document shall be informational.<br><br><br>Goals=
 and Milestones<br><br>TBD =C2=A0IPR licensing terms goals (Informational)<=
br><br>TBD =C2=A0Requirements to IESG, if the WG so chooses (Informational)=
<br><br>TBD =C2=A0Submit codec specification to IESG (Standards Track)<br><=
br>TBD =C2=A0Submit storage format specification to IESG (Standards Track)<=
br><br>TBD =C2=A0Testing document to IESG (Informational)<br></div>

--001a11c15e3e567dc7050e366535--


From nobody Tue Feb  3 20:37:41 2015
Return-Path: <tterribe@xiph.org>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845271A1BE6 for <video-codec@ietfa.amsl.com>; Tue,  3 Feb 2015 20:37:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.283
X-Spam-Level: 
X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, PLING_QUERY=0.994, RCVD_IN_DNSWL_MED=-2.3, SPF_FAIL=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 T8q4MS5xXJ_8 for <video-codec@ietfa.amsl.com>; Tue,  3 Feb 2015 20:37:37 -0800 (PST)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D96D51A1A9E for <video-codec@ietf.org>; Tue,  3 Feb 2015 20:37:37 -0800 (PST)
Received: from [10.124.97.85] (jurys-heathrow-gw.uk.cw.net [194.70.64.250]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 918E6F2238 for <video-codec@ietf.org>; Tue,  3 Feb 2015 20:37:36 -0800 (PST)
Message-ID: <54D1A20F.2050208@xiph.org>
Date: Tue, 03 Feb 2015 20:37:35 -0800
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
MIME-Version: 1.0
To: video-codec@ietf.org
References: <CAM5V9Z8sy1M9wX4bBu6NhkeKN--XcgVJoLehUNw1B0pGyo2i=w@mail.gmail.com>
In-Reply-To: <CAM5V9Z8sy1M9wX4bBu6NhkeKN--XcgVJoLehUNw1B0pGyo2i=w@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/S2TWPzHIaq9Co-CD3H9TxaLTpQE>
Subject: Re: [video-codec] Revised Charter video-codec - comments, feedback?!
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 04 Feb 2015 04:37:40 -0000

David Benham wrote:
> For those familiar with the prior version, this revision is shorter as
> it attempted to only include items consistent with typical, concise WG
> Charter.   Thus you will find of the more technically specific

I think this reads much better now.

> In completing its work, the working group will liaise with other
> relevant IETF working groups and SDOs, including PAYLOAD, RMCAT, RTCWEB,
> MMUSIC, and other IETF WGs that make use of or handle negotiation of
> codecs; W3C working groups including HTML, Device APIs and WebRTC; and
> ITU-T (Study group 16) and ISO/IEC (JTC1/SC29 WG11).

I know that in the pre-BoF meeting in Toronto several people made 
comments that attempting to coordinate with ITU/ISO for possible joint 
publication was probably not worth the effort given the timescales 
required to set up joint work like JVT and JCTVC in the past and the 
lack of interest in similar attempts during CODEC. Given that, do people 
feel there's much value in liaising with these bodies at all, or should 
we drop those groups from this list entirely?


From nobody Wed Feb  4 14:45:09 2015
Return-Path: <dabenham@gmail.com>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0191A1B1C for <video-codec@ietfa.amsl.com>; Wed,  4 Feb 2015 14:45:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 yFnnzrfNftVe for <video-codec@ietfa.amsl.com>; Wed,  4 Feb 2015 14:44:59 -0800 (PST)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 457E51A1B92 for <video-codec@ietf.org>; Wed,  4 Feb 2015 14:44:59 -0800 (PST)
Received: by mail-ie0-f182.google.com with SMTP id ar1so5861194iec.13 for <video-codec@ietf.org>; Wed, 04 Feb 2015 14:44:58 -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 :content-type; bh=aGWofNl4oowrWwS6r56MLSrAx+UP1JEf0/sJupNtKLQ=; b=pg24gfHcJ32bx3HmlKAp8rJDRfX+NWkXmq0AbXfbepJ6GRI2uFBEz9rCcdbxmLWVlF OlAPq0Sni/ojGDxRceFB2bZ1y0UXEaOduE65lEAdrHt4c0jYp83Xv+iULhfb+pMrHybN SGFj/BGBD49uHeU1CHNfwNjw6FcgAUDrntqcxUfoPUo+pVJIt6514B9SA8CCM1kDtqfZ J1mbmkst7bHvoG1wN1B4+MgnSYZcwC1EX2NzRRRzE+d5wTWL9KWTAK2pc00w5Sk3g6lE nrBWauHUxZXR2EP3B6NRqsG/GmVFVzO6r7riS0qcj5D3djL7GwXJF8moeP2NUTQlcc/C 7Wcg==
MIME-Version: 1.0
X-Received: by 10.107.155.197 with SMTP id d188mr802405ioe.29.1423089898449; Wed, 04 Feb 2015 14:44:58 -0800 (PST)
Received: by 10.36.45.130 with HTTP; Wed, 4 Feb 2015 14:44:58 -0800 (PST)
In-Reply-To: <mailman.122.1423080069.8838.video-codec@ietf.org>
References: <mailman.122.1423080069.8838.video-codec@ietf.org>
Date: Wed, 4 Feb 2015 14:44:58 -0800
Message-ID: <CAM5V9Z9Wtv7gasFAoxkYTmFBqV+jyu4CRVawAt_kdLZA=VtSjg@mail.gmail.com>
From: David Benham <dabenham@gmail.com>
To: video-codec@ietf.org, tterribe@xiph.org
Content-Type: multipart/alternative; boundary=001a1140c8fee18b93050e4aefbe
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/olIfo66rmFgeHKWJ9TZIE5jgGbg>
Subject: Re: [video-codec] video-codec Digest, Vol 18, Issue 2
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 04 Feb 2015 22:45:04 -0000

--001a1140c8fee18b93050e4aefbe
Content-Type: text/plain; charset=UTF-8

Interested in others' opinion, but the thinking was more FYI-type liaisons
to IEC/ISO/ITU.   Thus not too much of a time investment.



>  In completing its work, the working group will liaise with other
>> relevant IETF working groups and SDOs, including PAYLOAD, RMCAT, RTCWEB,
>> MMUSIC, and other IETF WGs that make use of or handle negotiation of
>> codecs; W3C working groups including HTML, Device APIs and WebRTC; and
>> ITU-T (Study group 16) and ISO/IEC (JTC1/SC29 WG11).
>>
>
> I know that in the pre-BoF meeting in Toronto several people made comments
> that attempting to coordinate with ITU/ISO for possible joint publication
> was probably not worth the effort given the timescales required to set up
> joint work like JVT and JCTVC in the past and the lack of interest in
> similar attempts during CODEC. Given that, do people feel there's much
> value in liaising with these bodies at all, or should we drop those groups
> from this list entirely?
>
>

--001a1140c8fee18b93050e4aefbe
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>Interested in others&#39; opinion, but the thinking was more FYI-type liai=
sons to IEC/ISO/ITU. =C2=A0 Thus not too much of a time investment.</div><d=
iv><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
In completing its work, the working group will liaise with other<br>
relevant IETF working groups and SDOs, including PAYLOAD, RMCAT, RTCWEB,<br=
>
MMUSIC, and other IETF WGs that make use of or handle negotiation of<br>
codecs; W3C working groups including HTML, Device APIs and WebRTC; and<br>
ITU-T (Study group 16) and ISO/IEC (JTC1/SC29 WG11).<br>
</blockquote>
<br>
I know that in the pre-BoF meeting in Toronto several people made comments =
that attempting to coordinate with ITU/ISO for possible joint publication w=
as probably not worth the effort given the timescales required to set up jo=
int work like JVT and JCTVC in the past and the lack of interest in similar=
 attempts during CODEC. Given that, do people feel there&#39;s much value i=
n liaising with these bodies at all, or should we drop those groups from th=
is list entirely?<br>
<br></blockquote></div></div></div>

--001a1140c8fee18b93050e4aefbe--


From nobody Wed Feb  4 21:03:09 2015
Return-Path: <tterribe@xiph.org>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D2D1A03A5 for <video-codec@ietfa.amsl.com>; Wed,  4 Feb 2015 21:03:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.277
X-Spam-Level: 
X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_FAIL=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 NkOu4DKdcyEp for <video-codec@ietfa.amsl.com>; Wed,  4 Feb 2015 21:03:05 -0800 (PST)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 046611A0104 for <video-codec@ietf.org>; Wed,  4 Feb 2015 21:03:04 -0800 (PST)
Received: from [10.124.97.227] (jurys-heathrow-gw.uk.cw.net [194.70.64.250]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id D81A7F2651 for <video-codec@ietf.org>; Wed,  4 Feb 2015 21:03:03 -0800 (PST)
Message-ID: <54D2F985.10700@xiph.org>
Date: Wed, 04 Feb 2015 21:03:01 -0800
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
MIME-Version: 1.0
To: video-codec@ietf.org
References: <mailman.122.1423080069.8838.video-codec@ietf.org> <CAM5V9Z9Wtv7gasFAoxkYTmFBqV+jyu4CRVawAt_kdLZA=VtSjg@mail.gmail.com>
In-Reply-To: <CAM5V9Z9Wtv7gasFAoxkYTmFBqV+jyu4CRVawAt_kdLZA=VtSjg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/Ec_nLUe7l0MC-i1qUOtYFd6ibrQ>
Subject: Re: [video-codec] video-codec Digest, Vol 18, Issue 2
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 05 Feb 2015 05:03:07 -0000

David Benham wrote:
> Interested in others' opinion, but the thinking was more FYI-type
> liaisons to IEC/ISO/ITU.   Thus not too much of a time investment.

Sure... I don't have an objection to doing it, I just wanted to make 
sure we were accurately capturing the sense of the room in Toronto. If 
no one else speaks up, let's leave it in.


From nobody Thu Feb  5 01:24:49 2015
Return-Path: <mzanaty@cisco.com>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B761A0077 for <video-codec@ietfa.amsl.com>; Thu,  5 Feb 2015 01:24:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 42cO20bvlPk5 for <video-codec@ietfa.amsl.com>; Thu,  5 Feb 2015 01:24:33 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC0151A0021 for <video-codec@ietf.org>; Thu,  5 Feb 2015 01:24:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=706; q=dns/txt; s=iport; t=1423128272; x=1424337872; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1cNE7DDJ6IMeD2d4KwO/xxY1MJKf9tKfBLhV7OfoDmk=; b=HyZX81yVDOngLOA1zeOdHGFK/ZTygtNldRWulccLdayD/vvrQYwBKzF9 QiqW0mmP7QXScirftLpEp+1Uj804Dhwgc2zcPhTBj9/8nRwg6IB2FoJDm +u2AcMG1j6h/0tiGsD98TrpcgbkJynAriDc9NYKJdXK+RqhfYxV+QciV7 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BOBQAsNtNU/40NJK1agwaBKwTIOAKBI0MBAQEBAX2EDQEBBIEJAgEIGC4yJQIEARKILdYYAQEBAQEBAQMBAQEBAQEBG49/hCkBBIl0hSCJKpJqIoNub4FEfgEBAQ
X-IronPort-AV: E=Sophos;i="5.09,522,1418083200"; d="scan'208";a="120696445"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-8.cisco.com with ESMTP; 05 Feb 2015 09:24:32 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t159OWAW013079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Feb 2015 09:24:32 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.12]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Thu, 5 Feb 2015 03:24:32 -0600
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: "Timothy B. Terriberry" <tterribe@xiph.org>, "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: [video-codec] video-codec Digest, Vol 18, Issue 2
Thread-Index: AQHQQSWMBsGZxkTnjkKsb+iuvVB+ow==
Date: Thu, 5 Feb 2015 09:24:31 +0000
Message-ID: <D0F89FDF.43C2A%mzanaty@cisco.com>
References: <mailman.122.1423080069.8838.video-codec@ietf.org> <CAM5V9Z9Wtv7gasFAoxkYTmFBqV+jyu4CRVawAt_kdLZA=VtSjg@mail.gmail.com> <54D2F985.10700@xiph.org>
In-Reply-To: <54D2F985.10700@xiph.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.7.141117
x-originating-ip: [64.100.32.216]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <5DFBB56B9DA61E4CB1A25D3895001DD2@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/P06mj3GkiMzAIdAgHkBVz2ecc1I>
Subject: Re: [video-codec] video-codec Digest, Vol 18, Issue 2
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 05 Feb 2015 09:24:44 -0000

I think ITU/ISO/IEC liaisons are a good idea, even if you don=B9t expect
useful feedback. Just announcing efforts to make others aware is generally
a good idea. This also applies within IETF, e.g. announce on payload,
codec, rtcweb, and perhaps even avtcore, avtext and mmusic.

Mo

On 2/5/15, 12:03 AM, Timothy B. Terriberry <tterribe@xiph.org> wrote:
David Benham wrote:
> Interested in others' opinion, but the thinking was more FYI-type
> liaisons to IEC/ISO/ITU.   Thus not too much of a time investment.
Sure... I don't have an objection to doing it, I just wanted to make
sure we were accurately capturing the sense of the room in Toronto. If
no one else speaks up, let's leave it in.


From nobody Thu Feb  5 05:17:21 2015
Return-Path: <rlb@ipv.sx>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151F61A878C for <video-codec@ietfa.amsl.com>; Thu,  5 Feb 2015 05:17:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 BNdWHKpDuORc for <video-codec@ietfa.amsl.com>; Thu,  5 Feb 2015 05:17:13 -0800 (PST)
Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 649521A8796 for <video-codec@ietf.org>; Thu,  5 Feb 2015 05:17:13 -0800 (PST)
Received: by mail-lb0-f180.google.com with SMTP id b6so7000160lbj.11 for <video-codec@ietf.org>; Thu, 05 Feb 2015 05:17:12 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dz6HqRVIvG4P85+jJ4WvEpIuIpbA6uDUxL5hnTAvUDM=; b=SDWQE9lGP2Te+gLJIheKl7psqzWus4+GwNw0b192xJ2ILUm0cY5Gvv0dCOIYh00Gm6 dSuMrDwN5i5T2PcMUeC/KWbWaVFU2/qB0RP6HinReoHUtYjCFe2lk5qK38pP5e5eEtCE 1tU5EUyGOFPflrm9yuyCJ4XTzabNgFUBkhwFXaZCy0rDDwhXWYSpjM/x3AeumQJTUJIM 8huCmL9NHrCr6na6jEAhwn+nElS1kL3la7/eVTlhHxmKKRRmCigsGvbROjtEmV+CR9Ed I58qIydRWYgyA/r8PcmMnzHw2osInnyU32WtqsopoA2/WuEkcQ0zQuwe2Sll9Eu9NjTu 1gXQ==
X-Gm-Message-State: ALoCoQkkj5oKVXutd7zXo9+o6R/SJ8gTLYr+RTDz+9bjfRHiuq0RWID5zV7MzhJEUIk52+p/HJNz
MIME-Version: 1.0
X-Received: by 10.152.7.7 with SMTP id f7mr3364225laa.27.1423142231880; Thu, 05 Feb 2015 05:17:11 -0800 (PST)
Received: by 10.25.201.86 with HTTP; Thu, 5 Feb 2015 05:17:11 -0800 (PST)
In-Reply-To: <D0F89FDF.43C2A%mzanaty@cisco.com>
References: <mailman.122.1423080069.8838.video-codec@ietf.org> <CAM5V9Z9Wtv7gasFAoxkYTmFBqV+jyu4CRVawAt_kdLZA=VtSjg@mail.gmail.com> <54D2F985.10700@xiph.org> <D0F89FDF.43C2A%mzanaty@cisco.com>
Date: Thu, 5 Feb 2015 08:17:11 -0500
Message-ID: <CAL02cgSf100fmL0D+6xV4HvE0MXPaoFyQpyyosXvQbRSCEKV_Q@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
Content-Type: multipart/alternative; boundary=001a11c2870a324abc050e571f3e
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/vfmrCuPDOSG5Y6Du8R26hXCE4Zs>
Cc: "video-codec@ietf.org" <video-codec@ietf.org>, "Timothy B. Terriberry" <tterribe@xiph.org>
Subject: Re: [video-codec] video-codec Digest, Vol 18, Issue 2
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 05 Feb 2015 13:17:18 -0000

--001a11c2870a324abc050e571f3e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

FWIW, there is a standard practice of proposed new work in the IETF being
sent to a group of SDOs on new-work@ietf.org as part of the charter review
process.  I don't remember if ITU/ISO/IEC are on that list, but I think
there is at least some representation.

--Richard


On Thu, Feb 5, 2015 at 4:24 AM, Mo Zanaty (mzanaty) <mzanaty@cisco.com>
wrote:

> I think ITU/ISO/IEC liaisons are a good idea, even if you don=C2=B9t expe=
ct
> useful feedback. Just announcing efforts to make others aware is generall=
y
> a good idea. This also applies within IETF, e.g. announce on payload,
> codec, rtcweb, and perhaps even avtcore, avtext and mmusic.
>
> Mo
>
> On 2/5/15, 12:03 AM, Timothy B. Terriberry <tterribe@xiph.org> wrote:
> David Benham wrote:
> > Interested in others' opinion, but the thinking was more FYI-type
> > liaisons to IEC/ISO/ITU.   Thus not too much of a time investment.
> Sure... I don't have an objection to doing it, I just wanted to make
> sure we were accurately capturing the sense of the room in Toronto. If
> no one else speaks up, let's leave it in.
>
> _______________________________________________
> video-codec mailing list
> video-codec@ietf.org
> https://www.ietf.org/mailman/listinfo/video-codec
>

--001a11c2870a324abc050e571f3e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">FWIW=
, there is a standard practice of proposed new work in the IETF being sent =
to a group of SDOs on <a href=3D"mailto:new-work@ietf.org">new-work@ietf.or=
g</a> as part of the charter review process.=C2=A0 I don&#39;t remember if =
ITU/ISO/IEC are on that list, but I think there is at least some representa=
tion.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">=
--Richard</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quo=
te"><br></div><div class=3D"gmail_quote">On Thu, Feb 5, 2015 at 4:24 AM, Mo=
 Zanaty (mzanaty) <span dir=3D"ltr">&lt;<a href=3D"mailto:mzanaty@cisco.com=
" target=3D"_blank">mzanaty@cisco.com</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">I think ITU/ISO/IEC liaisons are a good idea, even if yo=
u don=C2=B9t expect<br>
useful feedback. Just announcing efforts to make others aware is generally<=
br>
a good idea. This also applies within IETF, e.g. announce on payload,<br>
codec, rtcweb, and perhaps even avtcore, avtext and mmusic.<br>
<span><font color=3D"#888888"><br>
Mo<br>
</font></span><div><div><br>
On 2/5/15, 12:03 AM, Timothy B. Terriberry &lt;<a href=3D"mailto:tterribe@x=
iph.org" target=3D"_blank">tterribe@xiph.org</a>&gt; wrote:<br>
David Benham wrote:<br>
&gt; Interested in others&#39; opinion, but the thinking was more FYI-type<=
br>
&gt; liaisons to IEC/ISO/ITU.=C2=A0 =C2=A0Thus not too much of a time inves=
tment.<br>
Sure... I don&#39;t have an objection to doing it, I just wanted to make<br=
>
sure we were accurately capturing the sense of the room in Toronto. If<br>
no one else speaks up, let&#39;s leave it in.<br>
<br>
_______________________________________________<br>
video-codec mailing list<br>
<a href=3D"mailto:video-codec@ietf.org" target=3D"_blank">video-codec@ietf.=
org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/video-codec" target=3D"_bl=
ank">https://www.ietf.org/mailman/listinfo/video-codec</a><br>
</div></div></blockquote></div><br></div></div>

--001a11c2870a324abc050e571f3e--


From nobody Thu Feb  5 05:23:08 2015
Return-Path: <dromasca@avaya.com>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C0F1A882A for <video-codec@ietfa.amsl.com>; Thu,  5 Feb 2015 05:22:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.92
X-Spam-Level: 
X-Spam-Status: No, score=-4.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 fq1KXUcyQs2S for <video-codec@ietfa.amsl.com>; Thu,  5 Feb 2015 05:22:44 -0800 (PST)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D8721A8841 for <video-codec@ietf.org>; Thu,  5 Feb 2015 05:22:30 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoMGAJRt01TGmAcV/2dsb2JhbABagkMhIlJZBIJ9rH4BAQEBAQEGkhodAQiFcgIcgQlDAQEBAQEBfIQMAQEBAQMBAQEPEQpBCxACAQgNAQMEAQEBCh0DAgICJQsUCQgCBAENBQgaiAsBDLUBikmWMQEBAQEBAQEBAQEBAQEBAQEBAQEBAReGBIlDLQQGAQmCXy6BEwWPFINQhyeFCIwVIoFbghNvAQGBQn4BAQE
X-IronPort-AV: E=Sophos;i="5.09,524,1418101200";  d="scan'208,217";a="105581293"
Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 05 Feb 2015 08:22:28 -0500
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 05 Feb 2015 08:22:27 -0500
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Thu, 5 Feb 2015 14:22:25 +0100
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: Richard Barnes <rlb@ipv.sx>, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
Thread-Topic: [video-codec] video-codec Digest, Vol 18, Issue 2
Thread-Index: AQHQQUYVjfXFxe/8AEmF9XrK2dR/ipziCotQ
Date: Thu, 5 Feb 2015 13:22:26 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C98287C@AZ-FFEXMB04.global.avaya.com>
References: <mailman.122.1423080069.8838.video-codec@ietf.org> <CAM5V9Z9Wtv7gasFAoxkYTmFBqV+jyu4CRVawAt_kdLZA=VtSjg@mail.gmail.com> <54D2F985.10700@xiph.org> <D0F89FDF.43C2A%mzanaty@cisco.com> <CAL02cgSf100fmL0D+6xV4HvE0MXPaoFyQpyyosXvQbRSCEKV_Q@mail.gmail.com>
In-Reply-To: <CAL02cgSf100fmL0D+6xV4HvE0MXPaoFyQpyyosXvQbRSCEKV_Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.47]
Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C98287CAZFFEXMB04globa_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/WEOxsRM3s-iGpPYgG9JwI5cf2bw>
Cc: Scott Mansfield <scott.mansfield@ericsson.com>, "video-codec@ietf.org" <video-codec@ietf.org>, Eliot Lear <lear@cisco.com>, "Timothy B. Terriberry" <tterribe@xiph.org>
Subject: Re: [video-codec] video-codec Digest, Vol 18, Issue 2
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 05 Feb 2015 13:22:52 -0000

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C98287CAZFFEXMB04globa_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SWYgSSBhbSBub3QgbWlzdGFrZW4gSVRVLVQgcmVwcmVzZW50YXRpdmVzIGZyb20gSVRVLVQgYXJl
IG9uIHRoaXMgbGlzdC4gSVNPL0lFRCBhcmUgZGlmZmVyZW50IHRoYW4gSVRVLCBhbmQgSSBkbyBu
b3Qga25vdy4gRWxpb3QgYW5kIFNjb3R0IChjb3BpZWQpIG1heSBrbm93IG1vcmUuDQoNClJlZ2Fy
ZHMsDQoNCkRhbg0KDQoNCkZyb206IHZpZGVvLWNvZGVjIFttYWlsdG86dmlkZW8tY29kZWMtYm91
bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJpY2hhcmQgQmFybmVzDQpTZW50OiBUaHVyc2Rh
eSwgRmVicnVhcnkgMDUsIDIwMTUgMzoxNyBQTQ0KVG86IE1vIFphbmF0eSAobXphbmF0eSkNCkNj
OiB2aWRlby1jb2RlY0BpZXRmLm9yZzsgVGltb3RoeSBCLiBUZXJyaWJlcnJ5DQpTdWJqZWN0OiBS
ZTogW3ZpZGVvLWNvZGVjXSB2aWRlby1jb2RlYyBEaWdlc3QsIFZvbCAxOCwgSXNzdWUgMg0KDQpG
V0lXLCB0aGVyZSBpcyBhIHN0YW5kYXJkIHByYWN0aWNlIG9mIHByb3Bvc2VkIG5ldyB3b3JrIGlu
IHRoZSBJRVRGIGJlaW5nIHNlbnQgdG8gYSBncm91cCBvZiBTRE9zIG9uIG5ldy13b3JrQGlldGYu
b3JnPG1haWx0bzpuZXctd29ya0BpZXRmLm9yZz4gYXMgcGFydCBvZiB0aGUgY2hhcnRlciByZXZp
ZXcgcHJvY2Vzcy4gIEkgZG9uJ3QgcmVtZW1iZXIgaWYgSVRVL0lTTy9JRUMgYXJlIG9uIHRoYXQg
bGlzdCwgYnV0IEkgdGhpbmsgdGhlcmUgaXMgYXQgbGVhc3Qgc29tZSByZXByZXNlbnRhdGlvbi4N
Cg0KLS1SaWNoYXJkDQoNCg0KT24gVGh1LCBGZWIgNSwgMjAxNSBhdCA0OjI0IEFNLCBNbyBaYW5h
dHkgKG16YW5hdHkpIDxtemFuYXR5QGNpc2NvLmNvbTxtYWlsdG86bXphbmF0eUBjaXNjby5jb20+
PiB3cm90ZToNCkkgdGhpbmsgSVRVL0lTTy9JRUMgbGlhaXNvbnMgYXJlIGEgZ29vZCBpZGVhLCBl
dmVuIGlmIHlvdSBkb27CuXQgZXhwZWN0DQp1c2VmdWwgZmVlZGJhY2suIEp1c3QgYW5ub3VuY2lu
ZyBlZmZvcnRzIHRvIG1ha2Ugb3RoZXJzIGF3YXJlIGlzIGdlbmVyYWxseQ0KYSBnb29kIGlkZWEu
IFRoaXMgYWxzbyBhcHBsaWVzIHdpdGhpbiBJRVRGLCBlLmcuIGFubm91bmNlIG9uIHBheWxvYWQs
DQpjb2RlYywgcnRjd2ViLCBhbmQgcGVyaGFwcyBldmVuIGF2dGNvcmUsIGF2dGV4dCBhbmQgbW11
c2ljLg0KDQpNbw0KDQpPbiAyLzUvMTUsIDEyOjAzIEFNLCBUaW1vdGh5IEIuIFRlcnJpYmVycnkg
PHR0ZXJyaWJlQHhpcGgub3JnPG1haWx0bzp0dGVycmliZUB4aXBoLm9yZz4+IHdyb3RlOg0KRGF2
aWQgQmVuaGFtIHdyb3RlOg0KPiBJbnRlcmVzdGVkIGluIG90aGVycycgb3BpbmlvbiwgYnV0IHRo
ZSB0aGlua2luZyB3YXMgbW9yZSBGWUktdHlwZQ0KPiBsaWFpc29ucyB0byBJRUMvSVNPL0lUVS4g
ICBUaHVzIG5vdCB0b28gbXVjaCBvZiBhIHRpbWUgaW52ZXN0bWVudC4NClN1cmUuLi4gSSBkb24n
dCBoYXZlIGFuIG9iamVjdGlvbiB0byBkb2luZyBpdCwgSSBqdXN0IHdhbnRlZCB0byBtYWtlDQpz
dXJlIHdlIHdlcmUgYWNjdXJhdGVseSBjYXB0dXJpbmcgdGhlIHNlbnNlIG9mIHRoZSByb29tIGlu
IFRvcm9udG8uIElmDQpubyBvbmUgZWxzZSBzcGVha3MgdXAsIGxldCdzIGxlYXZlIGl0IGluLg0K
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdmlkZW8t
Y29kZWMgbWFpbGluZyBsaXN0DQp2aWRlby1jb2RlY0BpZXRmLm9yZzxtYWlsdG86dmlkZW8tY29k
ZWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3ZpZGVv
LWNvZGVjPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z
QV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fdmlkZW8tMkRjb2RlYyZkPUF3TUZhUSZj
PUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmcj1JNGR6R3hSMzFPY05YQ0pmUXp2bHNpTFFmdWNCWFJ1
Y1B2ZHJwaHBCc0ZBJm09ZF9nc0IyUUtwUS0weF9vQXJaRk5OSVBKMEE1cU9DYmMxa3hSRU8yS3NL
MCZzPWQ1TDBreHZYVzAtWmp4XzVvLWdXOUplRVBQS3NuUFVDLUJnVkcxdDVlNFkmZT0+DQoNCg==

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C98287CAZFFEXMB04globa_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10
eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K
QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w
cHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT
ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk
ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t
PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K
PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+
PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp
bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIEkgYW0g
bm90IG1pc3Rha2VuIElUVS1UIHJlcHJlc2VudGF0aXZlcyBmcm9tIElUVS1UIGFyZSBvbiB0aGlz
IGxpc3QuIElTTy9JRUQgYXJlIGRpZmZlcmVudCB0aGFuIElUVSwgYW5kIEkgZG8gbm90IGtub3cu
IEVsaW90IGFuZCBTY290dCAoY29waWVkKSBtYXkga25vdw0KIG1vcmUuIDxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVn
YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPkRhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw
YWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj
bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdmlkZW8tY29kZWMg
W21haWx0bzp2aWRlby1jb2RlYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwv
Yj5SaWNoYXJkIEJhcm5lczxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgMDUs
IDIwMTUgMzoxNyBQTTxicj4NCjxiPlRvOjwvYj4gTW8gWmFuYXR5IChtemFuYXR5KTxicj4NCjxi
PkNjOjwvYj4gdmlkZW8tY29kZWNAaWV0Zi5vcmc7IFRpbW90aHkgQi4gVGVycmliZXJyeTxicj4N
CjxiPlN1YmplY3Q6PC9iPiBSZTogW3ZpZGVvLWNvZGVjXSB2aWRlby1jb2RlYyBEaWdlc3QsIFZv
bCAxOCwgSXNzdWUgMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZXSVcsIHRoZXJlIGlzIGEgc3RhbmRhcmQgcHJhY3Rp
Y2Ugb2YgcHJvcG9zZWQgbmV3IHdvcmsgaW4gdGhlIElFVEYgYmVpbmcgc2VudCB0byBhIGdyb3Vw
IG9mIFNET3Mgb24NCjxhIGhyZWY9Im1haWx0bzpuZXctd29ya0BpZXRmLm9yZyI+bmV3LXdvcmtA
aWV0Zi5vcmc8L2E+IGFzIHBhcnQgb2YgdGhlIGNoYXJ0ZXIgcmV2aWV3IHByb2Nlc3MuJm5ic3A7
IEkgZG9uJ3QgcmVtZW1iZXIgaWYgSVRVL0lTTy9JRUMgYXJlIG9uIHRoYXQgbGlzdCwgYnV0IEkg
dGhpbmsgdGhlcmUgaXMgYXQgbGVhc3Qgc29tZSByZXByZXNlbnRhdGlvbi48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS1SaWNoYXJkPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1
LCBGZWIgNSwgMjAxNSBhdCA0OjI0IEFNLCBNbyBaYW5hdHkgKG16YW5hdHkpICZsdDs8YSBocmVm
PSJtYWlsdG86bXphbmF0eUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5temFuYXR5QGNpc2Nv
LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
SSB0aGluayBJVFUvSVNPL0lFQyBsaWFpc29ucyBhcmUgYSBnb29kIGlkZWEsIGV2ZW4gaWYgeW91
IGRvbsK5dCBleHBlY3Q8YnI+DQp1c2VmdWwgZmVlZGJhY2suIEp1c3QgYW5ub3VuY2luZyBlZmZv
cnRzIHRvIG1ha2Ugb3RoZXJzIGF3YXJlIGlzIGdlbmVyYWxseTxicj4NCmEgZ29vZCBpZGVhLiBU
aGlzIGFsc28gYXBwbGllcyB3aXRoaW4gSUVURiwgZS5nLiBhbm5vdW5jZSBvbiBwYXlsb2FkLDxi
cj4NCmNvZGVjLCBydGN3ZWIsIGFuZCBwZXJoYXBzIGV2ZW4gYXZ0Y29yZSwgYXZ0ZXh0IGFuZCBt
bXVzaWMuPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCk1vPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpP
biAyLzUvMTUsIDEyOjAzIEFNLCBUaW1vdGh5IEIuIFRlcnJpYmVycnkgJmx0OzxhIGhyZWY9Im1h
aWx0bzp0dGVycmliZUB4aXBoLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnR0ZXJyaWJlQHhpcGgub3Jn
PC9hPiZndDsgd3JvdGU6PGJyPg0KRGF2aWQgQmVuaGFtIHdyb3RlOjxicj4NCiZndDsgSW50ZXJl
c3RlZCBpbiBvdGhlcnMnIG9waW5pb24sIGJ1dCB0aGUgdGhpbmtpbmcgd2FzIG1vcmUgRllJLXR5
cGU8YnI+DQomZ3Q7IGxpYWlzb25zIHRvIElFQy9JU08vSVRVLiZuYnNwOyAmbmJzcDtUaHVzIG5v
dCB0b28gbXVjaCBvZiBhIHRpbWUgaW52ZXN0bWVudC48YnI+DQpTdXJlLi4uIEkgZG9uJ3QgaGF2
ZSBhbiBvYmplY3Rpb24gdG8gZG9pbmcgaXQsIEkganVzdCB3YW50ZWQgdG8gbWFrZTxicj4NCnN1
cmUgd2Ugd2VyZSBhY2N1cmF0ZWx5IGNhcHR1cmluZyB0aGUgc2Vuc2Ugb2YgdGhlIHJvb20gaW4g
VG9yb250by4gSWY8YnI+DQpubyBvbmUgZWxzZSBzcGVha3MgdXAsIGxldCdzIGxlYXZlIGl0IGlu
Ljxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fPGJyPg0KdmlkZW8tY29kZWMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnZp
ZGVvLWNvZGVjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dmlkZW8tY29kZWNAaWV0Zi5vcmc8
L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy
bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb192aWRlby0yRGNvZGVj
JmFtcDtkPUF3TUZhUSZhbXA7Yz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJmFtcDtyPUk0ZHpHeFIz
MU9jTlhDSmZRenZsc2lMUWZ1Y0JYUnVjUHZkcnBocEJzRkEmYW1wO209ZF9nc0IyUUtwUS0weF9v
QXJaRk5OSVBKMEE1cU9DYmMxa3hSRU8yS3NLMCZhbXA7cz1kNUwwa3h2WFcwLVpqeF81by1nVzlK
ZUVQUEtzblBVQy1CZ1ZHMXQ1ZTRZJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdmlkZW8tY29kZWM8L2E+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o
dG1sPg0K

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C98287CAZFFEXMB04globa_--


From nobody Thu Feb  5 06:33:53 2015
Return-Path: <lear@cisco.com>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525A61A89AF for <video-codec@ietfa.amsl.com>; Thu,  5 Feb 2015 06:29:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.521
X-Spam-Level: 
X-Spam-Status: No, score=-12.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 Ms-jseHts2rw for <video-codec@ietfa.amsl.com>; Thu,  5 Feb 2015 06:29:21 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D24071A88CE for <video-codec@ietf.org>; Thu,  5 Feb 2015 06:29:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12200; q=dns/txt; s=iport; t=1423146561; x=1424356161; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=98Kxm5fI97BQ2fIafAE/VEzEcuGx328QSfAv0cKhtxo=; b=YRjgol/RC7nbCmfK9NF6zFi+8Sw/EpAVmHNOEqF48BIXNGxN5fSeCkW1 3oNaZOKvXnyZfAbBHawu5qVzKubyhzfyZ3WtW79huAZZLGh4brAx88MOS 4H65/3y+iO0ahiE5rLuMkE2XNe2pfGxj6nqL3CmvMBTR9tc84/EnJq+hc 8=;
X-Files: signature.asc : 486
X-IronPort-AV: E=Sophos;i="5.09,524,1418083200";  d="asc'?scan'208,217";a="390574598"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-1.cisco.com with ESMTP; 05 Feb 2015 14:28:56 +0000
Received: from [10.86.248.216] (bxb-vpn3-216.cisco.com [10.86.248.216]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t15ESpTn015532; Thu, 5 Feb 2015 14:28:52 GMT
Message-ID: <54D37E22.2070205@cisco.com>
Date: Thu, 05 Feb 2015 15:28:50 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, Richard Barnes <rlb@ipv.sx>,  "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
References: <mailman.122.1423080069.8838.video-codec@ietf.org> <CAM5V9Z9Wtv7gasFAoxkYTmFBqV+jyu4CRVawAt_kdLZA=VtSjg@mail.gmail.com> <54D2F985.10700@xiph.org> <D0F89FDF.43C2A%mzanaty@cisco.com> <CAL02cgSf100fmL0D+6xV4HvE0MXPaoFyQpyyosXvQbRSCEKV_Q@mail.gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA5C98287C@AZ-FFEXMB04.global.avaya.com>
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C98287C@AZ-FFEXMB04.global.avaya.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aVi4x4HsToNS7fdSgk6Q274kVBBPbu0Mc"
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/a1RHwSEA-B2y7H7okoUHcYn4H50>
X-Mailman-Approved-At: Thu, 05 Feb 2015 06:33:49 -0800
Cc: Scott Mansfield <scott.mansfield@ericsson.com>, "video-codec@ietf.org" <video-codec@ietf.org>, "Timothy B. Terriberry" <tterribe@xiph.org>
Subject: Re: [video-codec] video-codec Digest, Vol 18, Issue 2
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 05 Feb 2015 14:29:28 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--aVi4x4HsToNS7fdSgk6Q274kVBBPbu0Mc
Content-Type: multipart/alternative;
 boundary="------------060707050603080904030808"

This is a multi-part message in MIME format.
--------------060707050603080904030808
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I believe we send copies to the ITU-T as a matter of course.  Whether
SG16 is seeing everything I cannot say.  Scott?

Eliot

On 2/5/15 2:22 PM, Romascanu, Dan (Dan) wrote:
>
> If I am not mistaken ITU-T representatives from ITU-T are on this
> list. ISO/IED are different than ITU, and I do not know. Eliot and
> Scott (copied) may know more.
>
> =20
>
> Regards,
>
> =20
>
> Dan
>
> =20
>
> =20
>
> *From:*video-codec [mailto:video-codec-bounces@ietf.org] *On Behalf Of
> *Richard Barnes
> *Sent:* Thursday, February 05, 2015 3:17 PM
> *To:* Mo Zanaty (mzanaty)
> *Cc:* video-codec@ietf.org; Timothy B. Terriberry
> *Subject:* Re: [video-codec] video-codec Digest, Vol 18, Issue 2
>
> =20
>
> FWIW, there is a standard practice of proposed new work in the IETF
> being sent to a group of SDOs on new-work@ietf.org
> <mailto:new-work@ietf.org> as part of the charter review process.  I
> don't remember if ITU/ISO/IEC are on that list, but I think there is
> at least some representation.
>
> =20
>
> --Richard
>
> =20
>
> =20
>
> On Thu, Feb 5, 2015 at 4:24 AM, Mo Zanaty (mzanaty) <mzanaty@cisco.com
> <mailto:mzanaty@cisco.com>> wrote:
>
> I think ITU/ISO/IEC liaisons are a good idea, even if you don=C2=B9t ex=
pect
> useful feedback. Just announcing efforts to make others aware is genera=
lly
> a good idea. This also applies within IETF, e.g. announce on payload,
> codec, rtcweb, and perhaps even avtcore, avtext and mmusic.
>
> Mo
>
>
> On 2/5/15, 12:03 AM, Timothy B. Terriberry <tterribe@xiph.org
> <mailto:tterribe@xiph.org>> wrote:
> David Benham wrote:
> > Interested in others' opinion, but the thinking was more FYI-type
> > liaisons to IEC/ISO/ITU.   Thus not too much of a time investment.
> Sure... I don't have an objection to doing it, I just wanted to make
> sure we were accurately capturing the sense of the room in Toronto. If
> no one else speaks up, let's leave it in.
>
> _______________________________________________
> video-codec mailing list
> video-codec@ietf.org <mailto:video-codec@ietf.org>
> https://www.ietf.org/mailman/listinfo/video-codec
> <https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma=
ilman_listinfo_video-2Dcodec&d=3DAwMFaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4=
dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3Dd_gsB2QKpQ-0x_oArZFNNIPJ0A5=
qOCbc1kxREO2KsK0&s=3Dd5L0kxvXW0-Zjx_5o-gW9JeEPPKsnPUC-BgVG1t5e4Y&e=3D>
>
> =20
>


--------------060707050603080904030808
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty=
pe">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    I believe we send copies to the ITU-T as a matter of course.=C2=A0
    Whether SG16 is seeing everything I cannot say.=C2=A0 Scott?<br>
    <br>
    Eliot<br>
    <br>
    <div class=3D"moz-cite-prefix">On 2/5/15 2:22 PM, Romascanu, Dan (Dan=
)
      wrote:<br>
    </div>
    <blockquote
cite=3D"mid:9904FB1B0159DA42B0B887B7FA8119CA5C98287C@AZ-FFEXMB04.global.a=
vaya.com"
      type=3D"cite">
      <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Du=
tf-8">
      <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
=2EMsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
      <div class=3D"WordSection1">
        <p class=3D"MsoNormal"><span
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-seri=
f&quot;;color:#1F497D">If
            I am not mistaken ITU-T representatives from ITU-T are on
            this list. ISO/IED are different than ITU, and I do not
            know. Eliot and Scott (copied) may know more. <o:p></o:p></sp=
an></p>
        <p class=3D"MsoNormal"><span
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-seri=
f&quot;;color:#1F497D"><o:p>=C2=A0</o:p></span></p>
        <p class=3D"MsoNormal"><span
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-seri=
f&quot;;color:#1F497D">Regards,<o:p></o:p></span></p>
        <p class=3D"MsoNormal"><span
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-seri=
f&quot;;color:#1F497D"><o:p>=C2=A0</o:p></span></p>
        <p class=3D"MsoNormal"><span
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-seri=
f&quot;;color:#1F497D">Dan<o:p></o:p></span></p>
        <p class=3D"MsoNormal"><span
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-seri=
f&quot;;color:#1F497D"><o:p>=C2=A0</o:p></span></p>
        <p class=3D"MsoNormal"><span
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-seri=
f&quot;;color:#1F497D"><o:p>=C2=A0</o:p></span></p>
        <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0c=
m
          0cm 0cm 4.0pt">
          <div>
            <div style=3D"border:none;border-top:solid #B5C4DF
              1.0pt;padding:3.0pt 0cm 0cm 0cm">
              <p class=3D"MsoNormal"><b><span
style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif=
&quot;">From:</span></b><span
style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif=
&quot;">
                  video-codec [<a class=3D"moz-txt-link-freetext" href=3D=
"mailto:video-codec-bounces@ietf.org">mailto:video-codec-bounces@ietf.org=
</a>]
                  <b>On Behalf Of </b>Richard Barnes<br>
                  <b>Sent:</b> Thursday, February 05, 2015 3:17 PM<br>
                  <b>To:</b> Mo Zanaty (mzanaty)<br>
                  <b>Cc:</b> <a class=3D"moz-txt-link-abbreviated" href=3D=
"mailto:video-codec@ietf.org">video-codec@ietf.org</a>; Timothy B. Terrib=
erry<br>
                  <b>Subject:</b> Re: [video-codec] video-codec Digest,
                  Vol 18, Issue 2<o:p></o:p></span></p>
            </div>
          </div>
          <p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
          <div>
            <div>
              <div>
                <p class=3D"MsoNormal">FWIW, there is a standard practice=

                  of proposed new work in the IETF being sent to a group
                  of SDOs on
                  <a moz-do-not-send=3D"true"
                    href=3D"mailto:new-work@ietf.org">new-work@ietf.org</=
a>
                  as part of the charter review process.=C2=A0 I don't
                  remember if ITU/ISO/IEC are on that list, but I think
                  there is at least some representation.<o:p></o:p></p>
              </div>
              <div>
                <p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
              </div>
              <div>
                <p class=3D"MsoNormal">--Richard<o:p></o:p></p>
              </div>
              <div>
                <p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
              </div>
              <div>
                <p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
              </div>
              <div>
                <p class=3D"MsoNormal">On Thu, Feb 5, 2015 at 4:24 AM, Mo=

                  Zanaty (mzanaty) &lt;<a moz-do-not-send=3D"true"
                    href=3D"mailto:mzanaty@cisco.com" target=3D"_blank">m=
zanaty@cisco.com</a>&gt;
                  wrote:<o:p></o:p></p>
                <p class=3D"MsoNormal">I think ITU/ISO/IEC liaisons are a=

                  good idea, even if you don=C2=B9t expect<br>
                  useful feedback. Just announcing efforts to make
                  others aware is generally<br>
                  a good idea. This also applies within IETF, e.g.
                  announce on payload,<br>
                  codec, rtcweb, and perhaps even avtcore, avtext and
                  mmusic.<br>
                  <span style=3D"color:#888888"><br>
                    Mo</span><o:p></o:p></p>
                <div>
                  <div>
                    <p class=3D"MsoNormal"><br>
                      On 2/5/15, 12:03 AM, Timothy B. Terriberry &lt;<a
                        moz-do-not-send=3D"true"
                        href=3D"mailto:tterribe@xiph.org" target=3D"_blan=
k">tterribe@xiph.org</a>&gt;
                      wrote:<br>
                      David Benham wrote:<br>
                      &gt; Interested in others' opinion, but the
                      thinking was more FYI-type<br>
                      &gt; liaisons to IEC/ISO/ITU.=C2=A0 =C2=A0Thus not =
too much
                      of a time investment.<br>
                      Sure... I don't have an objection to doing it, I
                      just wanted to make<br>
                      sure we were accurately capturing the sense of the
                      room in Toronto. If<br>
                      no one else speaks up, let's leave it in.<br>
                      <br>
                      _______________________________________________<br>=

                      video-codec mailing list<br>
                      <a moz-do-not-send=3D"true"
                        href=3D"mailto:video-codec@ietf.org"
                        target=3D"_blank">video-codec@ietf.org</a><br>
                      <a moz-do-not-send=3D"true"
href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.o=
rg_mailman_listinfo_video-2Dcodec&amp;d=3DAwMFaQ&amp;c=3DBFpWQw8bsuKpl1Sg=
iZH64Q&amp;r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&amp;m=3Dd_gsB2=
QKpQ-0x_oArZFNNIPJ0A5qOCbc1kxREO2KsK0&amp;s=3Dd5L0kxvXW0-Zjx_5o-gW9JeEPPK=
snPUC-BgVG1t5e4Y&amp;e=3D"
                        target=3D"_blank">https://www.ietf.org/mailman/li=
stinfo/video-codec</a><o:p></o:p></p>
                  </div>
                </div>
              </div>
              <p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------060707050603080904030808--

--aVi4x4HsToNS7fdSgk6Q274kVBBPbu0Mc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQEcBAEBAgAGBQJU034iAAoJEIe2a0bZ0nozrnoH/2nN98pn1Gj9bR/68n1l7jUt
9nJrswuwVn82IOynzrilP6syrlr23XLIggesSFgeBKM/4Z4+JubDi2DitpOrLjtc
3PE3AmaI59mGcD3/zo4UN4X0XnCPnh/RYrO3TcnMvqIMnA0J0OKOxNQnb+5voZnj
oNUMCEv4dBrCZoJ2W0i9/yis6NWOc3su3ahCN0V69X2wvoa74nnZp1nrhjdqRjnq
NnsP2aY97fiQZQS/i1KFR77s6Ru0K+gmwuCvyRuAx3Jdt2yKt1s2CFI4oHO7KfP9
lrMhnOrRwVsLXMSXXMvJ/s1Awx1815aRKKYuuPe3vp3FqjcLWhgVUEC5FcgMmh4=
=SaYB
-----END PGP SIGNATURE-----

--aVi4x4HsToNS7fdSgk6Q274kVBBPbu0Mc--


From nobody Thu Feb 12 08:48:37 2015
Return-Path: <adam@nostrum.com>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D521A0141 for <video-codec@ietfa.amsl.com>; Thu, 12 Feb 2015 08:48:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Hw6hhNTevVe5 for <video-codec@ietfa.amsl.com>; Thu, 12 Feb 2015 08:48:33 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4439D1A0178 for <video-codec@ietf.org>; Thu, 12 Feb 2015 08:48:30 -0800 (PST)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t1CGmTR5012799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <video-codec@ietf.org>; Thu, 12 Feb 2015 10:48:29 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
Message-ID: <54DCD95D.5030900@nostrum.com>
Date: Thu, 12 Feb 2015 10:48:29 -0600
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: video-codec@ietf.org
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/3IC6n0smjJc-gLBVA1-ttNG0HKQ>
Subject: [video-codec] NETVC BoF Approved for IETF92
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 12 Feb 2015 16:48:35 -0000

I just got word from the IESG that the NETVC BoF has been approved for 
the Dallas meeting. Jon Peterson and I will be chairing the BoF.

A proposed agenda is available at 
http://trac.tools.ietf.org/bof/trac/wiki#NETVC

The proposed charter is at 
https://daala.etherpad.mozilla.org/video-codec-charter

/a


From nobody Wed Feb 25 00:17:19 2015
Return-Path: <harald@alvestrand.no>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AB41A1EF1 for <video-codec@ietfa.amsl.com>; Wed, 25 Feb 2015 00:17:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.318
X-Spam-Level: 
X-Spam-Status: No, score=0.318 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01, URI_TRY_3LD=0.228] 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 QJHlxjaLgkTG for <video-codec@ietfa.amsl.com>; Wed, 25 Feb 2015 00:17:15 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8841A1C06 for <video-codec@ietf.org>; Wed, 25 Feb 2015 00:17:15 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 5A2277C3DCE for <video-codec@ietf.org>; Wed, 25 Feb 2015 09:17:13 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_lz_m_YdcWw for <video-codec@ietf.org>; Wed, 25 Feb 2015 09:17:11 +0100 (CET)
Received: from [IPv6:2001:470:de0a:27:51f6:d297:73ab:810] (unknown [IPv6:2001:470:de0a:27:51f6:d297:73ab:810]) by mork.alvestrand.no (Postfix) with ESMTPSA id 1D8E37C3D0C for <video-codec@ietf.org>; Wed, 25 Feb 2015 09:17:11 +0100 (CET)
Message-ID: <54ED8506.30908@alvestrand.no>
Date: Wed, 25 Feb 2015 09:17:10 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: video-codec@ietf.org
References: <CACrD=+_uNyiFuKtoxNYGMOcB2jSvKdh_6mBLvpFeTeEmHDQ9PQ@mail.gmail.com> <CABcZeBOenDx=10XWP_85iSsgGVi0uaTazwfOtN7EsuXS0oUG_A@mail.gmail.com> <CABcZeBPpDNK9+uVmhYo4-LDjkeuNkX86eOsfCzfrO04aeYrYYw@mail.gmail.com> <CACrD=+8wrCc31s1smT5WRkg8t3QO+RnNVSzhwJcvAZzZ6WDFNw@mail.gmail.com> <D0ECB849.42FC4%mzanaty@cisco.com>
In-Reply-To: <D0ECB849.42FC4%mzanaty@cisco.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/TVfIlRsg2W5PU7DAtk-obv0h3EM>
Subject: Re: [video-codec] Test sequences, automated and otherwise
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 25 Feb 2015 08:17:18 -0000

Coming in very late on thread....

sequences need to be grouped in multiple dimensions. I'd suggest that
one dimension be:

- Talking heads (still camera, little movement)
- Cinematic material (slow camera moves, dramatic cuts, sudden moves)
- Amateur video (camera shake, sudden moves)
- Artificially generated (no camera shake, color gradients smoother than
normal, no inter-frame movement blur)

Another dimension should be available bandwidth

- 0.1 Mbits, 1 Mbits, 10 Mbits, 100 Mbits

I've come to the conclusion that varying resolution should be considered
one tool for achieving lossy compression, and should not be a primary
dimension - YMMV.
(that said, existing source material has resolutions, and a codec should
make sure to handle all resolutions well.)

A third dimension should be available computing resources for encode and
decode:

- Infinite encode resources available (test style)
- Encode 10x slower than real time (production environments)
- Encode faster than real time (interactive + overhead)

- Decode in real time, stalls acceptable
- Decode in real time, stalls not acceptable

A fourth dimension is about the use of lookahead:

- Any lookahead, including multipass, is acceptable
- Lookahead of a second or two is acceptable
- Lookahead of 100 ms is acceptable
- No lookahead at all is permissible (minimum delay)

I'm running some codec comparisons on compare-codecs.appspot.com (open
source project) - incorporating Derf's clip set is high on my TODO list.

Den 27. jan. 2015 10:17, skrev Mo Zanaty (mzanaty):
> Since a particularly interesting comparison will be HEVC, should we
> consider some JCT-VC standard sequences and operating points?
> 
> We can redefine the classes of sequences to be the most relevant for
> initial experiments. For example:
> 
> Class 1: Video Conferencing
>   a) 360p 30Hz 0.1-1Mbps
>   b) 720p 30Hz 0.2-2Mbps
>   c) 720p 60Hz 0.3-3Mbps
>   d) 1080p 30Hz 0.4-4Mbps
>   e) 1080p 60Hz 0.6-6Mbps
>   f) 2160p 30Hz 1.2-12Mbps
> 
> Class 2: Video Streaming
>   a) 360p 30Hz 0.2-2Mbps
>   b) 720p 30Hz 0.3-3Mbps
>   c) 1080p 24Hz 0.6-6Mbps
>   d) 2160p 24Hz 2-20Mbps
> 
> 1b and 2c may be the most interesting operating points for many.
> 
> We can also consider other classes like professional applications, screen
> content / wireless display, etc. with relatively higher rates.
> 
> 
> Mo
> 
> 
> On 1/26/15, 8:09 PM, Monty Montgomery <xiphmont@gmail.com> wrote:
> 
> Right, and our use of AWCY and test clips being mostly regression
> testing at the moment (and specific to our particular glass box), I
> wasn't proposing the particulars what we're doing right now as the
> starting point.  Rather, it could be, but used a different way, not as
> we're using it.
> 
> Monty
> 
> On Sun, Jan 25, 2015 at 1:14 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>> Following up to myself: what i'm hoping here is to get a consensus list
>> of
>> the domains of interest so that we can then evaluate our progress against
>> them.
>>
>> -Ekr
>>
>>
>> On Sun, Jan 25, 2015 at 12:57 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>>
>>>
>>> On Fri, Jan 23, 2015 at 1:45 PM, Monty Montgomery <xiphmont@gmail.com>
>>> wrote:
>>>>
>>>> Hi everyone,
>>>>
>>>> Testing discussions are already happening in private and elsewhere.
>>>> The basic points are usually pretty similar and I expect they're going
>>>> to keep coming up, so I'm going to try centralizing it here.
>>>>
>>>> The Daala team is using a small number of fairly short test sequences
>>>> in an automated testing system ('Are We compressed Yet?) mostly as a
>>>> way of doing regression testing.  It's also used to sanity check small
>>>> improvements that are unlikely to be apparent in visual testing.  The
>>>> various graphs we've shown in demos and the like are coming from AWCY.
>>>>
>>>> One point that's been raised several times is that we're not testing
>>>> reasonable or practical bitrates.  Or, rather, that our range includes
>>>> the typical useful rates, but we also go way up to insanely high rates
>>>> no one would ever use.  That's mainly because AWCY is meant as a
>>>> sanity/regression check, and many subtle bugs we've had in the past
>>>> have only popped out at near-lossless quality levels.  Automated
>>>> testing should report these rates, but we don't intend to use them in
>>>> evaluation of relative practical performance.
>>>
>>>
>>> To sharpen this point a little bit, it's probably useful to distinguish
>>> between testing for performance evaluation and testing for regression,
>>> continuous integration etc.
>>>
>>> For the purpose of continuous integration, we should, as you
>>> suggest, test all sorts of parameter sets, including insane ones,
>>> as well as how the decoder handles bogus encodings, etc. For
>>> the purpose of performance evaluation/comparison, I would suggest
>>> that it would be useful to try to define a set of strawman scenarios
>>> which we would use. I'm sure others have different opinions, but
>>> for me the scenarios of most interest are basically videoconferencing,
>>> so roughly speaking:
>>>
>>> - Some set of sizes like:
>>>   - QCIF
>>>   - VGA
>>>   - 1080p
>>>
>>> - 30fps.
>>> - Bit rates on the order of 200kps - 5ish Mbps, depending on the size
>>> (I could be a bit off here).
>>>
>>>
>>> Presumably we want some streaming use cases, but I have a less good
>>> handle on what typical streaming is...
>>>
>>> -Ekr
>>>
>>>
>>>
>>>
>>>
>>>
>>>> Another point that keeps coming up is that we should come up with a
>>>> standard set of sequences and rates for trading and evaluating first-
>>>> and probably second-line evaluations.  Full agreement there, though
>>>> our own frontline tetsing right now is only using a handful of clips
>>>> of a few seconds each (though our available library is much larger).
>>>>
>>>> Monty
>>>>
>>>> _______________________________________________
>>>> video-codec mailing list
>>>> video-codec@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/video-codec
>>>
>>>
>>
> 
> _______________________________________________
> video-codec mailing list
> video-codec@ietf.org
> https://www.ietf.org/mailman/listinfo/video-codec
> 
> _______________________________________________
> video-codec mailing list
> video-codec@ietf.org
> https://www.ietf.org/mailman/listinfo/video-codec
> 


From nobody Wed Feb 25 06:36:25 2015
Return-Path: <tterribe@xiph.org>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121841A1BD1 for <video-codec@ietfa.amsl.com>; Wed, 25 Feb 2015 06:36:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.277
X-Spam-Level: 
X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_FAIL=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 3Sw9gbBXo4pD for <video-codec@ietfa.amsl.com>; Wed, 25 Feb 2015 06:36:22 -0800 (PST)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C11B81A1BCA for <video-codec@ietf.org>; Wed, 25 Feb 2015 06:36:22 -0800 (PST)
Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTP id 21D9DF2372 for <video-codec@ietf.org>; Wed, 25 Feb 2015 06:36:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at mozilla.org
Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.corp.phx1.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCQdfU67VG-b for <video-codec@ietf.org>; Wed, 25 Feb 2015 06:36:21 -0800 (PST)
Received: from [172.17.0.79] (50-78-100-113-static.hfc.comcastbusiness.net [50.78.100.113]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id A6840F2301 for <video-codec@ietf.org>; Wed, 25 Feb 2015 06:36:21 -0800 (PST)
Message-ID: <54EDDDE4.1050303@xiph.org>
Date: Wed, 25 Feb 2015 06:36:20 -0800
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
MIME-Version: 1.0
To: video-codec@ietf.org
References: <CACrD=+_uNyiFuKtoxNYGMOcB2jSvKdh_6mBLvpFeTeEmHDQ9PQ@mail.gmail.com> <CABcZeBOenDx=10XWP_85iSsgGVi0uaTazwfOtN7EsuXS0oUG_A@mail.gmail.com> <CABcZeBPpDNK9+uVmhYo4-LDjkeuNkX86eOsfCzfrO04aeYrYYw@mail.gmail.com> <CACrD=+8wrCc31s1smT5WRkg8t3QO+RnNVSzhwJcvAZzZ6WDFNw@mail.gmail.com> <D0ECB849.42FC4%mzanaty@cisco.com> <54ED8506.30908@alvestrand.no>
In-Reply-To: <54ED8506.30908@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/NjLzUHEAlaDMTuU3QRd2Mnpkx18>
Subject: Re: [video-codec] Test sequences, automated and otherwise
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 25 Feb 2015 14:36:24 -0000

Harald Alvestrand wrote:
> I've come to the conclusion that varying resolution should be considered
> one tool for achieving lossy compression, and should not be a primary
> dimension - YMMV.

Can you say a little bit more about how you would go about comparing the 
results of two encoders that chose to encode a sequence (or even 
individual frames within a given sequence) at different resolutions?


From nobody Wed Feb 25 07:17:30 2015
Return-Path: <harald@alvestrand.no>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734301A8778 for <video-codec@ietfa.amsl.com>; Wed, 25 Feb 2015 07:17:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 q4aINAzQksZw for <video-codec@ietfa.amsl.com>; Wed, 25 Feb 2015 07:17:27 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id D4A9E1A1BE4 for <video-codec@ietf.org>; Wed, 25 Feb 2015 07:17:26 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id D13D97C448E for <video-codec@ietf.org>; Wed, 25 Feb 2015 16:17:25 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFuwP0XEJ9MC for <video-codec@ietf.org>; Wed, 25 Feb 2015 16:17:24 +0100 (CET)
Received: from [IPv6:2001:470:de0a:27:2475:90a6:402e:96d2] (unknown [IPv6:2001:470:de0a:27:2475:90a6:402e:96d2]) by mork.alvestrand.no (Postfix) with ESMTPSA id A2A097C4483 for <video-codec@ietf.org>; Wed, 25 Feb 2015 16:17:24 +0100 (CET)
Message-ID: <54EDE784.2000107@alvestrand.no>
Date: Wed, 25 Feb 2015 16:17:24 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: video-codec@ietf.org
References: <CACrD=+_uNyiFuKtoxNYGMOcB2jSvKdh_6mBLvpFeTeEmHDQ9PQ@mail.gmail.com> <CABcZeBOenDx=10XWP_85iSsgGVi0uaTazwfOtN7EsuXS0oUG_A@mail.gmail.com> <CABcZeBPpDNK9+uVmhYo4-LDjkeuNkX86eOsfCzfrO04aeYrYYw@mail.gmail.com> <CACrD=+8wrCc31s1smT5WRkg8t3QO+RnNVSzhwJcvAZzZ6WDFNw@mail.gmail.com> <D0ECB849.42FC4%mzanaty@cisco.com> <54ED8506.30908@alvestrand.no> <54EDDDE4.1050303@xiph.org>
In-Reply-To: <54EDDDE4.1050303@xiph.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/oCYQSEp3EJB9PKCpsN_CJIIdtpo>
Subject: Re: [video-codec] Test sequences, automated and otherwise
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 25 Feb 2015 15:17:29 -0000

Den 25. feb. 2015 15:36, skrev Timothy B. Terriberry:
> Harald Alvestrand wrote:
>> I've come to the conclusion that varying resolution should be considered
>> one tool for achieving lossy compression, and should not be a primary
>> dimension - YMMV.
> 
> Can you say a little bit more about how you would go about comparing the
> results of two encoders that chose to encode a sequence (or even
> individual frames within a given sequence) at different resolutions?

I think comparision tools that care about what the codecs do rather than
what the result is are problematic - so I'm not sure whether this is
different from all the other choices encoders can make.

The overall process would have to return an image suitable for display -
for simplicity of testing, I would make the output resolution the same
as the input resolution.

We've experimented with this sort of resolution change in the WebRTC
pipeline - encoding in a lower resolution saves both CPU and bandwidth.

(Just for fun, I integrated such a rescaling into the compare-codecs
pipeline that encodes using the H.261 encoder, to allow comparing H.261
with its very limited available resolutions to other codecs on HD-sized
clips - it "works", for some value of "work".

psnr values of 35 dB where x264 achieves 40 dB - it seems psnr isn't
particularly sensitive to the resulting blurriness).


> 
> _______________________________________________
> video-codec mailing list
> video-codec@ietf.org
> https://www.ietf.org/mailman/listinfo/video-codec


From nobody Wed Feb 25 09:40:06 2015
Return-Path: <tdaede@mozilla.com>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1197F1A1B48 for <video-codec@ietfa.amsl.com>; Wed, 25 Feb 2015 09:40:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 3ubookmyMDCb for <video-codec@ietfa.amsl.com>; Wed, 25 Feb 2015 09:40:01 -0800 (PST)
Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54B2C1A1B27 for <video-codec@ietf.org>; Wed, 25 Feb 2015 09:39:59 -0800 (PST)
Received: by paceu11 with SMTP id eu11so6805155pac.7 for <video-codec@ietf.org>; Wed, 25 Feb 2015 09:39:57 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XUeeXlre7WetQLB7dpcU36hrWYTj6aTwCQVJ5AlMPDY=; b=PPeXfUFyGh/JgWZ9xjwGALXNgiF7Y1KObeoljjlAivSLsGlBJiiYEhIvqkjlRe0ooe TGpkTH3PKqiogLui5MgAgMbGgisCKY27g/B48a33J9GhGqYf7DZmusvC0083x4edfNTj lpXt144cCED587pBBisddwtA7+ZLDB81q6VcN5U3/t1sQ8iwcaGfyGh3vB+eOO5WAvu5 bVFW5lKkemYUOyRVqFhK+VDOeBo5OYPlp2OI9JeaR8vUXGSDQ6/ReNscICH1rPeBtfeH LmoI2XPajp0gfNvVd0XEP2ZHQWVPnCCjKUzs0R6HtsgtuxvOvWuaBeem5V8m7qJNpIiM 2Ouw==
X-Gm-Message-State: ALoCoQk6nfEN+hum/REiluFCYD+oHBSoANHHd6jH1NiX4QITDFOF/qcVqND6zMbUSA5tI28D4tX9
X-Received: by 10.68.234.164 with SMTP id uf4mr7213808pbc.37.1424885997778; Wed, 25 Feb 2015 09:39:57 -0800 (PST)
Received: from ?IPv6:2601:9:3400:900:7e7a:91ff:fe9e:8126? ([2601:9:3400:900:7e7a:91ff:fe9e:8126]) by mx.google.com with ESMTPSA id dx6sm43048783pab.14.2015.02.25.09.39.56 for <video-codec@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Feb 2015 09:39:57 -0800 (PST)
Message-ID: <54EE08EC.6090903@mozilla.com>
Date: Wed, 25 Feb 2015 09:39:56 -0800
From: Thomas Daede <tdaede@mozilla.com>
User-Agent: http://a.pomf.se/cszdno.opus
MIME-Version: 1.0
To: video-codec@ietf.org
References: <CACrD=+_uNyiFuKtoxNYGMOcB2jSvKdh_6mBLvpFeTeEmHDQ9PQ@mail.gmail.com> <CABcZeBOenDx=10XWP_85iSsgGVi0uaTazwfOtN7EsuXS0oUG_A@mail.gmail.com> <CABcZeBPpDNK9+uVmhYo4-LDjkeuNkX86eOsfCzfrO04aeYrYYw@mail.gmail.com> <CACrD=+8wrCc31s1smT5WRkg8t3QO+RnNVSzhwJcvAZzZ6WDFNw@mail.gmail.com> <D0ECB849.42FC4%mzanaty@cisco.com> <54ED8506.30908@alvestrand.no>
In-Reply-To: <54ED8506.30908@alvestrand.no>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/L62s9dC02qAzY4GKGhtX87eQD_w>
Subject: Re: [video-codec] Test sequences, automated and otherwise
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 25 Feb 2015 17:40:04 -0000

On 02/25/2015 12:17 AM, Harald Alvestrand wrote:
> Coming in very late on thread....
> 
> sequences need to be grouped in multiple dimensions. I'd suggest that
> one dimension be:
> 
> - Talking heads (still camera, little movement)
> - Cinematic material (slow camera moves, dramatic cuts, sudden moves)
> - Amateur video (camera shake, sudden moves)
> - Artificially generated (no camera shake, color gradients smoother than
> normal, no inter-frame movement blur)

Rather than "Artificially Generated", I would suggest the following
categories:
 - Screensharing - 10fps
 - Video game streaming - 60fps, 1080p

I think it's okay for sequences like the Blender open movie projects to
be in cinematic material. I'm also not totally sure it makes sense to
separate cinematic and amateur video. I think it is unlikely that any
video hosting site is going to try to treat the two differently.

The problem with all of these dimensions is that we now have 5*4*3*2*4 =
480 different combinations to try. I think we should probably limit
ourselves to sensible combinations here.


From nobody Wed Feb 25 09:44:46 2015
Return-Path: <tdaede@mozilla.com>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1DC1A1B72 for <video-codec@ietfa.amsl.com>; Wed, 25 Feb 2015 09:44:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 j-CNVJQyk-VX for <video-codec@ietfa.amsl.com>; Wed, 25 Feb 2015 09:44:41 -0800 (PST)
Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE9D01A0040 for <video-codec@ietf.org>; Wed, 25 Feb 2015 09:44:41 -0800 (PST)
Received: by pabkx10 with SMTP id kx10so6759938pab.13 for <video-codec@ietf.org>; Wed, 25 Feb 2015 09:44:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FQW+XV9Ww6qF0CuAEQ8Ueb2lpzUyD1wb+3aJqUhI3qc=; b=PxC7IC50iqKCuG5qEW176YG0ZvB/FYE//coPrXPxLPTUrBRIcIh/Rg0tG6FrcfzxTP nvUsHgMPQ6iPKRt1iF4eJ9xH+QuOaLXX+hbPQttNLK2dpSW+SOgXSAYQnuKHDskmmHSY B3footU31CMr3xa0yimDg12Q2m8q9D1hxzbL1bDiqI9jFmJA6jnutjYC5YP8GC3P68rO QBWT6GsXC2YvkHA1SORzGxJ+TZ7AbkRkozNeusSrCX1MnP0q94NSpbWtScClIg0dqho6 CLM3dz/7CLKq2XmzG591LOqZkG3lAKeXQ+cZZfibpQfpFcou/EYZGyUuAKmMjzrQ14WC 8frQ==
X-Gm-Message-State: ALoCoQn59Lq+cZkNzZSV95Xa2ZjF1JFtL8Kk/JYvPs/tC2CfpkbByoWLM/eBSiCJYXPmP4C13jT7
X-Received: by 10.70.40.209 with SMTP id z17mr7507846pdk.9.1424886281243; Wed, 25 Feb 2015 09:44:41 -0800 (PST)
Received: from ?IPv6:2601:9:3400:900:7e7a:91ff:fe9e:8126? ([2601:9:3400:900:7e7a:91ff:fe9e:8126]) by mx.google.com with ESMTPSA id xh3sm4277383pab.25.2015.02.25.09.44.40 for <video-codec@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Feb 2015 09:44:40 -0800 (PST)
Message-ID: <54EE0A07.3080100@mozilla.com>
Date: Wed, 25 Feb 2015 09:44:39 -0800
From: Thomas Daede <tdaede@mozilla.com>
User-Agent: http://a.pomf.se/cszdno.opus
MIME-Version: 1.0
To: video-codec@ietf.org
References: <CACrD=+_uNyiFuKtoxNYGMOcB2jSvKdh_6mBLvpFeTeEmHDQ9PQ@mail.gmail.com> <CABcZeBOenDx=10XWP_85iSsgGVi0uaTazwfOtN7EsuXS0oUG_A@mail.gmail.com> <CABcZeBPpDNK9+uVmhYo4-LDjkeuNkX86eOsfCzfrO04aeYrYYw@mail.gmail.com> <CACrD=+8wrCc31s1smT5WRkg8t3QO+RnNVSzhwJcvAZzZ6WDFNw@mail.gmail.com> <D0ECB849.42FC4%mzanaty@cisco.com>
In-Reply-To: <D0ECB849.42FC4%mzanaty@cisco.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/8ZyenBA-TDTlECgXzpROnhDimcA>
Subject: Re: [video-codec] Test sequences, automated and otherwise
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 25 Feb 2015 17:44:45 -0000

On 01/27/2015 01:17 AM, Mo Zanaty (mzanaty) wrote:
> Since a particularly interesting comparison will be HEVC, should we
> consider some JCT-VC standard sequences and operating points?

After looking at the JCT-VC standard sequences, I don't feel that they
are sufficient for our testing. However, I do think that they are a good
way to compare to the published results of other standards, so we should
include them as a category.

The JCT-VC test set only includes three clips for video conferencing,
which I don't think is sufficient. It also specifies a intra frame
period of 1 second, which is not reasonable.

It does not feature any 2160p test sequences either, which is a bit strange.


From nobody Wed Feb 25 10:19:26 2015
Return-Path: <ycho@mozilla.com>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C75F1A079A for <video-codec@ietfa.amsl.com>; Wed, 25 Feb 2015 10:19:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 tkfNxNcxcbiO for <video-codec@ietfa.amsl.com>; Wed, 25 Feb 2015 10:19:12 -0800 (PST)
Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3327D1A037D for <video-codec@ietf.org>; Wed, 25 Feb 2015 10:18:52 -0800 (PST)
Received: by mail-ob0-f174.google.com with SMTP id wo20so5621992obc.5 for <video-codec@ietf.org>; Wed, 25 Feb 2015 10:18:51 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xU57UbpRAbMTlaM0qWEXUrvdTi99FjmWuHu9kUPkQF8=; b=lSlq3aq2FqDk1GkIu47nThPX7tq986vOoSB4F2EfdqYPmepictgHFP757EOwAttjWY TaoNWKJevQx1OoFWF8iDEvbFMfeiijoP0V/DzGE0XD3DRNUSbutHtDnVHCddv+jjlO67 +6bEzFNUwtoqLFU/NC4IhCC4qKYJ5uJHQZZ7LHrKB0i+rmwallH61QpMBrKoGkP8hew/ QJFYD6UyiKJJp4mxgxcCrHnAff+CN9FeTJA0aHTxQjsmaUl4UQJSDVkeurSZQExDQapQ tGt7003fHIphCrhpGaR+KHEkfsEF7tphXPBSulZRWIzf5O+jQg2BfsviNsEgLo5cwAB3 okTg==
X-Gm-Message-State: ALoCoQnUcAfB6xG7EOShhCcW7cCwHDDBusch69w2fHsGeTY+XuAgHv1JitFOcsjudXcdHPrBTDRq
MIME-Version: 1.0
X-Received: by 10.60.34.133 with SMTP id z5mr3155112oei.63.1424888331384; Wed, 25 Feb 2015 10:18:51 -0800 (PST)
Received: by 10.60.169.167 with HTTP; Wed, 25 Feb 2015 10:18:51 -0800 (PST)
In-Reply-To: <54EE08EC.6090903@mozilla.com>
References: <CACrD=+_uNyiFuKtoxNYGMOcB2jSvKdh_6mBLvpFeTeEmHDQ9PQ@mail.gmail.com> <CABcZeBOenDx=10XWP_85iSsgGVi0uaTazwfOtN7EsuXS0oUG_A@mail.gmail.com> <CABcZeBPpDNK9+uVmhYo4-LDjkeuNkX86eOsfCzfrO04aeYrYYw@mail.gmail.com> <CACrD=+8wrCc31s1smT5WRkg8t3QO+RnNVSzhwJcvAZzZ6WDFNw@mail.gmail.com> <D0ECB849.42FC4%mzanaty@cisco.com> <54ED8506.30908@alvestrand.no> <54EE08EC.6090903@mozilla.com>
Date: Wed, 25 Feb 2015 10:18:51 -0800
Message-ID: <CABSTHf3q3FiENDRrxQ2Dd=Payab0tuaova=KtebmFiS_rZ+1Zw@mail.gmail.com>
From: Yushin Cho <ycho@mozilla.com>
To: Thomas Daede <tdaede@mozilla.com>
Content-Type: multipart/alternative; boundary=089e012952f4d64fc6050fedaaca
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/S6xYm7PhmOBK8xaYE94ZOGoPKTc>
Cc: video-codec@ietf.org
Subject: Re: [video-codec] Test sequences, automated and otherwise
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 25 Feb 2015 18:19:16 -0000

--089e012952f4d64fc6050fedaaca
Content-Type: text/plain; charset=UTF-8

On Wed, Feb 25, 2015 at 9:39 AM, Thomas Daede <tdaede@mozilla.com> wrote:

>
> The problem with all of these dimensions is that we now have 5*4*3*2*4 =
> 480 different combinations to try. I think we should probably limit
> ourselves to sensible combinations here.
>
>
Why do we multiply the # of cases of each category, instead of adding?
I believe that encoder will encode video clips from each category
independently to other categories.

Thanks,
Yushin

--089e012952f4d64fc6050fedaaca
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, Feb 25, 2015 at 9:39 AM, Thomas Daede <span dir=3D"ltr">&lt;<a href=
=3D"mailto:tdaede@mozilla.com" target=3D"_blank">tdaede@mozilla.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The problem with all of these dimensions is that we now have 5*4*3*2*4 =3D<=
br>
480 different combinations to try. I think we should probably limit<br>
ourselves to sensible combinations here.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br clear=3D"all"></div></div></blo=
ckquote></div><br></div><div class=3D"gmail_extra">Why do we multiply the #=
 of cases of each category, instead of adding?<br></div><div class=3D"gmail=
_extra">I believe that encoder will encode video clips from each category i=
ndependently to other categories.<br></div><div class=3D"gmail_extra"><br><=
/div><div class=3D"gmail_extra"><div class=3D"gmail_signature"><div dir=3D"=
ltr"><div>Thanks,<br></div>Yushin<br></div></div>
</div></div>

--089e012952f4d64fc6050fedaaca--


From nobody Wed Feb 25 10:27:50 2015
Return-Path: <ycho@mozilla.com>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D031A1A0470 for <video-codec@ietfa.amsl.com>; Wed, 25 Feb 2015 10:27:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 LEA6c6El5Qc5 for <video-codec@ietfa.amsl.com>; Wed, 25 Feb 2015 10:27:43 -0800 (PST)
Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D2CC1A037D for <video-codec@ietf.org>; Wed, 25 Feb 2015 10:27:42 -0800 (PST)
Received: by mail-ob0-f175.google.com with SMTP id va2so5737926obc.6 for <video-codec@ietf.org>; Wed, 25 Feb 2015 10:27:42 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rt+3QktN+t8bkqJag2Pja/xZnL5lDhKyO0Gvv975d2Q=; b=EHLmhTGWbCvZlP0wjjtnJ4tOW7StFVBxhRc/RI2uyJISaBhdd+ivRPvtIrTOSMNKBC eHoLp7g+scCo7NCs8w9+xxl4zxByGT8bboT8x4tzJlHr9eWXyHHX+YtVJYa5sWyzFDJU CNy8UO3JxLCGg814SaksoEWUtyZVn46fxxkGR5JcIlB3B+lM1B+FYsLtrrh2yf9DEgIH zhO9pDq159dr8MNFQ1ZRIHnPBvl3BM8ITQc5jai5iiLN2OwtIIPWpZS2K6hgjjFEnS/l GJSaxbu0sFRoQNB+AYLD1I5HwuKQSqtqGLMCI3XqK+foEnBhiZjNRxcx1DNuJhwYnxYj JmpQ==
X-Gm-Message-State: ALoCoQnbaPJMdKPEhkp/Dx5Hia2WbPkeMFtJDRYBeLKW3vWoOEW0lCxl82OGXkOFah36LZ2edC4V
MIME-Version: 1.0
X-Received: by 10.60.97.35 with SMTP id dx3mr3230730oeb.6.1424888862372; Wed, 25 Feb 2015 10:27:42 -0800 (PST)
Received: by 10.60.169.167 with HTTP; Wed, 25 Feb 2015 10:27:42 -0800 (PST)
In-Reply-To: <54EDE784.2000107@alvestrand.no>
References: <CACrD=+_uNyiFuKtoxNYGMOcB2jSvKdh_6mBLvpFeTeEmHDQ9PQ@mail.gmail.com> <CABcZeBOenDx=10XWP_85iSsgGVi0uaTazwfOtN7EsuXS0oUG_A@mail.gmail.com> <CABcZeBPpDNK9+uVmhYo4-LDjkeuNkX86eOsfCzfrO04aeYrYYw@mail.gmail.com> <CACrD=+8wrCc31s1smT5WRkg8t3QO+RnNVSzhwJcvAZzZ6WDFNw@mail.gmail.com> <D0ECB849.42FC4%mzanaty@cisco.com> <54ED8506.30908@alvestrand.no> <54EDDDE4.1050303@xiph.org> <54EDE784.2000107@alvestrand.no>
Date: Wed, 25 Feb 2015 10:27:42 -0800
Message-ID: <CABSTHf3Z8nqkh0jQsu4JFbHaVsD-1UrH7XegcU_rrihDq99BzQ@mail.gmail.com>
From: Yushin Cho <ycho@mozilla.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: multipart/alternative; boundary=089e01227a187c8d02050fedca88
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/rIl_-YqB9iEnUXUHT7hrUUhExjI>
Cc: video-codec@ietf.org
Subject: Re: [video-codec] Test sequences, automated and otherwise
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 25 Feb 2015 18:27:50 -0000

--089e01227a187c8d02050fedca88
Content-Type: text/plain; charset=UTF-8

I think, for all video *encoding* testing, we want to assume the input and
output resolution will be identical.
(One possible exception I can think of is : If we ever support a resolution
scalability,
then lower resolution video can be additionally decoded from the same coded
bitstream.)

Meanwhile, the encoder designers can do whatever they want inside encoder
and possibly its paired decoder,
for example encode at down sampled resolution then decode, upsample to
original input resolution,
and add pepper and salt noises on top of it.

-yushin

On Wed, Feb 25, 2015 at 7:17 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

> Den 25. feb. 2015 15:36, skrev Timothy B. Terriberry:
> > Harald Alvestrand wrote:
> >> I've come to the conclusion that varying resolution should be considered
> >> one tool for achieving lossy compression, and should not be a primary
> >> dimension - YMMV.
> >
> > Can you say a little bit more about how you would go about comparing the
> > results of two encoders that chose to encode a sequence (or even
> > individual frames within a given sequence) at different resolutions?
>
> I think comparision tools that care about what the codecs do rather than
> what the result is are problematic - so I'm not sure whether this is
> different from all the other choices encoders can make.
>
> The overall process would have to return an image suitable for display -
> for simplicity of testing, I would make the output resolution the same
> as the input resolution.
>
> We've experimented with this sort of resolution change in the WebRTC
> pipeline - encoding in a lower resolution saves both CPU and bandwidth.
>
> (Just for fun, I integrated such a rescaling into the compare-codecs
> pipeline that encodes using the H.261 encoder, to allow comparing H.261
> with its very limited available resolutions to other codecs on HD-sized
> clips - it "works", for some value of "work".
>
> psnr values of 35 dB where x264 achieves 40 dB - it seems psnr isn't
> particularly sensitive to the resulting blurriness).
>
>
> >
> > _______________________________________________
> > video-codec mailing list
> > video-codec@ietf.org
> > https://www.ietf.org/mailman/listinfo/video-codec
>
> _______________________________________________
> video-codec mailing list
> video-codec@ietf.org
> https://www.ietf.org/mailman/listinfo/video-codec
>



-- 
Thanks,
Yushin

--089e01227a187c8d02050fedca88
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>I think, for all video *encoding* testing, we wa=
nt to assume the input and output resolution will be identical.<br></div><d=
iv>(One possible exception I can think of is : If we ever support a resolut=
ion scalability, <br>then lower resolution video can be additionally decode=
d from the same coded bitstream.)<br></div><br>Meanwhile, the encoder desig=
ners can do whatever they want inside encoder and possibly its paired decod=
er, <br>for example encode at down sampled resolution then decode, upsample=
 to original input resolution, <br>and add pepper and salt noises on top of=
 it.<br><br></div>-yushin<br><div><div><div><div class=3D"gmail_extra"><br>=
<div class=3D"gmail_quote">On Wed, Feb 25, 2015 at 7:17 AM, Harald Alvestra=
nd <span dir=3D"ltr">&lt;<a href=3D"mailto:harald@alvestrand.no" target=3D"=
_blank">harald@alvestrand.no</a>&gt;</span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">Den 25. feb. 2015 15:36, skrev Timothy B. Terriberry:<br>
<span class=3D"">&gt; Harald Alvestrand wrote:<br>
&gt;&gt; I&#39;ve come to the conclusion that varying resolution should be =
considered<br>
&gt;&gt; one tool for achieving lossy compression, and should not be a prim=
ary<br>
&gt;&gt; dimension - YMMV.<br>
&gt;<br>
&gt; Can you say a little bit more about how you would go about comparing t=
he<br>
&gt; results of two encoders that chose to encode a sequence (or even<br>
&gt; individual frames within a given sequence) at different resolutions?<b=
r>
<br>
</span>I think comparision tools that care about what the codecs do rather =
than<br>
what the result is are problematic - so I&#39;m not sure whether this is<br=
>
different from all the other choices encoders can make.<br>
<br>
The overall process would have to return an image suitable for display -<br=
>
for simplicity of testing, I would make the output resolution the same<br>
as the input resolution.<br>
<br>
We&#39;ve experimented with this sort of resolution change in the WebRTC<br=
>
pipeline - encoding in a lower resolution saves both CPU and bandwidth.<br>
<br>
(Just for fun, I integrated such a rescaling into the compare-codecs<br>
pipeline that encodes using the H.261 encoder, to allow comparing H.261<br>
with its very limited available resolutions to other codecs on HD-sized<br>
clips - it &quot;works&quot;, for some value of &quot;work&quot;.<br>
<br>
psnr values of 35 dB where x264 achieves 40 dB - it seems psnr isn&#39;t<br=
>
particularly sensitive to the resulting blurriness).<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; video-codec mailing list<br>
&gt; <a href=3D"mailto:video-codec@ietf.org">video-codec@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/video-codec" target=
=3D"_blank">https://www.ietf.org/mailman/listinfo/video-codec</a><br>
<br>
_______________________________________________<br>
video-codec mailing list<br>
<a href=3D"mailto:video-codec@ietf.org">video-codec@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/video-codec" target=3D"_bl=
ank">https://www.ietf.org/mailman/listinfo/video-codec</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br><div class=
=3D"gmail_signature"><div dir=3D"ltr"><div>Thanks,<br></div>Yushin<br></div=
></div>
</div></div></div></div></div>

--089e01227a187c8d02050fedca88--


From nobody Wed Feb 25 11:38:05 2015
Return-Path: <metajack@gmail.com>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF391A8762 for <video-codec@ietfa.amsl.com>; Wed, 25 Feb 2015 11:38:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_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 S8rjEMNPO1vA for <video-codec@ietfa.amsl.com>; Wed, 25 Feb 2015 11:38:02 -0800 (PST)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 022CD1A8760 for <video-codec@ietf.org>; Wed, 25 Feb 2015 11:38:02 -0800 (PST)
Received: by lbdu14 with SMTP id u14so6182223lbd.1 for <video-codec@ietf.org>; Wed, 25 Feb 2015 11:38:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:date:message-id:subject:from:to:content-type;  bh=wgQYdz/SK78BwZ5bnZV/SL5LDQXQ2eqfx0mzw1hLlL8=; b=rKfEk7EHcMjXw0Y++iBoxSUsmic1O2ZNWYF4oTBn5q8nzbxggnCryJA8qAj6lHEx1P dKtX1pYZB5ncrnUIKZpNQQEuFptAbbVGYjGVbTcN8S4J/EtEBDU4rgyHbl+slXJmgN35 ZpfuInWRexkHHlDqO9wDBhBjgHs6Yo1cchj7n6qQSqdn9bcAk2IqeSoMfa0xVygPq9Oc 8AsIngVf3tlu0tGc6TaR0GetyPk9lJi36OnTdt0tlfPia1QIHtVE/YVWzd0MbPx7qs/n 4btoY7FGBIeOoMejdO0Qes2JbFiPVX+YvrQuE3R6IAV4cBevp3K7MXM3nE5AhhJzDSxb kvTw==
MIME-Version: 1.0
X-Received: by 10.112.8.68 with SMTP id p4mr4224335lba.37.1424893080521; Wed, 25 Feb 2015 11:38:00 -0800 (PST)
Sender: metajack@gmail.com
Received: by 10.25.38.137 with HTTP; Wed, 25 Feb 2015 11:38:00 -0800 (PST)
Date: Wed, 25 Feb 2015 12:38:00 -0700
X-Google-Sender-Auth: alNaKSEpnsamTP1EsbrI78W4r9A
Message-ID: <CAP7VpsXvhqNH761MMtDuY_VSzq9SqJzF36gw4cUZwh3rPjh=CA@mail.gmail.com>
From: Jack Moffitt <jack@metajack.im>
To: "video-codec@ietf.org" <video-codec@ietf.org>, daala@xiph.org
Content-Type: multipart/alternative; boundary=001a1135e3d2e85471050feec5cb
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/vDsmcQDMbNGqLzhsSnDdOk3Ab28>
Subject: [video-codec] Come hack on Daala @ IETF 92
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 25 Feb 2015 19:38:03 -0000

--001a1135e3d2e85471050feec5cb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Charles Eckel has organized an IETF hackathon the weekend before IETF.
Daala is one of the groups participating and we'd love to have some others
come hack with us on video codecs. There are Daala projects appropriate for
many skills levels, and several of the Daala team will be there to mentor
people who need some.

Be sure to register early as there are only so many spots available.

Here are the details from Charles:

The Internet Engineering Task Force (IETF) is holding a Hackathon to
encourage developers to discuss, collaborate and develop utilities,
ideas, sample code and solutions that show practical implementations of
IETF standards. It takes place just before IETF 92, and it=C2=B9s free and
open to everyone.

All you need is a knowledge of networking technologies, and you=C2=B9ll be
guaranteed to learn something new and have fun!

Event details: https://developer.cisco.com/site/ietf-hackathon
Link to register: https://www.ietf.org/meeting/92/hackathon-signup.html

--001a1135e3d2e85471050feec5cb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Charles Eckel has organized an IETF hackathon the wee=
kend before IETF. Daala is one of the groups participating and we&#39;d lov=
e to have some others come hack with us on video codecs. There are Daala pr=
ojects appropriate for many skills levels, and several of the Daala team wi=
ll be there to mentor people who need some.<br><br></div><div>Be sure to re=
gister early as there are only so many spots available.<br></div><div><br><=
/div>Here are the details from Charles:<br><div><div><div><br>The Internet =
Engineering Task Force (IETF) is holding a Hackathon to<br>
encourage developers to discuss, collaborate and develop utilities,<br>
ideas, sample code and solutions that show practical implementations of<br>
IETF standards. It takes place just before IETF 92, and it=C2=B9s free and<=
br>
open to everyone.<br>
<br>
All you need is a knowledge of networking technologies, and you=C2=B9ll be<=
br>
guaranteed to learn something new and have fun!<br>
<br>
Event details: <a href=3D"https://developer.cisco.com/site/ietf-hackathon" =
target=3D"_blank">https://developer.cisco.com/site/ietf-hackathon</a><br>
Link to register: <a href=3D"https://www.ietf.org/meeting/92/hackathon-sign=
up.html" target=3D"_blank">https://www.ietf.org/meeting/92/hackathon-signup=
.html</a></div></div></div></div>

--001a1135e3d2e85471050feec5cb--


From nobody Wed Feb 25 12:05:34 2015
Return-Path: <tterribe@xiph.org>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EEF1A87AF for <video-codec@ietfa.amsl.com>; Wed, 25 Feb 2015 12:05:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.277
X-Spam-Level: 
X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_FAIL=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 jjycHLYjz8Oj for <video-codec@ietfa.amsl.com>; Wed, 25 Feb 2015 12:05:29 -0800 (PST)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 704A41A87D7 for <video-codec@ietf.org>; Wed, 25 Feb 2015 12:05:29 -0800 (PST)
Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTP id EA09AF22A8 for <video-codec@ietf.org>; Wed, 25 Feb 2015 12:05:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at mozilla.org
Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx2.mail.corp.phx1.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzbEHZBDQWpk for <video-codec@ietf.org>; Wed, 25 Feb 2015 12:05:28 -0800 (PST)
Received: from [10.252.26.110] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id CDD60F2252 for <video-codec@ietf.org>; Wed, 25 Feb 2015 12:05:28 -0800 (PST)
Message-ID: <54EE2B08.9060306@xiph.org>
Date: Wed, 25 Feb 2015 12:05:28 -0800
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
MIME-Version: 1.0
To: video-codec@ietf.org
References: <CACrD=+_uNyiFuKtoxNYGMOcB2jSvKdh_6mBLvpFeTeEmHDQ9PQ@mail.gmail.com> <CABcZeBOenDx=10XWP_85iSsgGVi0uaTazwfOtN7EsuXS0oUG_A@mail.gmail.com> <CABcZeBPpDNK9+uVmhYo4-LDjkeuNkX86eOsfCzfrO04aeYrYYw@mail.gmail.com> <CACrD=+8wrCc31s1smT5WRkg8t3QO+RnNVSzhwJcvAZzZ6WDFNw@mail.gmail.com> <D0ECB849.42FC4%mzanaty@cisco.com> <54ED8506.30908@alvestrand.no> <54EDDDE4.1050303@xiph.org> <54EDE784.2000107@alvestrand.no>
In-Reply-To: <54EDE784.2000107@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/JTGLBz6YDySsalDD4jLMom42_kY>
Subject: Re: [video-codec] Test sequences, automated and otherwise
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 25 Feb 2015 20:05:30 -0000

Harald Alvestrand wrote:
> psnr values of 35 dB where x264 achieves 40 dB - it seems psnr isn't
> particularly sensitive to the resulting blurriness).

Yes, it's well-known that PSNR loves low-passing. It's not the only 
metric that's going to have these problems. FastSSIM will probably be 
similarly blind. Fixable problems, maybe, but I don't want to get in the 
business of designing my own metrics. I'm not even sure there's good 
data on human preferences for when one should downsample, but I haven't 
spent any time looking.


From nobody Wed Feb 25 13:39:32 2015
Return-Path: <mzanaty@cisco.com>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581FE1A88F1 for <video-codec@ietfa.amsl.com>; Wed, 25 Feb 2015 13:39:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 mZixOZHIeOUo for <video-codec@ietfa.amsl.com>; Wed, 25 Feb 2015 13:39:27 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33DB21A88F3 for <video-codec@ietf.org>; Wed, 25 Feb 2015 13:39:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1290; q=dns/txt; s=iport; t=1424900367; x=1426109967; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ruh5juamnGCIhHlUBlpnoO5D44q1kJZqCaIza2q8PT8=; b=ki5i+6AhWnNkxCdYtQ45SJLKlx5XDshacduwgUjis4NBl1Uacbn2kZ4+ o4UY9MPbmvLFg465ryNdxoSp+mIPDs5tYL6UdxHvaH3CRNAgP9+1ed9/I WC7VqAK7HicXVhNe50pHAd6QgamTagRAzTLwLiUeZdSwBvJ1sSpZad/lk I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BxBQCYQO5U/5BdJa1bgwKBLATJEAKBKkMBAQEBAQF8hBABAQQ6TwIBCBgeEDIlAgQBEhuIFNYVAQEBAQEBAQMBAQEBAQEBARqLE4R1hCsFj1yJRZM+IoNub4FEfwEBAQ
X-IronPort-AV: E=Sophos;i="5.09,647,1418083200"; d="scan'208";a="399093310"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-7.cisco.com with ESMTP; 25 Feb 2015 21:39:26 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t1PLdQuf014258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Feb 2015 21:39:26 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Wed, 25 Feb 2015 15:39:26 -0600
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: "Timothy B. Terriberry" <tterribe@xiph.org>, "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: [video-codec] Test sequences, automated and otherwise
Thread-Index: AQHQUUOG0j6+oUpIBUW8J94i/88ekQ==
Date: Wed, 25 Feb 2015 21:39:25 +0000
Message-ID: <D113A77C.4601D%mzanaty@cisco.com>
References: <CACrD=+_uNyiFuKtoxNYGMOcB2jSvKdh_6mBLvpFeTeEmHDQ9PQ@mail.gmail.com> <CABcZeBOenDx=10XWP_85iSsgGVi0uaTazwfOtN7EsuXS0oUG_A@mail.gmail.com> <CABcZeBPpDNK9+uVmhYo4-LDjkeuNkX86eOsfCzfrO04aeYrYYw@mail.gmail.com> <CACrD=+8wrCc31s1smT5WRkg8t3QO+RnNVSzhwJcvAZzZ6WDFNw@mail.gmail.com> <D0ECB849.42FC4%mzanaty@cisco.com> <54ED8506.30908@alvestrand.no> <54EDDDE4.1050303@xiph.org> <54EDE784.2000107@alvestrand.no> <54EE2B08.9060306@xiph.org>
In-Reply-To: <54EE2B08.9060306@xiph.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.8.150116
x-originating-ip: [64.100.32.216]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <50C6A8A6FFE9A24789AADA4BEA34AD09@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/Z0lpeAUP-tRGivkfqVfJ8X1Qyzk>
Subject: Re: [video-codec] Test sequences, automated and otherwise
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 25 Feb 2015 21:39:31 -0000

This is perhaps getting into charter bashing, but I think we will need
some early milestone (close to requirements) for an evaluation criteria
document that represents the workgroup consensus on comparative testing
methodology and selection of solution candidates or specific tools. The
set of test sequences will only be one small part of that. Metrics will be
a very important part of that. While I agree designing new metrics should
probably be beyond the scope of proposed deliverables, I think we likely
need a thorough evaluation and discussion of various metrics and reach
some consensus on how proposed solutions and tools will be measured and
adopted.

Mo

On 2/25/15, 3:05 PM, Timothy B. Terriberry <tterribe@xiph.org> wrote:

Harald Alvestrand wrote:
> psnr values of 35 dB where x264 achieves 40 dB - it seems psnr isn't
> particularly sensitive to the resulting blurriness).

Yes, it's well-known that PSNR loves low-passing. It's not the only
metric that's going to have these problems. FastSSIM will probably be
similarly blind. Fixable problems, maybe, but I don't want to get in the
business of designing my own metrics. I'm not even sure there's good
data on human preferences for when one should downsample, but I haven't
spent any time looking.


From nobody Wed Feb 25 14:11:28 2015
Return-Path: <tdaede@mozilla.com>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35651A90FD for <video-codec@ietfa.amsl.com>; Wed, 25 Feb 2015 14:11:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 lFpHgVvysZpQ for <video-codec@ietfa.amsl.com>; Wed, 25 Feb 2015 14:11:22 -0800 (PST)
Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF3BB1A1B69 for <video-codec@ietf.org>; Wed, 25 Feb 2015 14:11:22 -0800 (PST)
Received: by padet14 with SMTP id et14so8476406pad.11 for <video-codec@ietf.org>; Wed, 25 Feb 2015 14:11:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=z1PWc6uQbTGySjFShSGcXH5ivt4S9csVVwMODJLm83o=; b=YoBxujDDRnzdRj99a8RIExIbPE8E5c/VrKw5VJ+/ExOoKXINWqB9w58ps3xPOhTmSk jL7HBEwBIi69ykxeML+mj/4MX8ZJ81oE/1zf8dEXGr8gMYjquKEDwxN35McljCSwJOoL +49fXwb5mFva/E3UFqcMmnbORuZShT6x0OYth8FjNB4p/A//V7KhHDBEzklEL6Eyvgfe lw1fMWfaXZl9Tj6kRJn+Dy7t66p+8mI+dJv6KCS64sAviAaTCO7o2yec83G08jbebvHb AP7mhV4KOSgqIVlccnrwB+gJ5+UQsl7/iRHbHXXYF1B8CATWCIFoGF9GIq5s8nNO5sMc Z1bg==
X-Gm-Message-State: ALoCoQlTYW7KsSkiEH6sYScOM6M6mSxITmbtP3GgBBZSjciSU+U17tmDg8tqE+LdsZKdYZt58wUo
X-Received: by 10.67.10.47 with SMTP id dx15mr9204900pad.139.1424902282224; Wed, 25 Feb 2015 14:11:22 -0800 (PST)
Received: from ?IPv6:2620:101:80fc:224:7e7a:91ff:fe9e:8126? ([2620:101:80fc:224:7e7a:91ff:fe9e:8126]) by mx.google.com with ESMTPSA id ng17sm21380786pdb.91.2015.02.25.14.11.21 for <video-codec@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Feb 2015 14:11:21 -0800 (PST)
Message-ID: <54EE4884.7050706@mozilla.com>
Date: Wed, 25 Feb 2015 14:11:16 -0800
From: Thomas Daede <tdaede@mozilla.com>
User-Agent: http://a.pomf.se/cszdno.opus
MIME-Version: 1.0
To: video-codec@ietf.org
References: <CACrD=+_uNyiFuKtoxNYGMOcB2jSvKdh_6mBLvpFeTeEmHDQ9PQ@mail.gmail.com> <CABcZeBOenDx=10XWP_85iSsgGVi0uaTazwfOtN7EsuXS0oUG_A@mail.gmail.com> <CABcZeBPpDNK9+uVmhYo4-LDjkeuNkX86eOsfCzfrO04aeYrYYw@mail.gmail.com> <CACrD=+8wrCc31s1smT5WRkg8t3QO+RnNVSzhwJcvAZzZ6WDFNw@mail.gmail.com> <D0ECB849.42FC4%mzanaty@cisco.com> <54ED8506.30908@alvestrand.no> <54EDDDE4.1050303@xiph.org> <54EDE784.2000107@alvestrand.no> <54EE2B08.9060306@xiph.org> <D113A77C.4601D%mzanaty@cisco.com>
In-Reply-To: <D113A77C.4601D%mzanaty@cisco.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/wKVWn_I9TNJgVFV-3_QVogZ9SUY>
Subject: Re: [video-codec] Test sequences, automated and otherwise
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 25 Feb 2015 22:11:28 -0000

To start the discussion, here is a brief overview of the four metrics we
currently use in Daala. The reference code is in the tools/dump_*.c
files in the Daala repository. Note that all of these metrics are
applied to the luma plane only.

## PSNR

PSNR is a traditional signal quality metric, measured in decibels. It is
directly drived from mean square error (MSE), or its square root (RMSE).
The formula used is:

20 * log10 ( MAX / RMSE )

or, equivalently:

10 * log10 ( MAX^2 / MSE )

which is the method used in the dump_psnr.c reference implementation.

## PSNR-HVS-M

The PSNR-HVS metric performs a DCT transform of 8x8 blocks of the image,
weights the coefficients, and then calculates the PSNR of those
coefficients. Several different sets of weights have been considered.
The weights used by the dump_pnsrhvs.c tool have been found to be the
best match to real MOS scores.

## SSIM

SSIM (Structural Similarity Image Metric) is a still image quality
metric introduced in 2004. It computes a score for each individual
pixel, using a window of neighboring pixels. These scores can then be
averaged to produce a global score for the entire image. The original
paper produces scores ranging between 0 and 1.

For the metric to appear more linear on BD-rate curves, the score is
converted into a nonlinear decibel scale:

-10 * log10 (1 - SSIM)

## Fast Multi-Scale SSIM

Multi-Scale SSIM is SSIM extended to multiple window sizes. This is
implemented by downscaling the image a number of times, and computing
SSIM over the same number of pixels, then averaging the SSIM scores
together. The final score is converted to decibels in the same manner as
SSIM.

On 02/25/2015 01:39 PM, Mo Zanaty (mzanaty) wrote:
> This is perhaps getting into charter bashing, but I think we will need
> some early milestone (close to requirements) for an evaluation criteria
> document that represents the workgroup consensus on comparative testing
> methodology and selection of solution candidates or specific tools. The
> set of test sequences will only be one small part of that. Metrics will be
> a very important part of that. While I agree designing new metrics should
> probably be beyond the scope of proposed deliverables, I think we likely
> need a thorough evaluation and discussion of various metrics and reach
> some consensus on how proposed solutions and tools will be measured and
> adopted.
> 
> Mo
> 
> On 2/25/15, 3:05 PM, Timothy B. Terriberry <tterribe@xiph.org> wrote:
> 
> Harald Alvestrand wrote:
>> psnr values of 35 dB where x264 achieves 40 dB - it seems psnr isn't
>> particularly sensitive to the resulting blurriness).
> 
> Yes, it's well-known that PSNR loves low-passing. It's not the only
> metric that's going to have these problems. FastSSIM will probably be
> similarly blind. Fixable problems, maybe, but I don't want to get in the
> business of designing my own metrics. I'm not even sure there's good
> data on human preferences for when one should downsample, but I haven't
> spent any time looking.
> 
> _______________________________________________
> video-codec mailing list
> video-codec@ietf.org
> https://www.ietf.org/mailman/listinfo/video-codec
>