
From nobody Thu Jul  2 13:54:43 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 F39171A00C0 for <video-codec@ietfa.amsl.com>; Thu,  2 Jul 2015 13:54:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.599
X-Spam-Level: 
X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_ABOUTYOU=0.5, 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 PJqOMJRxHHAx for <video-codec@ietfa.amsl.com>; Thu,  2 Jul 2015 13:54:40 -0700 (PDT)
Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) (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 F23F81A00BF for <video-codec@ietf.org>; Thu,  2 Jul 2015 13:54:39 -0700 (PDT)
Received: by pdbci14 with SMTP id ci14so50873422pdb.2 for <video-codec@ietf.org>; Thu, 02 Jul 2015 13:54:39 -0700 (PDT)
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:content-type:content-transfer-encoding; bh=4xbP0ToXdg7co6MLdylQFFBJJ1BzC9HBz2QlDqArOFk=; b=P+iijbYXpw8vqdgBGVUQeqaW5QXwaQCUAu3gwOaiL4gfWOf9X3JrfsyDP5Wo5qFNut QN2BQseaT2u5CEBZotLlAV1kbF7BNXo0V7Y7rtFgyiOWlJGVENp6S+Wl4dPaHhEDYIgu fqDq7uHlH+/eDNCkoj78eU5B/S+Df7mKKPjjo4zmDIVLu+iKEwuwH18Fdh5euf753Ah/ Wq2Mt739F5hlsLP5nH6IZmCwdP6uR43a7l/kfxKusxBUUvKkzdtw/SvlduuHS3/Mq8Pe YpJXQnHHEzcUkw0p6faNIoT+VDecRgEWeq57fHIOzgPhaLzK7+a9/IEDBe+/WKC/BctP tSjw==
X-Gm-Message-State: ALoCoQmNpJqV+Ag/KU4ll//dT6DSX8Xj5KJ+raDuIxmZVL4Py6wfRZABE65GP0CGSOaqtjyxhzSu
X-Received: by 10.68.129.38 with SMTP id nt6mr69934243pbb.30.1435870479606; Thu, 02 Jul 2015 13:54:39 -0700 (PDT)
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 ho10sm6652276pbc.27.2015.07.02.13.54.37 for <video-codec@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Jul 2015 13:54:38 -0700 (PDT)
Message-ID: <5595A50B.1030409@mozilla.com>
Date: Thu, 02 Jul 2015 13:54:35 -0700
From: Thomas Daede <tdaede@mozilla.com>
User-Agent: http://a.pomf.se/cszdno.opus
MIME-Version: 1.0
To: video-codec@ietf.org
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/4oFiuKXy3zcsM_nI2NzZB6QH3UE>
Subject: [video-codec] Comments on draft-filippov-netvc-requirements-00
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: <https://mailarchive.ietf.org/arch/browse/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, 02 Jul 2015 20:54:42 -0000

First of all, thank you for submitting this draft! I will be the one
working on merging any remaining parts of
draft-moffitt-netvc-requirements-00 into your draft.

I have some comments about your draft, organized by section.

2.1. Internet Protocol Television (IPTV)

I don't think either error robustness or temporal scalability are
necessary here. This sort of content is usually delivered over a
reliable network with high latency, like TCP.

Also, I would really like to not support interlacing. I would suggest
removing the interlaced formats and recommending a deinterlacer be used
before encoding.

2.2. Video conferencing

I would suggest dropping all of the CIF/SIF/nonsquare pixel formats.
480p and 360p could replace them.

2.3. Video sharing

So the main difference between 2.3 and 2.1 seems to be the content
source. I would suggest replacing section 2.1 with 2.3 entirely.

2.4. Screencasting

It should probably be made clear that these are input formats, but not
necessarily what the encoder will run at. I would expect a reasonable
encoder to convert RGB to YCbCr or YCgCo internally. In addition, high
frame drop is really common for screencasting, for effective frame rates
of 15fps or less.

2.5. Game streaming

Why is this the only category that requires resolution scalability?

3.1. Basic requirements

Is the intent that all decoders should support decoding 8 and 10 bit
bitstreams? Also, maybe swap 4:2:2 with 4:4:4, as 4:2:2 isn't in any of
the usecases mentioned earlier.

4.1. Compression performance evaluation

Are you suggesting running all of the codecs in CBR mode? I don't think
this makes sense for many of the applications mentioned earlier. In
addition, you are going to need to specify CBR buffer sizes, etc. The
equation you give seems to give the rate over the whole file, which I
would normally consider VBR.
Also, I'm not sure how much of this belongs in this draft versus the
testing draft.


From nobody Fri Jul  3 07:37:38 2015
Return-Path: <gmcoppa@cbs.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 88F7B1A1A00 for <video-codec@ietfa.amsl.com>; Fri,  3 Jul 2015 07:37:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.29
X-Spam-Level: *
X-Spam-Status: No, score=1.29 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 OyQVanLuNLwe for <video-codec@ietfa.amsl.com>; Fri,  3 Jul 2015 07:37:35 -0700 (PDT)
Received: from mail-la.cbs.com (mail-la.cbs.com [192.238.125.250]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D7981A0AC8 for <video-codec@ietf.org>; Fri,  3 Jul 2015 07:37:35 -0700 (PDT)
Received: from unknown (HELO ED1PWISTMSXHC01.cbs.ad.cbs.net) ([10.149.32.80]) by smtprelay.cbs.com with ESMTP; 03 Jul 2015 10:37:34 -0400
Received: from ED1PWISTMSXMB06.cbs.ad.cbs.net ([169.254.12.159]) by ED1PWISTMSXHC01.cbs.ad.cbs.net ([10.149.32.80]) with mapi id 14.03.0195.001; Fri, 3 Jul 2015 10:37:33 -0400
From: "Coppa, Greg" <gmcoppa@cbs.com>
To: Thomas Daede <tdaede@mozilla.com>, "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: [video-codec] Comments on draft-filippov-netvc-requirements-00
Thread-Index: AQHQtQlVkDiKDvvN7EKjDm6Pdz0HWp3JzB8N
Date: Fri, 3 Jul 2015 14:37:33 +0000
Message-ID: <3569E2579E6AF14AAD30C8E74C9F9F8867F59108@ED1PWISTMSXMB06.cbs.ad.cbs.net>
References: <5595A50B.1030409@mozilla.com>
In-Reply-To: <5595A50B.1030409@mozilla.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [68.173.9.71]
Content-Type: multipart/alternative; boundary="_000_3569E2579E6AF14AAD30C8E74C9F9F8867F59108ED1PWISTMSXMB06_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/jep2N2xaWYlhQ5AzrzADYp2Fx5M>
Subject: Re: [video-codec] Comments on draft-filippov-netvc-requirements-00
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 03 Jul 2015 14:37:37 -0000

--_000_3569E2579E6AF14AAD30C8E74C9F9F8867F59108ED1PWISTMSXMB06_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear All -

With regard to Section 2.1 Internet Protocol Television (IPTV) and Table 1.=
 I note that the use case states "Typical content used in this application =
is movies, cartoons, series, TV shows, etc."

Table 1 lists 1080p at 24, 50 and 60 fps, and while these resolution/frame =
rates may be used they do not represent typical content formats that a US B=
roadcaster (e.g. CBS) delivers; a very typical format for the typical conte=
nt types noted is 1080i at 59.94 fields per second (29.97 frames per second=
) and I suggest that this be added to Table 1 as a typically delivered cont=
ent type.

I'd also point out that 2160p @ 30 may be used in limited cases however the=
 frame rate is too low for most content (particularly Sports) and that at t=
he resolution of 2160p, 59.94 frames per second is a more realistic and nec=
essary use case. I suggest that this also be added to Table 1.

greg
________________________________________
From: video-codec [video-codec-bounces@ietf.org] on behalf of Thomas Daede =
[tdaede@mozilla.com]
Sent: Thursday, July 02, 2015 4:54 PM
To: video-codec@ietf.org
Subject: [video-codec] Comments on draft-filippov-netvc-requirements-00

First of all, thank you for submitting this draft! I will be the one
working on merging any remaining parts of
draft-moffitt-netvc-requirements-00 into your draft.

I have some comments about your draft, organized by section.

2.1. Internet Protocol Television (IPTV)

I don't think either error robustness or temporal scalability are
necessary here. This sort of content is usually delivered over a
reliable network with high latency, like TCP.

Also, I would really like to not support interlacing. I would suggest
removing the interlaced formats and recommending a deinterlacer be used
before encoding.

2.2. Video conferencing

I would suggest dropping all of the CIF/SIF/nonsquare pixel formats.
480p and 360p could replace them.

2.3. Video sharing

So the main difference between 2.3 and 2.1 seems to be the content
source. I would suggest replacing section 2.1 with 2.3 entirely.

2.4. Screencasting

It should probably be made clear that these are input formats, but not
necessarily what the encoder will run at. I would expect a reasonable
encoder to convert RGB to YCbCr or YCgCo internally. In addition, high
frame drop is really common for screencasting, for effective frame rates
of 15fps or less.

2.5. Game streaming

Why is this the only category that requires resolution scalability?

3.1. Basic requirements

Is the intent that all decoders should support decoding 8 and 10 bit
bitstreams? Also, maybe swap 4:2:2 with 4:4:4, as 4:2:2 isn't in any of
the usecases mentioned earlier.

4.1. Compression performance evaluation

Are you suggesting running all of the codecs in CBR mode? I don't think
this makes sense for many of the applications mentioned earlier. In
addition, you are going to need to specify CBR buffer sizes, etc. The
equation you give seems to give the rate over the whole file, which I
would normally consider VBR.
Also, I'm not sure how much of this belongs in this draft versus the
testing draft.

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

--_000_3569E2579E6AF14AAD30C8E74C9F9F8867F59108ED1PWISTMSXMB06_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html dir=3D"ltr">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" id=3D"owaParaStyle"></style>
</head>
<body style=3D"zoom: 1;" fpstyle=3D"1" ocsi=3D"0">
<div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: =
12pt;">Dear All -
<br>
<br>
With regard to Section 2.1 Internet Protocol Television (IPTV) and Table 1.=
 I note that the use case states &quot;<i>Typical content</i> used in this =
application is movies, cartoons,&nbsp;series, TV shows, etc.&quot;&nbsp;
<div><br>
</div>
<div>Table 1 lists 1080p at 24, 50 and 60 fps, and while these resolution/f=
rame rates may be used they do not represent&nbsp;typical content formats t=
hat a US Broadcaster (e.g. CBS) delivers; a very&nbsp;typical&nbsp;format f=
or the typical content types noted is 1080i at
 59.94 fields per second (29.97 frames per second) and I suggest that this =
be added to Table 1 as a typically delivered content type.</div>
<div><br>
</div>
<div>I'd also point out that 2160p @ 30 may be used in limited cases howeve=
r the frame rate is too low for most content (particularly Sports) and that=
 at the resolution of 2160p, 59.94 frames per second is a more realistic an=
d necessary use case. I suggest
 that this also be added to Table 1.</div>
<div><br>
</div>
<div>greg</div>
<div>________________________________________<br>
From: video-codec [video-codec-bounces@ietf.org] on behalf of Thomas Daede =
[tdaede@mozilla.com]<br>
Sent: Thursday, July 02, 2015 4:54 PM<br>
To: video-codec@ietf.org<br>
Subject: [video-codec] Comments on draft-filippov-netvc-requirements-00<br>
<br>
First of all, thank you for submitting this draft! I will be the one<br>
working on merging any remaining parts of<br>
draft-moffitt-netvc-requirements-00 into your draft.<br>
<br>
I have some comments about your draft, organized by section.<br>
<br>
2.1. Internet Protocol Television (IPTV)<br>
<br>
I don't think either error robustness or temporal scalability are<br>
necessary here. This sort of content is usually delivered over a<br>
reliable network with high latency, like TCP.<br>
<br>
Also, I would really like to not support interlacing. I would suggest<br>
removing the interlaced formats and recommending a deinterlacer be used<br>
before encoding.<br>
<br>
2.2. Video conferencing<br>
<br>
I would suggest dropping all of the CIF/SIF/nonsquare pixel formats.<br>
480p and 360p could replace them.<br>
<br>
2.3. Video sharing<br>
<br>
So the main difference between 2.3 and 2.1 seems to be the content<br>
source. I would suggest replacing section 2.1 with 2.3 entirely.<br>
<br>
2.4. Screencasting<br>
<br>
It should probably be made clear that these are input formats, but not<br>
necessarily what the encoder will run at. I would expect a reasonable<br>
encoder to convert RGB to YCbCr or YCgCo internally. In addition, high<br>
frame drop is really common for screencasting, for effective frame rates<br=
>
of 15fps or less.<br>
<br>
2.5. Game streaming<br>
<br>
Why is this the only category that requires resolution scalability?<br>
<br>
3.1. Basic requirements<br>
<br>
Is the intent that all decoders should support decoding 8 and 10 bit<br>
bitstreams? Also, maybe swap 4:2:2 with 4:4:4, as 4:2:2 isn't in any of<br>
the usecases mentioned earlier.<br>
<br>
4.1. Compression performance evaluation<br>
<br>
Are you suggesting running all of the codecs in CBR mode? I don't think<br>
this makes sense for many of the applications mentioned earlier. In<br>
addition, you are going to need to specify CBR buffer sizes, etc. The<br>
equation you give seems to give the rate over the whole file, which I<br>
would normally consider VBR.<br>
Also, I'm not sure how much of this belongs in this draft versus the<br>
testing draft.<br>
<br>
_______________________________________________<br>
video-codec mailing list<br>
video-codec@ietf.org<br>
https://www.ietf.org/mailman/listinfo/video-codec</div>
</div>
</body>
</html>

--_000_3569E2579E6AF14AAD30C8E74C9F9F8867F59108ED1PWISTMSXMB06_--


From nobody Fri Jul  3 11:59:56 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 946131A1C02 for <video-codec@ietfa.amsl.com>; Fri,  3 Jul 2015 11:59:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.201
X-Spam-Level: 
X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 Y9yjV26pViM7 for <video-codec@ietfa.amsl.com>; Fri,  3 Jul 2015 11:59:53 -0700 (PDT)
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 7B2661A1BFF for <video-codec@ietf.org>; Fri,  3 Jul 2015 11:59:53 -0700 (PDT)
Received: by pabvl15 with SMTP id vl15so60791191pab.1 for <video-codec@ietf.org>; Fri, 03 Jul 2015 11:59:53 -0700 (PDT)
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=Eh4BYmhMsAr7hc7W163znrsGi/gE2htzi3BVhaLDf3k=; b=ALB5ORFxYO4Bc2ZjnVduAf8goC+qBAG3QE+/QfXwJHZ68/mFmqBsE0ALJ2J2k8QlW5 YksNGd15tKEL0nnxD5JSx1An85dF7pgz1OtBBhAmCgeQFDigUJE0sQlyCQnWeheAw89R PgPttyYH57elgCMG4wKbzAbzJwZnfy+e5A1ZXzUx6qDq5WZroYTShmJNMDizKve/uTs8 U1YCMoqZpO5eFB8ecNK2y903EYQskZ2o4TkjbZkuUSrQesD6ZNJ88Uwewc7NEY/ogrgh QknR/fQvuAkxYOhltGSwwnc7c0ReLx5uuQ0dSR8ryDWOl4fJXfOGTwyCgzp08DJ8fNdN XuRw==
X-Gm-Message-State: ALoCoQn9dvzUhV1wivNsugAoO+6AlimOhHgk5euXYPO+TDrSw3NEBG6ep+UAnQAxvOXik4C2b2ba
X-Received: by 10.68.57.226 with SMTP id l2mr60988978pbq.61.1435949993140; Fri, 03 Jul 2015 11:59:53 -0700 (PDT)
Received: from [10.0.0.120] ([172.56.16.234]) by mx.google.com with ESMTPSA id l7sm9828147pbq.87.2015.07.03.11.59.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Jul 2015 11:59:51 -0700 (PDT)
Message-ID: <5596DBA5.9080301@mozilla.com>
Date: Fri, 03 Jul 2015 11:59:49 -0700
From: Thomas Daede <tdaede@mozilla.com>
User-Agent: http://a.pomf.se/cszdno.opus
MIME-Version: 1.0
To: "Coppa, Greg" <gmcoppa@cbs.com>,  "video-codec@ietf.org" <video-codec@ietf.org>
References: <5595A50B.1030409@mozilla.com> <3569E2579E6AF14AAD30C8E74C9F9F8867F59108@ED1PWISTMSXMB06.cbs.ad.cbs.net>
In-Reply-To: <3569E2579E6AF14AAD30C8E74C9F9F8867F59108@ED1PWISTMSXMB06.cbs.ad.cbs.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/AauhQAs4zaMUDhRX5CtQwpgwQ6s>
Subject: Re: [video-codec] Comments on draft-filippov-netvc-requirements-00
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 03 Jul 2015 18:59:55 -0000

On 07/03/2015 07:37 AM, Coppa, Greg wrote:
> Table 1 lists 1080p at 24, 50 and 60 fps, and while these
> resolution/frame rates may be used they do not represent typical content
> formats that a US Broadcaster (e.g. CBS) delivers; a very typical format
> for the typical content types noted is 1080i at 59.94 fields per second
> (29.97 frames per second) and I suggest that this be added to Table 1 as
> a typically delivered content type.
> 

We should explicitly specify whether the tables are for input content or
for the actual encoding and output format. e.g. I would expect a
deinterlacer or IVTC to be applied before encoding content if necessary.
The same problem happens with screencasting, which frequently uses way
lower framerates than the screen refresh rate (60-144fps).


From nobody Fri Jul  3 12:22:04 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 76CD71A6F33 for <video-codec@ietfa.amsl.com>; Fri,  3 Jul 2015 12:22:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.723
X-Spam-Level: *
X-Spam-Status: No, score=1.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, SPF_FAIL=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 3tVNmcLS9Cyi for <video-codec@ietfa.amsl.com>; Fri,  3 Jul 2015 12:22:02 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (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 375091A6F30 for <video-codec@ietf.org>; Fri,  3 Jul 2015 12:22:01 -0700 (PDT)
Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 03139C0971 for <video-codec@ietf.org>; Fri,  3 Jul 2015 19:22:01 +0000 (UTC)
X-Virus-Scanned: amavisd-new at mozilla.org
Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3F6S696GpHFe for <video-codec@ietf.org>; Fri,  3 Jul 2015 19:22:00 +0000 (UTC)
Received: from [172.17.0.26] (50-78-100-113-static.hfc.comcastbusiness.net [50.78.100.113]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id CA160C045F for <video-codec@ietf.org>; Fri,  3 Jul 2015 19:22:00 +0000 (UTC)
Message-ID: <5596E0D8.8010400@xiph.org>
Date: Fri, 03 Jul 2015 12:22:00 -0700
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" <video-codec@ietf.org>
References: <5595A50B.1030409@mozilla.com> <3569E2579E6AF14AAD30C8E74C9F9F8867F59108@ED1PWISTMSXMB06.cbs.ad.cbs.net> <5596DBA5.9080301@mozilla.com>
In-Reply-To: <5596DBA5.9080301@mozilla.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/1WSFZi6uUKWTjiOe7mUrCmyzlOY>
Subject: Re: [video-codec] Comments on draft-filippov-netvc-requirements-00
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 03 Jul 2015 19:22:03 -0000

Thomas Daede wrote:
> We should explicitly specify whether the tables are for input content or
> for the actual encoding and output format. e.g. I would expect a
> deinterlacer or IVTC to be applied before encoding content if necessary.
> The same problem happens with screencasting, which frequently uses way
> lower framerates than the screen refresh rate (60-144fps).

For non-trivial encoder conversions like changing interlacing or 
framerates, you'll want to be very explicit about how you'll measure 
quality.


From nobody Mon Jul  6 14:07:43 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 70DA21B328C for <video-codec@ietfa.amsl.com>; Mon,  6 Jul 2015 14:07:39 -0700 (PDT)
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 xHaOrdUFefpw for <video-codec@ietfa.amsl.com>; Mon,  6 Jul 2015 14:07:38 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3BF71B328B for <video-codec@ietf.org>; Mon,  6 Jul 2015 14:07:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=998; q=dns/txt; s=iport; t=1436216857; x=1437426457; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=G/+7ope9fMBZgfVul6XD2yqjgehnbaEGK4vIx6tHmIA=; b=mKK0pZcVtIWtlanM/YUwyjvo/KRxB5clhX7oo4F40ndfz6ny1YnTOko3 aNihjPqtmAv9lDVueSOZ3Ud8IXgjrENaE8vELgW9T6mIdm6qkes3Ki3EQ nqr8OjTUSoiG/InOZSmI/1bnX0MFBaP5mrvvdkJRnMV86IkeZT1EiOCsc Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C9AwBS7ZpV/5hdJa1cgxJUYAa9VwmBboV3AoE7OBQBAQEBAQEBgQqEJAEBBDo/EAIBCDYQMiUCBA4FiC4Ny10BAQEBAQEBAQEBAQEBAQEBAQEBAQETBItLhQYHhCsBBJQVAYtngTqEFY8qg10mg3tvgUeBBAEBAQ
X-IronPort-AV: E=Sophos;i="5.15,417,1432598400"; d="scan'208";a="13084247"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 06 Jul 2015 21:07:37 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t66L7bg5000935 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Jul 2015 21:07:37 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.240]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Mon, 6 Jul 2015 16:07:36 -0500
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: Preliminary Agenda
Thread-Index: AQHQuC/IJhA0e8FIYki197hev2ZkZg==
Date: Mon, 6 Jul 2015 21:07:36 +0000
Message-ID: <D1C061D4.51117%mzanaty@cisco.com>
References: <55931FBE.5050609@nostrum.com>
In-Reply-To: <55931FBE.5050609@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.2.150604
x-originating-ip: [64.100.32.216]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <F70DBE3FE2D75F44B7996CDA153BC882@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/z2YYcYs7E6Qm2N5ggBKQBj-4DfM>
Cc: Adam Roach <adam@nostrum.com>
Subject: Re: [video-codec] Preliminary Agenda
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: <https://mailarchive.ietf.org/arch/browse/video-codec/>
List-Post: <mailto:video-codec@ietf.org>
List-Help: <mailto:video-codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/video-codec>, <mailto:video-codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jul 2015 21:07:39 -0000

The netvc agenda has been updated with links to all drafts.
Thanks to all authors for submitting their drafts and updates.

https://www.ietf.org/proceedings/93/agenda/agenda-93-netvc


If you would like to request agenda time and have not already done so,
please submit your request (topic/draft and time requested) to
netvc-chairs@tools.ietf.org by Thursday July 9.

Thanks,
Mo (as chair)

On 6/30/15, 7:01 PM, Adam Roach <adam@nostrum.com> wrote:

[as chair]

We now have a preliminary agenda up for NETVC at the upcoming meeting in
Prague:

https://www.ietf.org/proceedings/93/agenda/agenda-93-netvc

Note that the mentioned Thor document isn't yet in the repository, but
we expect it to be available prior to the document deadline on Monday.
Also, while the requirements slot mentions only
draft-filippov-netvc-requirements, the plan is to incorporate the
contents of draft-moffitt-netvc-requirements into that document prior to
the document deadline as well.

/a


From nobody Mon Jul  6 15:32:24 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 BC98B1A86EA for <video-codec@ietfa.amsl.com>; Mon,  6 Jul 2015 15:32:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.977
X-Spam-Level: 
X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, 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 E8DZx3pbrhXs for <video-codec@ietfa.amsl.com>; Mon,  6 Jul 2015 15:32:19 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (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 E28C41A212D for <video-codec@ietf.org>; Mon,  6 Jul 2015 15:32:18 -0700 (PDT)
Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 74C90C1604 for <video-codec@ietf.org>; Mon,  6 Jul 2015 22:32:18 +0000 (UTC)
X-Virus-Scanned: amavisd-new at mozilla.org
Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJ78H5KMbltt for <video-codec@ietf.org>; Mon,  6 Jul 2015 22:32:18 +0000 (UTC)
Received: from [10.252.26.16] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 60ED6C05FE for <video-codec@ietf.org>; Mon,  6 Jul 2015 22:32:18 +0000 (UTC)
Message-ID: <559B01F2.3060204@xiph.org>
Date: Mon, 06 Jul 2015 15:32:18 -0700
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" <video-codec@ietf.org>
References: <20150706222840.25069.32034.idtracker@ietfa.amsl.com>
In-Reply-To: <20150706222840.25069.32034.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20150706222840.25069.32034.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/uIqdmNuDEO66vyLCflsvTxPDwhM>
Subject: [video-codec] Fwd: New Version Notification for draft-terriberry-netvc-obmc-00.txt
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: <https://mailarchive.ietf.org/arch/browse/video-codec/>
List-Post: <mailto:video-codec@ietf.org>
List-Help: <mailto:video-codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/video-codec>, <mailto:video-codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jul 2015 22:32:23 -0000

I submitted the following draft documenting Daala's variable-block-size 
OBMC scheme. This is based on the SPIE paper I presented at a conference 
in March, 
<http://spie.org/Publications/Proceedings/Paper/10.1117/12.2080412>, but 
updated with recent improvements.

-------- Forwarded Message --------
Subject: New Version Notification for draft-terriberry-netvc-obmc-00.txt
Date: Mon, 06 Jul 2015 15:28:40 -0700
From: internet-drafts@ietf.org
To: Timothy Terriberry <tterribe@xiph.org>, Timothy B. Terriberry 
<tterribe@xiph.org>


A new version of I-D, draft-terriberry-netvc-obmc-00.txt
has been successfully submitted by Timothy B. Terriberry and posted to the
IETF repository.

Name:		draft-terriberry-netvc-obmc
Revision:	00
Title:		Overlapped Block Motion Compensation for NETVC
Document date:	2015-07-06
Group:		Individual Submission
Pages:		16
URL: 
https://www.ietf.org/internet-drafts/draft-terriberry-netvc-obmc-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-terriberry-netvc-obmc/
Htmlized:       https://tools.ietf.org/html/draft-terriberry-netvc-obmc-00


Abstract:
    This document proposes a scheme for overlapped block motion
    compensation that could be incorporated into a next-generation video
    codec.  The scheme described is that currently used by Xiph's Daala
    project, which supports variable block sizes without introducing any
    discontinuities at block boundaries.  This makes the scheme suitable
    for use with lapped transforms or other techniques where encoding
    such discontinuities is expensive.

 



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


From nobody Mon Jul  6 17:05:39 2015
Return-Path: <jmvalin@jmvalin.ca>
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 3ED341A21AB for <video-codec@ietfa.amsl.com>; Mon,  6 Jul 2015 17:05:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4TdXAeTikBXc for <video-codec@ietfa.amsl.com>; Mon,  6 Jul 2015 17:05:36 -0700 (PDT)
Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.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 78E7C1A1A6A for <video-codec@ietf.org>; Mon,  6 Jul 2015 17:05:36 -0700 (PDT)
Received: by qgef3 with SMTP id f3so27178001qge.0 for <video-codec@ietf.org>; Mon, 06 Jul 2015 17:05:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=MRzlwBXfE4WaoyvqD9Tknv079I8WJvbF56KrAH6ZZg4=; b=cB6ylA7Iot/YpeY2YraTG/mIfX2XKITj6/VeGlykMibXmOPSMVL/71ipCiD/dzo+Ni 29yeSqgWJefSrQbvEZm+QTmy8svmJcz/opwYJQYYouXLqL68TftB3Twix6cNOyjBmXqL tJqHHSn6MKkOj1wNIS/JHJqUgETpoTRUxJ2v9jYV8qbjn6QYRXTcppV1psRboepWZooQ RvJIIq5wjFkIP6jvv8hAc0hhZT7FviRhn+jrA3AMEoXwO5Ci+ZQRGPl5jwMNHXE0Pcbm YV9sViHy6LS9hu7dLGIINGqn+Al0/owRs0pLhm6Ul24DKEXDFRCLShxACu9jMZN7nm8R OF2A==
X-Gm-Message-State: ALoCoQktCDOF2fQ6IYGjvP5uQIsVda5jBSOZh5oA8ArN/FtFqJvajGHYFaDcjHG0FcRgMdpZ6wcw
X-Received: by 10.55.22.161 with SMTP id 33mr2535643qkw.11.1436227535748; Mon, 06 Jul 2015 17:05:35 -0700 (PDT)
Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by mx.google.com with ESMTPSA id 202sm10166461qhy.1.2015.07.06.17.05.34 for <video-codec@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2015 17:05:35 -0700 (PDT)
References: <20150706235757.28545.68675.idtracker@ietfa.amsl.com>
To: video-codec@ietf.org
From: Jean-Marc Valin <jmvalin@jmvalin.ca>
X-Enigmail-Draft-Status: N1110
X-Forwarded-Message-Id: <20150706235757.28545.68675.idtracker@ietfa.amsl.com>
Message-ID: <559B17CD.2020905@jmvalin.ca>
Date: Mon, 6 Jul 2015 20:05:33 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <20150706235757.28545.68675.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/MyjByDAEc6G3BOmUFJcObLo_G0A>
Subject: [video-codec] Fwd: New Version Notification for draft-valin-netvc-l1tw-01.txt
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: <https://mailarchive.ietf.org/arch/browse/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, 07 Jul 2015 00:05:38 -0000

I submitted the following draft discussing screencasting applications
and proposing one technique to improve handling of anti-aliased text in
those applications.

Cheers,

	Jean-Marc

-------- Forwarded Message --------
Subject: New Version Notification for draft-valin-netvc-l1tw-01.txt
Date: Mon, 06 Jul 2015 16:57:57 -0700
From: internet-drafts@ietf.org
To: Jean-Marc Valin <jmvalin@jmvalin.ca>, Jean-Marc Valin
<jmvalin@jmvalin.ca>


A new version of I-D, draft-valin-netvc-l1tw-01.txt
has been successfully submitted by Jean-Marc Valin and posted to the
IETF repository.

Name:		draft-valin-netvc-l1tw
Revision:	01
Title:		Screencasting Considerations and L1-Tree Wavelet Coding
Document date:	2015-07-06
Group:		Individual Submission
Pages:		5
URL:
https://www.ietf.org/internet-drafts/draft-valin-netvc-l1tw-01.txt
Status:         https://datatracker.ietf.org/doc/draft-valin-netvc-l1tw/
Htmlized:       https://tools.ietf.org/html/draft-valin-netvc-l1tw-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-valin-netvc-l1tw-01

Abstract:
   This document proposes a screencasting encoding mode based on the
   Haar wavelet transform and L1-tree wavelet (L1TW) coding.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




From nobody Tue Jul  7 11:21:17 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 A1B921A1A76 for <video-codec@ietfa.amsl.com>; Tue,  7 Jul 2015 11:21:15 -0700 (PDT)
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 yZTenKdU9W3f for <video-codec@ietfa.amsl.com>; Tue,  7 Jul 2015 11:21:14 -0700 (PDT)
Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.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 C95DA1A1A6F for <video-codec@ietf.org>; Tue,  7 Jul 2015 11:21:03 -0700 (PDT)
Received: by pddu5 with SMTP id u5so42534033pdd.3 for <video-codec@ietf.org>; Tue, 07 Jul 2015 11:21:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=81kJ5p50yrSe+eLlClryI+1+nk3Alec9yszPM0EM6KI=; b=aOd7W+NmbuaLjQptyxbK4HyURzE6eYaBGOuOLFVfGcua9Ie+NsbpeNwal0gLzzh1FN KKgnof47WO8B+Kq8jjFfixLBRHXpu0mnjgKAFjIsJQq54sQavi/qSVPSqyRkWPHWF87b D9Nfrux3+gSen5v1Lsb6eUPtiCsP9IP2DGgpOhDSlt5kwbdcnTuUKEOpVKhALrkJKO/n 5UBtmEWGo0IbL8Qga5apOLnglzyW4AMDG1FFPBB9cvDIBNl/UJ9Dp55gEaPsXrquI5k+ vEks6VDYXkJXJBS3NBFso3rNgb2h0H9deJpHU+CcWnJihtMHEcr2bDow8jvdU26I4hGt IhpA==
X-Gm-Message-State: ALoCoQnFFFU/IZdOPObBAPZozlPJW+YNTwAZV3+hw/Wy3S9xiRNr8pMXvJspFnlos8CLuzjCwr4V
X-Received: by 10.70.43.72 with SMTP id u8mr11546582pdl.33.1436293263228; Tue, 07 Jul 2015 11:21:03 -0700 (PDT)
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 pp6sm22562582pbb.79.2015.07.07.11.21.01 for <video-codec@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jul 2015 11:21:01 -0700 (PDT)
To: "video-codec@ietf.org" <video-codec@ietf.org>
From: Thomas Daede <tdaede@mozilla.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <559C188B.8090604@mozilla.com>
Date: Tue, 7 Jul 2015 11:20:59 -0700
User-Agent: http://a.pomf.se/cszdno.opus
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/9cF5xO_syfSV6__HejCJUwDnzRk>
Subject: [video-codec] Interlacing support
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: <https://mailarchive.ietf.org/arch/browse/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, 07 Jul 2015 18:21:15 -0000

I don't think we should support interlacing in the netvc bitstream. I
bring this up because draft-filippov-netvc-requirements-01 still
specifies some interlaced modes.

Arguments against interlacing:
- Requires extra features to encode efficiently. HEVC has dropped MBAFF,
libvpx has never supported interlacing.
- Moves deinterlacer complexity to the encoder, which is an easier place
to offload complexity
- There are no internet-connected interlaced displays in common usage

If anyone has counterarguments, I'd like to hear them.


From nobody Tue Jul  7 11:29:39 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 2B85E1A1B15 for <video-codec@ietfa.amsl.com>; Tue,  7 Jul 2015 11:29:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.078
X-Spam-Level: 
X-Spam-Status: No, score=-4.078 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, 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 ar7MJmu7zYbl for <video-codec@ietfa.amsl.com>; Tue,  7 Jul 2015 11:29:36 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (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 53D951A0125 for <video-codec@ietf.org>; Tue,  7 Jul 2015 11:29:36 -0700 (PDT)
Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 11AF7C0346 for <video-codec@ietf.org>; Tue,  7 Jul 2015 18:29:36 +0000 (UTC)
X-Virus-Scanned: amavisd-new at mozilla.org
Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8W9sRB0zdO5 for <video-codec@ietf.org>; Tue,  7 Jul 2015 18:29:36 +0000 (UTC)
Received: from [10.252.28.57] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id F29B2BFFBB for <video-codec@ietf.org>; Tue,  7 Jul 2015 18:29:35 +0000 (UTC)
Message-ID: <559C1A8F.5060706@xiph.org>
Date: Tue, 07 Jul 2015 11:29:35 -0700
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" <video-codec@ietf.org>
References: <559C188B.8090604@mozilla.com>
In-Reply-To: <559C188B.8090604@mozilla.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/BcdGUeix1pltZ50padxicEM4yNg>
Subject: Re: [video-codec] Interlacing support
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: <https://mailarchive.ietf.org/arch/browse/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, 07 Jul 2015 18:29:38 -0000

Thomas Daede wrote:
> Arguments against interlacing:
> - Requires extra features to encode efficiently. HEVC has dropped MBAFF,
> libvpx has never supported interlacing.
> - Moves deinterlacer complexity to the encoder, which is an easier place
> to offload complexity
> - There are no internet-connected interlaced displays in common usage

I'll add one more: brings into play a large amount of additional IPR to 
avoid.


From nobody Tue Jul  7 11:43:08 2015
Return-Path: <Andrew.Krupiczka@espn.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 D98A01A1B85 for <video-codec@ietfa.amsl.com>; Tue,  7 Jul 2015 11:43:06 -0700 (PDT)
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 4-AoFyFylA0P for <video-codec@ietfa.amsl.com>; Tue,  7 Jul 2015 11:43:05 -0700 (PDT)
Received: from espn5.mailsec1.batblue.net (espn5.mailsec1.batblue.net [74.123.200.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531741A1B76 for <video-codec@ietf.org>; Tue,  7 Jul 2015 11:43:04 -0700 (PDT)
Received: from EXHUBP11C02V.corp.espn.pvt ([192.234.2.236]) by espn5.mailsec1.batblue.net (8.13.8/8.13.8) with ESMTP id t67Ih3u0022746; Tue, 7 Jul 2015 14:43:03 -0400
Received: from EXMDAGP11C01VC6.corp.espn.pvt ([169.254.6.85]) by EXHUBP11C02V.corp.espn.pvt ([10.75.64.205]) with mapi id 14.03.0210.002; Tue, 7 Jul 2015 14:42:28 -0400
From: "Krupiczka, Andrew" <Andrew.Krupiczka@espn.com>
To: "Timothy B. Terriberry" <tterribe@xiph.org>, "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: [video-codec] Interlacing support
Thread-Index: AQHQuOGlqlxw+o4QPk2oof+IDqZZk53QlwqA//+9k3A=
Date: Tue, 7 Jul 2015 18:43:02 +0000
Message-ID: <7E78635F75F78C41ADC5ADAAD658319324B01E14@EXMDAGP11C01VC6.corp.espn.pvt>
References: <559C188B.8090604@mozilla.com> <559C1A8F.5060706@xiph.org>
In-Reply-To: <559C1A8F.5060706@xiph.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.22.131.10]
x-exclaimer-md-config: 8a320cb5-50ce-4a00-b4e5-c5b1c6c1625e
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/q5ghAzAh-cZSGbhULEInn1LBLsQ>
Subject: Re: [video-codec] Interlacing support
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: <https://mailarchive.ietf.org/arch/browse/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, 07 Jul 2015 18:43:07 -0000

Hello everyone,
Yes, unlike H.264 the HEVC doesn't provide any encoding tools specific to t=
he interlaced format sourced content.
Not to say, the 1080i format is well alive and still very important for som=
e broadcasters and markets due to operational distribution infrastructure.
Even, if the interlaced format content is to be encoded it can always be de=
interlaced prior and as noted no need for re-interlacing it back for displa=
y devices.
Best regards,=20
Andrew

-----Original Message-----
From: video-codec [mailto:video-codec-bounces@ietf.org] On Behalf Of Timoth=
y B. Terriberry
Sent: Tuesday, July 07, 2015 2:30 PM
To: video-codec@ietf.org
Subject: Re: [video-codec] Interlacing support

Thomas Daede wrote:
> Arguments against interlacing:
> - Requires extra features to encode efficiently. HEVC has dropped=20
> MBAFF, libvpx has never supported interlacing.
> - Moves deinterlacer complexity to the encoder, which is an easier=20
> place to offload complexity
> - There are no internet-connected interlaced displays in common usage

I'll add one more: brings into play a large amount of additional IPR to avo=
id.

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


From nobody Tue Jul  7 14:00:21 2015
Return-Path: <mohammedsraad@raadtech.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 AD2BD1AC44B for <video-codec@ietfa.amsl.com>; Tue,  7 Jul 2015 14:00:20 -0700 (PDT)
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 cy-FTFYy4pFF for <video-codec@ietfa.amsl.com>; Tue,  7 Jul 2015 14:00:15 -0700 (PDT)
Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.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 8A0661AC3B1 for <video-codec@ietf.org>; Tue,  7 Jul 2015 14:00:15 -0700 (PDT)
Received: by wifm2 with SMTP id m2so71137734wif.1 for <video-codec@ietf.org>; Tue, 07 Jul 2015 14:00:14 -0700 (PDT)
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=M/Ut4vn3SLbhvHSBqEFSjpTWNafFbIl/Q9lcZbXH8+c=; b=dJSIWEdUassoL207mesUl7m9KOYS8eIS40J5DXO6Z9YthefiogWQoFGsftbhLdBrbV 1SoJo25Rk0VHa5j/mpP2A4lPCisyY8s/NLJS+tccfQQUdf7fsNOujn/nnkdorSNs2X3d pOcTe3m5+JGcRu/YseJB8MbD1LYV8JQvwSQkWeY+l6t9L6ztuw1DWEsX4wk9jbXeRm+r gX3pmVyi8BKw5zOi62w6M9w77QyOn+7lFbLjRohwM7Pv59atREEl3on9mjgUd8F5vPSk HSxnHSP9L8j8FowA3X8hx/ybELExTd14s8tQKf6EGUA0daxsG2G4IxhWPbX4LueJqFMC /lrQ==
X-Gm-Message-State: ALoCoQmfLBsRk3zC3bJ+OTjxuyoyjBIMttT0UXanXmZpqhoe4vs+dBxj9RfgQ3Y6GPUhl+Zlb/8D
MIME-Version: 1.0
X-Received: by 10.180.9.75 with SMTP id x11mr64185830wia.80.1436302814081; Tue, 07 Jul 2015 14:00:14 -0700 (PDT)
Received: by 10.194.243.106 with HTTP; Tue, 7 Jul 2015 14:00:13 -0700 (PDT)
Received: by 10.194.243.106 with HTTP; Tue, 7 Jul 2015 14:00:13 -0700 (PDT)
In-Reply-To: <559C1A8F.5060706@xiph.org>
References: <559C188B.8090604@mozilla.com> <559C1A8F.5060706@xiph.org>
Date: Tue, 7 Jul 2015 23:00:13 +0200
Message-ID: <CA+E6M0n=HnqU8XgPpKUxXzcqaZUoVsUwBpUCx5C=AZ+j1b-Rrg@mail.gmail.com>
From: Mohammed Raad <mohammedsraad@raadtech.com>
To: "Timothy B. Terriberry" <tterribe@xiph.org>
Content-Type: multipart/alternative; boundary=001a11c241360609e2051a4f4f5b
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/31MvbNEZD__WUm_HcWuIN4bwse4>
Cc: video-codec@ietf.org
Subject: Re: [video-codec] Interlacing support
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: <https://mailarchive.ietf.org/arch/browse/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, 07 Jul 2015 21:00:20 -0000

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

I agree, I don't see a reason for supporting interlace in future video
codecs.
On 7 Jul 2015 21:29, "Timothy B. Terriberry" <tterribe@xiph.org> wrote:

> Thomas Daede wrote:
>
>> Arguments against interlacing:
>> - Requires extra features to encode efficiently. HEVC has dropped MBAFF,
>> libvpx has never supported interlacing.
>> - Moves deinterlacer complexity to the encoder, which is an easier place
>> to offload complexity
>> - There are no internet-connected interlaced displays in common usage
>>
>
> I'll add one more: brings into play a large amount of additional IPR to
> avoid.
>
> _______________________________________________
> video-codec mailing list
> video-codec@ietf.org
> https://www.ietf.org/mailman/listinfo/video-codec
>

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

<p dir=3D"ltr">I agree, I don&#39;t see a reason for supporting interlace i=
n future video codecs.</p>
<div class=3D"gmail_quote">On 7 Jul 2015 21:29, &quot;Timothy B. Terriberry=
&quot; &lt;<a href=3D"mailto:tterribe@xiph.org">tterribe@xiph.org</a>&gt; w=
rote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thomas Daede w=
rote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Arguments against interlacing:<br>
- Requires extra features to encode efficiently. HEVC has dropped MBAFF,<br=
>
libvpx has never supported interlacing.<br>
- Moves deinterlacer complexity to the encoder, which is an easier place<br=
>
to offload complexity<br>
- There are no internet-connected interlaced displays in common usage<br>
</blockquote>
<br>
I&#39;ll add one more: brings into play a large amount of additional IPR to=
 avoid.<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" rel=3D"norefe=
rrer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/video-codec</=
a><br>
</blockquote></div>

--001a11c241360609e2051a4f4f5b--


From nobody Tue Jul  7 14:03: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 3E9741ACD32 for <video-codec@ietfa.amsl.com>; Tue,  7 Jul 2015 14:03:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.977
X-Spam-Level: 
X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, 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 VvTKRG2WGXxH for <video-codec@ietfa.amsl.com>; Tue,  7 Jul 2015 14:03:39 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.scl3.mozilla.com [63.245.214.156]) (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 1A72B1ACC8C for <video-codec@ietf.org>; Tue,  7 Jul 2015 14:03:39 -0700 (PDT)
Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id C377FC0521 for <video-codec@ietf.org>; Tue,  7 Jul 2015 21:03:38 +0000 (UTC)
X-Virus-Scanned: amavisd-new at mozilla.org
Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx2.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFWBpqzdkyf7 for <video-codec@ietf.org>; Tue,  7 Jul 2015 21:03:38 +0000 (UTC)
Received: from [10.252.28.57] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id B0A67BFF57 for <video-codec@ietf.org>; Tue,  7 Jul 2015 21:03:38 +0000 (UTC)
Message-ID: <559C3EAA.2060809@xiph.org>
Date: Tue, 07 Jul 2015 14:03:38 -0700
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" <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/LDN17_2PRtVSLxLA61QIAQyj1ww>
Subject: [video-codec] Minor comments on draft-fuldseth-netvc-thor-00
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: <https://mailarchive.ietf.org/arch/browse/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, 07 Jul 2015 21:03:40 -0000

In section 8.1.1, step 4, the calculations of c' and d' are supposed to 
use subtractions instead of additions, right?

A similar question applies to the calculation of c' in 8.2.1 step 3.

In Table 3 in Section 9.2.6, index 9 should code (run=2,level>1), right?


From nobody Tue Jul  7 14:55:56 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 9F18D1AD36E for <video-codec@ietfa.amsl.com>; Tue,  7 Jul 2015 14:55:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, 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 nasLftKhqzIx for <video-codec@ietfa.amsl.com>; Tue,  7 Jul 2015 14:55:50 -0700 (PDT)
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 832F41AD35B for <video-codec@ietf.org>; Tue,  7 Jul 2015 14:55:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3502; q=dns/txt; s=iport; t=1436306150; x=1437515750; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=v8yLTiDXj9NVQJynrYj/9qViGVCROCIeqN9G4XLU4qs=; b=K0hlCQZJyfBmkWgL9qM7V7naAtLTJExLEn0PT/GKQx+ii97Lj9eENQT/ qI+lI1dsjmETnemJjP8gpLWMIBZ0/KH3RAQ62q3FSr3TNN4jHIBE00xUE bx7upg/QhGgPRIX7pbW68+MYKvycAbgAmUAdw6fGK4P5cYc/iVDVghXvA A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CdAwCPSpxV/4kNJK1bgxJUYL1tCYFlAQmFdwKBZTgUAQEBAQEBAYEKhCQBAQQBAQFrCxACAQgEOwcnCxQRAgQOBYguDc0DAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLS4UCBAeDF4EUBZQYAYtomFomg3tvgksBAQE
X-IronPort-AV: E=Sophos;i="5.15,426,1432598400";  d="scan'208,217";a="166373037"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-8.cisco.com with ESMTP; 07 Jul 2015 21:55:49 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t67LtnaH017795 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Jul 2015 21:55:49 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.240]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Tue, 7 Jul 2015 16:55:49 -0500
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: Mohammed Raad <mohammedsraad@raadtech.com>
Thread-Topic: [video-codec] Interlacing support
Thread-Index: AQHQuPfzEQSvAgqQPUCb1DF1ggxWlJ3QjW7i
Date: Tue, 7 Jul 2015 21:55:49 +0000
Message-ID: <B0F23405-A043-414C-8174-FE8B239DF73A@cisco.com>
References: <559C188B.8090604@mozilla.com> <559C1A8F.5060706@xiph.org>, <CA+E6M0n=HnqU8XgPpKUxXzcqaZUoVsUwBpUCx5C=AZ+j1b-Rrg@mail.gmail.com>
In-Reply-To: <CA+E6M0n=HnqU8XgPpKUxXzcqaZUoVsUwBpUCx5C=AZ+j1b-Rrg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_B0F23405A043414C8174FE8B239DF73Aciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/GlZn_YklBKpW4yr8S8uGBPBodL8>
Cc: "video-codec@ietf.org" <video-codec@ietf.org>, "Timothy B. Terriberry" <tterribe@xiph.org>
Subject: Re: [video-codec] Interlacing support
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: <https://mailarchive.ietf.org/arch/browse/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, 07 Jul 2015 21:55:54 -0000

--_000_B0F23405A043414C8174FE8B239DF73Aciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

+1



On Jul 7, 2015, at 5:00 PM, Mohammed Raad <mohammedsraad@raadtech.com<mailt=
o:mohammedsraad@raadtech.com>> wrote:


I agree, I don't see a reason for supporting interlace in future video code=
cs.

On 7 Jul 2015 21:29, "Timothy B. Terriberry" <tterribe@xiph.org<mailto:tter=
ribe@xiph.org>> wrote:
Thomas Daede wrote:
Arguments against interlacing:
- Requires extra features to encode efficiently. HEVC has dropped MBAFF,
libvpx has never supported interlacing.
- Moves deinterlacer complexity to the encoder, which is an easier place
to offload complexity
- There are no internet-connected interlaced displays in common usage

I'll add one more: brings into play a large amount of additional IPR to avo=
id.

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

--_000_B0F23405A043414C8174FE8B239DF73Aciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body dir=3D"auto">
<div>&#43;1<br>
<br>
<br>
</div>
<div><br>
On Jul 7, 2015, at 5:00 PM, Mohammed Raad &lt;<a href=3D"mailto:mohammedsra=
ad@raadtech.com">mohammedsraad@raadtech.com</a>&gt; wrote:<br>
<br>
</div>
<div>
<p dir=3D"ltr">I agree, I don't see a reason for supporting interlace in fu=
ture video codecs.</p>
<div class=3D"gmail_quote">On 7 Jul 2015 21:29, &quot;Timothy B. Terriberry=
&quot; &lt;<a href=3D"mailto:tterribe@xiph.org">tterribe@xiph.org</a>&gt; w=
rote:<br type=3D"attribution">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Thomas Daede wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Arguments against interlacing:<br>
- Requires extra features to encode efficiently. HEVC has dropped MBAFF,<br=
>
libvpx has never supported interlacing.<br>
- Moves deinterlacer complexity to the encoder, which is an easier place<br=
>
to offload complexity<br>
- There are no internet-connected interlaced displays in common usage<br>
</blockquote>
<br>
I'll add one more: brings into play a large amount of additional IPR to avo=
id.<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" rel=3D"norefe=
rrer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/video-codec</=
a><br>
</blockquote>
</div>
</div>
<div><span>_______________________________________________</span><br>
<span>video-codec mailing list</span><br>
<span><a href=3D"mailto:video-codec@ietf.org">video-codec@ietf.org</a></spa=
n><br>
<span><a href=3D"https://www.ietf.org/mailman/listinfo/video-codec">https:/=
/www.ietf.org/mailman/listinfo/video-codec</a></span><br>
</div>
</body>
</html>

--_000_B0F23405A043414C8174FE8B239DF73Aciscocom_--


From nobody Tue Jul  7 23:24:11 2015
Return-Path: <Alexey.Filippov@huawei.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 5D93C1B3137 for <video-codec@ietfa.amsl.com>; Tue,  7 Jul 2015 23:24:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 ZwkrA-eMxulN for <video-codec@ietfa.amsl.com>; Tue,  7 Jul 2015 23:24:05 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C14C1B3135 for <video-codec@ietf.org>; Tue,  7 Jul 2015 23:24:04 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYM01540; Wed, 08 Jul 2015 06:24:03 +0000 (GMT)
Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 8 Jul 2015 07:24:01 +0100
Received: from SZXEMA508-MBS.china.huawei.com ([169.254.8.221]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0158.001; Wed, 8 Jul 2015 14:23:51 +0800
From: Filippov Alexey <Alexey.Filippov@huawei.com>
To: "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: [video-codec] Interlacing support
Thread-Index: AdC5RqbV7dM1CnH0TxSFdvLnVAQJ7Q==
Date: Wed, 8 Jul 2015 06:23:51 +0000
Message-ID: <A95DB243D3936149BBFA3B43ED710745705088DC@szxema508-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.198.51.238]
Content-Type: multipart/alternative; boundary="_000_A95DB243D3936149BBFA3B43ED710745705088DCszxema508mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/IA9kF2oyuGKktXa5vVixome678g>
Cc: Thomas Daede <tdaede@mozilla.com>
Subject: [video-codec]  Interlacing support
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: <https://mailarchive.ietf.org/arch/browse/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, 08 Jul 2015 06:24:09 -0000

--_000_A95DB243D3936149BBFA3B43ED710745705088DCszxema508mbschi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear Mr. Daede,

>I don't think we should support interlacing in the netvc bitstream. I brin=
g this up because draft-filippov-netvc-requirements-01 still specifies some=
 interlaced modes.
Sorry but your understanding of my document is incorrect. I included interl=
aced modes into the table titled "IPTV: typical values of resolutions, fram=
e-rates..." because these formats are actually used by different companies =
in practice. It is confirmed by Mr. Coppa from CBS in his comment ("a very =
typical format for the typical content types noted is 1080i at 59.94 fields=
 per second (29.97 frames per second) and I suggest that this be added to T=
able 1 as a typically delivered content type."). So, I guess it would be in=
correct to ignore a consumer request (I mean, for example, CBS that can pot=
entially decide to use a new netvc codec ) and exclude these formats from t=
he list of input sequences for testing a new codec. However, it doesn't mea=
n that a codec has to support tools like MBAFF or PAFF adopted for AVC/H.26=
4. I agree that a common way to avoid dealing with interlaced formats is to=
 use a deinterlacer before encoding. The main disadvantage of this approach=
 is blurring caused by applying a low-pass filter (deinterlacer) to an inte=
rlaced picture. So, it's necessary to show that deinterlacing before encodi=
ng is better than using specific tools inside the codec. If anyone has coun=
terarguments, I'd like to hear them.

--
Best regards,
Alexey Filippov

--_000_A95DB243D3936149BBFA3B43ED710745705088DCszxema508mbschi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-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;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
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]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Dear Mr. Daede,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">&gt;I don't think we should support interlacing in t=
he netvc bitstream. I bring this up because draft-filippov-netvc-requiremen=
ts-01 still specifies some interlaced modes.<o:p></o:p></p>
<p class=3D"MsoNormal">Sorry but your understanding of my document is incor=
rect. I included interlaced modes into the table titled &#8220;IPTV: typica=
l values of resolutions, frame-rates&#8230;&#8221; because these formats ar=
e actually used by different companies in practice.
 It is confirmed by Mr. Coppa from CBS in his comment (&#8220;a very&nbsp;t=
ypical&nbsp;format for the typical content types noted is 1080i at 59.94 fi=
elds per second (29.97 frames per second) and I suggest that this be added =
to Table 1 as a typically delivered content type.&#8221;).
 So, I guess it would be incorrect to ignore a consumer request (I mean, fo=
r example, CBS that can potentially decide to use a new netvc codec ) and e=
xclude these formats from the list of input sequences for testing a new cod=
ec. However, it doesn't mean that
 a codec has to support tools like MBAFF or PAFF adopted for AVC/H.264. I a=
gree that a common way to avoid dealing with interlaced formats is to use a=
 deinterlacer before encoding. The main disadvantage of this approach is bl=
urring caused by applying a low-pass
 filter (deinterlacer) to an interlaced picture. So, it's necessary to show=
 that deinterlacing before encoding is better than using specific tools ins=
ide the codec. If anyone has counterarguments, I'd like to hear them.<o:p><=
/o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">--<o:p></o:p></p>
<p class=3D"MsoNormal">Best regards,<o:p></o:p></p>
<p class=3D"MsoNormal">Alexey Filippov<o:p></o:p></p>
</div>
</body>
</html>

--_000_A95DB243D3936149BBFA3B43ED710745705088DCszxema508mbschi_--


From nobody Tue Jul  7 23:49:31 2015
Return-Path: <Alexey.Filippov@huawei.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 8A49D1B3171 for <video-codec@ietfa.amsl.com>; Tue,  7 Jul 2015 23:49:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 IFKjWmBxT0re for <video-codec@ietfa.amsl.com>; Tue,  7 Jul 2015 23:49:27 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C56B1B316E for <video-codec@ietf.org>; Tue,  7 Jul 2015 23:49:26 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUW03892; Wed, 08 Jul 2015 06:49:25 +0000 (GMT)
Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 8 Jul 2015 07:49:22 +0100
Received: from SZXEMA508-MBS.china.huawei.com ([169.254.8.221]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Wed, 8 Jul 2015 14:49:10 +0800
From: Filippov Alexey <Alexey.Filippov@huawei.com>
To: "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: [video-codec] Interlacing support
Thread-Index: AdC5SjBP+/9x3FRmRZ203T0b4EqunQ==
Date: Wed, 8 Jul 2015 06:49:09 +0000
Message-ID: <A95DB243D3936149BBFA3B43ED71074570508938@szxema508-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.198.51.238]
Content-Type: multipart/alternative; boundary="_000_A95DB243D3936149BBFA3B43ED71074570508938szxema508mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/Ok_amyY-AKSq2otgUTAYYFHgh5Y>
Cc: Thomas Daede <tdaede@mozilla.com>
Subject: [video-codec]  Interlacing support
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: <https://mailarchive.ietf.org/arch/browse/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, 08 Jul 2015 06:49:29 -0000

--_000_A95DB243D3936149BBFA3B43ED71074570508938szxema508mbschi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

By the way, the statement that HEVC/H.265 doesn't support interlaced video =
is incorrect. At the JCT-VC meeting in San Jose (February 2012), after disc=
ussing several possible approaches, it was decided that efficient compressi=
on of interlace video could be achieved by adding an SEI message to the spe=
cification without needing to change the basic design or coding tools of HE=
VC/H.265 [JCTVC-H0013]. An overview of interlaced video support in HEVC/H.2=
65 can be found in http://ngcodec.com/news/2014/1/15/does-hevch265-support-=
interlaced
So, including low-level tools into a codec is not the only way  of supporti=
ng interlaced video in bitstream.

--
Best regards,
Alexey Filippov

--_000_A95DB243D3936149BBFA3B43ED71074570508938szxema508mbschi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-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-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
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]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">By the way, the statement that HEVC/H.265 doesn&#821=
7;t support interlaced video is incorrect. At the JCT-VC meeting in San Jos=
e (February 2012), after discussing several possible approaches, it was dec=
ided that efficient compression of interlace
 video could be achieved by adding an SEI message to the specification with=
out needing to change the basic design or coding tools of HEVC/H.265 [JCTVC=
-H0013]. An overview of interlaced video support in HEVC/H.265 can be found=
 in
<a href=3D"http://ngcodec.com/news/2014/1/15/does-hevch265-support-interlac=
ed">http://ngcodec.com/news/2014/1/15/does-hevch265-support-interlaced</a>
<o:p></o:p></p>
<p class=3D"MsoNormal">So, including low-level tools into a codec is not th=
e only way &nbsp;of supporting interlaced video in bitstream.<o:p></o:p></p=
>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">--<o:p></o:p></p>
<p class=3D"MsoNormal">Best regards,<o:p></o:p></p>
<p class=3D"MsoNormal">Alexey Filippov<o:p></o:p></p>
</div>
</body>
</html>

--_000_A95DB243D3936149BBFA3B43ED71074570508938szxema508mbschi_--


From nobody Wed Jul  8 15:50:38 2015
Return-Path: <arilfuld@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 401CE1A879B for <video-codec@ietfa.amsl.com>; Wed,  8 Jul 2015 13:36:43 -0700 (PDT)
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 10HRc3-E5VJ0 for <video-codec@ietfa.amsl.com>; Wed,  8 Jul 2015 13:36:42 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 012401A879A for <video-codec@ietf.org>; Wed,  8 Jul 2015 13:36:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=772; q=dns/txt; s=iport; t=1436387802; x=1437597402; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=LKuEjtJPK5YkGEJxUESp16jZpTAC9SxMt+LPfXWqbRA=; b=I13nTxBQMplf3ZVYuKTml+a4XCi9Io7G8m8MexHjM7Y6WNow+NGWNjDx QcTcyMXG/dtgm7OLX4Yri+JKjyjpPMQDmMyrbcIkLv6DTHEfY/Fm0U8ef 5iMGSoTdz98MPGyCWZ1po0YNbDuw1yozP4sW+EgHJpGQn/M2DYsFqVSIE g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AABQCCiZ1V/5RdJa1bgxJUYAa9P4FlCoV3AoFdOhIBAQEBAQEBgQqEIwEBAQQBAQE3NBcEAgEIEQQBAQsUCQcnCxQJCAIEARIIiCYNziMBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItLhFU4BoMRgRQBBJQjAaRfJoN7b4FHgQQBAQE
X-IronPort-AV: E=Sophos;i="5.15,434,1432598400"; d="scan'208";a="166861629"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jul 2015 20:36:41 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t68KafA9029405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jul 2015 20:36:41 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.83]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Wed, 8 Jul 2015 15:36:41 -0500
From: "Arild Fuldseth (arilfuld)" <arilfuld@cisco.com>
To: "Timothy B. Terriberry" <tterribe@xiph.org>, "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: [video-codec] Minor comments on draft-fuldseth-netvc-thor-00
Thread-Index: AQHQuPhpsyAwiuUU1UuYiPuRb2BdX53SCXlA
Date: Wed, 8 Jul 2015 20:36:40 +0000
Message-ID: <D93780CEB41CE1419C1A7542E3096BC210FED1C8@xmb-aln-x08.cisco.com>
References: <559C3EAA.2060809@xiph.org>
In-Reply-To: <559C3EAA.2060809@xiph.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.84.80]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/LB9CKmbJCD3hj1cFjrRJlncCDcE>
X-Mailman-Approved-At: Wed, 08 Jul 2015 15:50:37 -0700
Subject: Re: [video-codec] Minor comments on draft-fuldseth-netvc-thor-00
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: <https://mailarchive.ietf.org/arch/browse/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, 08 Jul 2015 20:36:43 -0000

Tim,

Yes, you are right on all points.

Thank you for pointing that out.

Regards,

Arild

-----Original Message-----
From: video-codec [mailto:video-codec-bounces@ietf.org] On Behalf Of Timoth=
y B. Terriberry
Sent: 7. juli 2015 23:04
To: video-codec@ietf.org
Subject: [video-codec] Minor comments on draft-fuldseth-netvc-thor-00

In section 8.1.1, step 4, the calculations of c' and d' are supposed to use=
 subtractions instead of additions, right?

A similar question applies to the calculation of c' in 8.2.1 step 3.

In Table 3 in Section 9.2.6, index 9 should code (run=3D2,level>1), right?

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


From nobody Thu Jul  9 09:12:04 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 F18131B2AC6 for <video-codec@ietfa.amsl.com>; Thu,  9 Jul 2015 09:12:02 -0700 (PDT)
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 zPJFcqD9XfDh for <video-codec@ietfa.amsl.com>; Thu,  9 Jul 2015 09:12:01 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 534691B2AC2 for <video-codec@ietf.org>; Thu,  9 Jul 2015 09:12:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1295; q=dns/txt; s=iport; t=1436458321; x=1437667921; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=A5NZisPfxgih9brWgiAA9Nx5ndEffeMw95QuYMjBzlI=; b=cjkayT8VI1DSHIP0nW0sC4uhpTJhTJD42sqAdL77M5gElN8TKnF2tR1r Kx/eomvm1t284kDZ8Cwc99yGfA3xjS49dp+hjtguwnPvdsmOQ7+voW4LC OXmPbzBnZPmVGYCcx4UWxqNyGPRth7kVQvVcKoshU++m3RlYG8e1z1+vO U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BIBQAwnJ5V/5hdJa1bgxJUYAa7I4FnCoV3AoFZOhIBAQEBAQEBgQqEIwEBAQQBAQE3NBcEAgEIEQQBAR8JBycLFAkIAgQBEoguDc8SAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLS4UNBoQlBZQtAYt/mGcmg3tvgUeBBAEBAQ
X-IronPort-AV: E=Sophos;i="5.15,441,1432598400"; d="scan'208";a="166955234"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP; 09 Jul 2015 16:12:00 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t69GC0qt031581 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Jul 2015 16:12:00 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.240]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Thu, 9 Jul 2015 11:12:00 -0500
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: "Arild Fuldseth (arilfuld)" <arilfuld@cisco.com>, "Timothy B. Terriberry" <tterribe@xiph.org>, "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: [video-codec] Minor comments on draft-fuldseth-netvc-thor-00
Thread-Index: AQHQumH7/DlDmhQZ0k+oWtsAK88Lzw==
Date: Thu, 9 Jul 2015 16:11:59 +0000
Message-ID: <D1C40F34.514DA%mzanaty@cisco.com>
References: <559C3EAA.2060809@xiph.org> <D93780CEB41CE1419C1A7542E3096BC210FED1C8@xmb-aln-x08.cisco.com>
In-Reply-To: <D93780CEB41CE1419C1A7542E3096BC210FED1C8@xmb-aln-x08.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.2.150604
x-originating-ip: [64.100.32.216]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <DB84FB9A836A0440B80B48376AB761AB@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/SSZu3d14Yeh4M919XpJKEOAIe2c>
Subject: Re: [video-codec] Minor comments on draft-fuldseth-netvc-thor-00
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: <https://mailarchive.ietf.org/arch/browse/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, 09 Jul 2015 16:12:03 -0000

Another correction in section 9.2.6:
Table 3, Index=3D2 should show abs(coeff)=3D4 and level=3D4.
Figure 10, the last 0 should be removed.
All corrections will be updated in a new draft version once submission
reopens.

Mo

On 7/8/15, 4:36 PM, video-codec on behalf of Arild Fuldseth (arilfuld)
<video-codec-bounces@ietf.org on behalf of arilfuld@cisco.com> wrote:

Tim,

Yes, you are right on all points.

Thank you for pointing that out.

Regards,

Arild

-----Original Message-----
From: video-codec [mailto:video-codec-bounces@ietf.org] On Behalf Of
Timothy B. Terriberry
Sent: 7. juli 2015 23:04
To: video-codec@ietf.org
Subject: [video-codec] Minor comments on draft-fuldseth-netvc-thor-00

In section 8.1.1, step 4, the calculations of c' and d' are supposed to
use subtractions instead of additions, right?

A similar question applies to the calculation of c' in 8.2.1 step 3.

In Table 3 in Section 9.2.6, index 9 should code (run=3D2,level>1), right?

_______________________________________________
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 Fri Jul 10 11:50:41 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 D75971A1ADF for <video-codec@ietfa.amsl.com>; Fri, 10 Jul 2015 11:50:40 -0700 (PDT)
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 wwlu_GL4RE5t for <video-codec@ietfa.amsl.com>; Fri, 10 Jul 2015 11:50:37 -0700 (PDT)
Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) (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 D444B1A036F for <video-codec@ietf.org>; Fri, 10 Jul 2015 11:50:37 -0700 (PDT)
Received: by pdbqm3 with SMTP id qm3so44711608pdb.0 for <video-codec@ietf.org>; Fri, 10 Jul 2015 11:50:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=L9KiIDnQINWWwGssRsVA6nJUO7pFrOwPip1G4Lgxkso=; b=HEzDICXvZEDXbnk/HDWBCUMgI+kg20j9nM3Go/MqxDPHz5guq3RaL8wVG+Bp5x1RRG 6aOgJiaXLkOl5cx0tWMcRjmYZ2GL+wIfKp6YFTzZepU3jGcNyKnDs57lt5sYXu2WI4sJ pCQVRnahnE2oSfp8w9NPdRGkMKVejARuJh0R3i98VfGCE9qjLO6SA43nfM1F1P/dJUx+ E63Tl8U2Az4tGsPMqpcYpQMT/GH09r2a+jOkZoA8mio9nJaPHYlAujCipvprvl6x/P/A klPxR00IeF0G4tLDFHy7EmvN0bLe8FJq4SK6Qy5vBxindkOqH4V3/pDy56ZCSWTZse8x r2vQ==
X-Gm-Message-State: ALoCoQlZOm7vnOTsc5425qfu4rM0g7yyJE9g9afiXIJec7dRA/sxyMR4nOVc3JBa0OcjvAS0oB0M
X-Received: by 10.70.130.161 with SMTP id of1mr45036272pdb.31.1436554237386; Fri, 10 Jul 2015 11:50:37 -0700 (PDT)
Received: from ?IPv6:2620:101:80fc:232:bd05:d9d0:db6b:e094? ([2620:101:80fc:232:bd05:d9d0:db6b:e094]) by smtp.gmail.com with ESMTPSA id ry2sm9985367pbb.83.2015.07.10.11.50.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Jul 2015 11:50:36 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Yushin Cho <ycho@mozilla.com>
In-Reply-To: <D1C40F34.514DA%mzanaty@cisco.com>
Date: Fri, 10 Jul 2015 11:51:06 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <5724D873-9CE6-4DA3-9FC9-EFC44E06EF80@mozilla.com>
References: <559C3EAA.2060809@xiph.org> <D93780CEB41CE1419C1A7542E3096BC210FED1C8@xmb-aln-x08.cisco.com> <D1C40F34.514DA%mzanaty@cisco.com>
To: "Arild Fuldseth (arilfuld)" <arilfuld@cisco.com>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/jwzoX-y9UGvBjzSaEZlTKY2fSYA>
Cc: "video-codec@ietf.org" <video-codec@ietf.org>
Subject: Re: [video-codec] Minor comments on draft-fuldseth-netvc-thor-00
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 10 Jul 2015 18:50:41 -0000

More erratas found:

In 8.1.2.=20
Delocking =E2=80=94> Deblocking

In 9.2.5
is the sort =E2=80=94> is to sort



> On Jul 9, 2015, at 9:11 AM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> =
wrote:
>=20
> Another correction in section 9.2.6:
> Table 3, Index=3D2 should show abs(coeff)=3D4 and level=3D4.
> Figure 10, the last 0 should be removed.
> All corrections will be updated in a new draft version once submission
> reopens.
>=20
> Mo
>=20
> On 7/8/15, 4:36 PM, video-codec on behalf of Arild Fuldseth (arilfuld)
> <video-codec-bounces@ietf.org on behalf of arilfuld@cisco.com> wrote:
>=20
> Tim,
>=20
> Yes, you are right on all points.
>=20
> Thank you for pointing that out.
>=20
> Regards,
>=20
> Arild
>=20
> -----Original Message-----
> From: video-codec [mailto:video-codec-bounces@ietf.org] On Behalf Of
> Timothy B. Terriberry
> Sent: 7. juli 2015 23:04
> To: video-codec@ietf.org
> Subject: [video-codec] Minor comments on draft-fuldseth-netvc-thor-00
>=20
> In section 8.1.1, step 4, the calculations of c' and d' are supposed =
to
> use subtractions instead of additions, right?
>=20
> A similar question applies to the calculation of c' in 8.2.1 step 3.
>=20
> In Table 3 in Section 9.2.6, index 9 should code (run=3D2,level>1), =
right?
>=20
> _______________________________________________
> video-codec mailing list
> video-codec@ietf.org
> https://www.ietf.org/mailman/listinfo/video-codec
>=20
> _______________________________________________
> video-codec mailing list
> video-codec@ietf.org
> https://www.ietf.org/mailman/listinfo/video-codec
>=20
> _______________________________________________
> video-codec mailing list
> video-codec@ietf.org
> https://www.ietf.org/mailman/listinfo/video-codec


From nobody Fri Jul 10 12:01:04 2015
Return-Path: <jmvalin@jmvalin.ca>
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 4DF511A1ADF for <video-codec@ietfa.amsl.com>; Fri, 10 Jul 2015 12:01:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 E-0X3ftoFr3o for <video-codec@ietfa.amsl.com>; Fri, 10 Jul 2015 12:01:01 -0700 (PDT)
Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com [209.85.220.179]) (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 326341B2A84 for <video-codec@ietf.org>; Fri, 10 Jul 2015 12:00:52 -0700 (PDT)
Received: by qkhu186 with SMTP id u186so213229652qkh.0 for <video-codec@ietf.org>; Fri, 10 Jul 2015 12:00:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=dTtTXv37HqevccY/jNb/GQhAU6wOG0EdsFRx2wRHgsQ=; b=dW4dwLthn+YgGI7Ly1iHZHu/XaFbTd+/AsUrdiC/0/Gsk0jqFiv1FJzpfpxjhe0/kZ UAG+jS1rUValObH3tqatm8o/ZEjkc+JuVDBf+XYXq4hmqeOZ4OwtXFGDK3+5YWuKR4D8 iZVBvtq9qwiptbTjCREFxDDmCn4ElWw8Sj8NhUupWbheRiYYaXU4sGzqkDFQgJUvHfPu 10C2uBGZAWvq4LwJUOmcGsL5McgpnXF5EPEy8jOxvFNQEQMhB3Ng2kAO36clLGV1TXMU vUwy72kL5xcihsR4Z0sgPk6raXdiaD2J5N50SLSWQ3MYtccIzoGbl1QK/K4p31ABM+yE fHfw==
X-Gm-Message-State: ALoCoQm7cXW6SzWYFT+jr9irYryJnTnJkfnOar84PMMESn+yMrUAvLBeTwgW/Mm+spNkgK4W9m6p
X-Received: by 10.140.25.208 with SMTP id 74mr34301447qgt.104.1436554851450; Fri, 10 Jul 2015 12:00:51 -0700 (PDT)
Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by smtp.gmail.com with ESMTPSA id 20sm5926834qkz.30.2015.07.10.12.00.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jul 2015 12:00:50 -0700 (PDT)
To: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>, "Arild Fuldseth (arilfuld)" <arilfuld@cisco.com>, "Timothy B. Terriberry" <tterribe@xiph.org>, "video-codec@ietf.org" <video-codec@ietf.org>
References: <559C3EAA.2060809@xiph.org> <D93780CEB41CE1419C1A7542E3096BC210FED1C8@xmb-aln-x08.cisco.com> <D1C40F34.514DA%mzanaty@cisco.com>
From: Jean-Marc Valin <jmvalin@jmvalin.ca>
Message-ID: <55A01661.309@jmvalin.ca>
Date: Fri, 10 Jul 2015 15:00:49 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <D1C40F34.514DA%mzanaty@cisco.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/Dt1EqkEnZOVLZEoVHVIPLVvLU8k>
Subject: Re: [video-codec] Minor comments on draft-fuldseth-netvc-thor-00
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 10 Jul 2015 19:01:03 -0000

I see in section 4 that there are only 8 intra modes including DC,
rather than 9. I didn't understand why "upright" is missing, nor what
"The upright and upleft directions are exactly 45 degrees" means in that
context. Can you explain?

Cheers,

	Jean-Marc


On 07/09/2015 12:11 PM, Mo Zanaty (mzanaty) wrote:
> Another correction in section 9.2.6:
> Table 3, Index=2 should show abs(coeff)=4 and level=4.
> Figure 10, the last 0 should be removed.
> All corrections will be updated in a new draft version once submission
> reopens.
> 
> Mo
> 
> On 7/8/15, 4:36 PM, video-codec on behalf of Arild Fuldseth (arilfuld)
> <video-codec-bounces@ietf.org on behalf of arilfuld@cisco.com> wrote:
> 
> Tim,
> 
> Yes, you are right on all points.
> 
> Thank you for pointing that out.
> 
> Regards,
> 
> Arild
> 
> -----Original Message-----
> From: video-codec [mailto:video-codec-bounces@ietf.org] On Behalf Of
> Timothy B. Terriberry
> Sent: 7. juli 2015 23:04
> To: video-codec@ietf.org
> Subject: [video-codec] Minor comments on draft-fuldseth-netvc-thor-00
> 
> In section 8.1.1, step 4, the calculations of c' and d' are supposed to
> use subtractions instead of additions, right?
> 
> A similar question applies to the calculation of c' in 8.2.1 step 3.
> 
> In Table 3 in Section 9.2.6, index 9 should code (run=2,level>1), right?
> 
> _______________________________________________
> 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 Sat Jul 11 09:53:10 2015
Return-Path: <arilfuld@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 635731A902F for <video-codec@ietfa.amsl.com>; Sat, 11 Jul 2015 09:53:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.811
X-Spam-Level: 
X-Spam-Status: No, score=-11.811 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 MEO1PTclIjwL for <video-codec@ietfa.amsl.com>; Sat, 11 Jul 2015 09:53:07 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 046621A902E for <video-codec@ietf.org>; Sat, 11 Jul 2015 09:53:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2800; q=dns/txt; s=iport; t=1436633587; x=1437843187; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=undPRBBuFN8jPms8mYwKvye0L6dMKnWkTm0fcTN+zzk=; b=GhalNV/UHX1DEpZSwumdzdpMWrvGljM88ry85GfxQCjB8Ez15UCS24DL pDZsgSbUsphq3F3iaHc18idtMDX5EcOGJdsKB07g7PoXHVODFfo6cbr1d uP1YTIdG6IDApsBhnMqyecebqj1l09aVO4jIIiBS5eH1On/S70aN2/09O w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ByBQAWSaFV/4QNJK1bgxRUaQaDHLoECoV3AhyBCTwQAQEBAQEBAYEKhCMBAQEDAQEBASAROgsFBwQCAQgOAwQBAQECAgYdAwICAiULFAEICAIEDgUIiB4IDbhvlXsBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEiiiqEVTEHBoJiL4EUBZQxAaRuJoN7b4FHgQQBAQE
X-IronPort-AV: E=Sophos;i="5.15,454,1432598400"; d="scan'208";a="167794494"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Jul 2015 16:53:06 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t6BGr6GM017366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 11 Jul 2015 16:53:06 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.83]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Sat, 11 Jul 2015 11:53:06 -0500
From: "Arild Fuldseth (arilfuld)" <arilfuld@cisco.com>
To: Yushin Cho <ycho@mozilla.com>
Thread-Topic: [video-codec] Minor comments on draft-fuldseth-netvc-thor-00
Thread-Index: AQHQuPhpsyAwiuUU1UuYiPuRb2BdX53SCXlAgAGcX4CAAb7JAIABHVGA
Date: Sat, 11 Jul 2015 16:53:05 +0000
Message-ID: <D93780CEB41CE1419C1A7542E3096BC210FED306@xmb-aln-x08.cisco.com>
References: <559C3EAA.2060809@xiph.org> <D93780CEB41CE1419C1A7542E3096BC210FED1C8@xmb-aln-x08.cisco.com> <D1C40F34.514DA%mzanaty@cisco.com> <5724D873-9CE6-4DA3-9FC9-EFC44E06EF80@mozilla.com>
In-Reply-To: <5724D873-9CE6-4DA3-9FC9-EFC44E06EF80@mozilla.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.70.173]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/0W-rahvolTXFUU_LGs8O9Y2AjjY>
Cc: "video-codec@ietf.org" <video-codec@ietf.org>
Subject: Re: [video-codec] Minor comments on draft-fuldseth-netvc-thor-00
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 11 Jul 2015 16:53:08 -0000

RGVhciBZdXNoaW4sDQoNClRoYW5rIHlvdSBmb3IgcG9pbnRpbmcgb3V0IHRoZXNlIHR5cG9zLg0K
DQpSZWdhcmRzLA0KDQpBcmlsZA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog
WXVzaGluIENobyBbbWFpbHRvOnljaG9AbW96aWxsYS5jb21dIA0KU2VudDogMTAuIGp1bGkgMjAx
NSAyMDo1MQ0KVG86IEFyaWxkIEZ1bGRzZXRoIChhcmlsZnVsZCkNCkNjOiB2aWRlby1jb2RlY0Bp
ZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2aWRlby1jb2RlY10gTWlub3IgY29tbWVudHMgb24gZHJh
ZnQtZnVsZHNldGgtbmV0dmMtdGhvci0wMA0KDQpNb3JlIGVycmF0YXMgZm91bmQ6DQoNCkluIDgu
MS4yLiANCkRlbG9ja2luZyDigJQ+IERlYmxvY2tpbmcNCg0KSW4gOS4yLjUNCmlzIHRoZSBzb3J0
IOKAlD4gaXMgdG8gc29ydA0KDQoNCg0KPiBPbiBKdWwgOSwgMjAxNSwgYXQgOToxMSBBTSwgTW8g
WmFuYXR5IChtemFuYXR5KSA8bXphbmF0eUBjaXNjby5jb20+IHdyb3RlOg0KPiANCj4gQW5vdGhl
ciBjb3JyZWN0aW9uIGluIHNlY3Rpb24gOS4yLjY6DQo+IFRhYmxlIDMsIEluZGV4PTIgc2hvdWxk
IHNob3cgYWJzKGNvZWZmKT00IGFuZCBsZXZlbD00Lg0KPiBGaWd1cmUgMTAsIHRoZSBsYXN0IDAg
c2hvdWxkIGJlIHJlbW92ZWQuDQo+IEFsbCBjb3JyZWN0aW9ucyB3aWxsIGJlIHVwZGF0ZWQgaW4g
YSBuZXcgZHJhZnQgdmVyc2lvbiBvbmNlIHN1Ym1pc3Npb24gDQo+IHJlb3BlbnMuDQo+IA0KPiBN
bw0KPiANCj4gT24gNy84LzE1LCA0OjM2IFBNLCB2aWRlby1jb2RlYyBvbiBiZWhhbGYgb2YgQXJp
bGQgRnVsZHNldGggKGFyaWxmdWxkKSANCj4gPHZpZGVvLWNvZGVjLWJvdW5jZXNAaWV0Zi5vcmcg
b24gYmVoYWxmIG9mIGFyaWxmdWxkQGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPiBUaW0sDQo+IA0K
PiBZZXMsIHlvdSBhcmUgcmlnaHQgb24gYWxsIHBvaW50cy4NCj4gDQo+IFRoYW5rIHlvdSBmb3Ig
cG9pbnRpbmcgdGhhdCBvdXQuDQo+IA0KPiBSZWdhcmRzLA0KPiANCj4gQXJpbGQNCj4gDQo+IC0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHZpZGVvLWNvZGVjIFttYWlsdG86dmlk
ZW8tY29kZWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIA0KPiBUaW1vdGh5IEIuIFRl
cnJpYmVycnkNCj4gU2VudDogNy4ganVsaSAyMDE1IDIzOjA0DQo+IFRvOiB2aWRlby1jb2RlY0Bp
ZXRmLm9yZw0KPiBTdWJqZWN0OiBbdmlkZW8tY29kZWNdIE1pbm9yIGNvbW1lbnRzIG9uIGRyYWZ0
LWZ1bGRzZXRoLW5ldHZjLXRob3ItMDANCj4gDQo+IEluIHNlY3Rpb24gOC4xLjEsIHN0ZXAgNCwg
dGhlIGNhbGN1bGF0aW9ucyBvZiBjJyBhbmQgZCcgYXJlIHN1cHBvc2VkIA0KPiB0byB1c2Ugc3Vi
dHJhY3Rpb25zIGluc3RlYWQgb2YgYWRkaXRpb25zLCByaWdodD8NCj4gDQo+IEEgc2ltaWxhciBx
dWVzdGlvbiBhcHBsaWVzIHRvIHRoZSBjYWxjdWxhdGlvbiBvZiBjJyBpbiA4LjIuMSBzdGVwIDMu
DQo+IA0KPiBJbiBUYWJsZSAzIGluIFNlY3Rpb24gOS4yLjYsIGluZGV4IDkgc2hvdWxkIGNvZGUg
KHJ1bj0yLGxldmVsPjEpLCByaWdodD8NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQo+IHZpZGVvLWNvZGVjIG1haWxpbmcgbGlzdA0KPiB2aWRl
by1jb2RlY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L3ZpZGVvLWNvZGVjDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KPiB2aWRlby1jb2RlYyBtYWlsaW5nIGxpc3QNCj4gdmlkZW8tY29kZWNAaWV0
Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92aWRlby1jb2Rl
Yw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Cj4gdmlkZW8tY29kZWMgbWFpbGluZyBsaXN0DQo+IHZpZGVvLWNvZGVjQGlldGYub3JnDQo+IGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdmlkZW8tY29kZWMNCg0K


From nobody Sat Jul 11 09:56:44 2015
Return-Path: <arilfuld@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 5366D1A9039 for <video-codec@ietfa.amsl.com>; Sat, 11 Jul 2015 09:56:43 -0700 (PDT)
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 w4SK0jyXmEA0 for <video-codec@ietfa.amsl.com>; Sat, 11 Jul 2015 09:56:42 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE3371A9037 for <video-codec@ietf.org>; Sat, 11 Jul 2015 09:56:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2496; q=dns/txt; s=iport; t=1436633802; x=1437843402; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ZBWIEJlIMgcF2618acULnX0ZdRrVsyNzkil44hOtGDA=; b=lSJ9rid9odeibgnEpUNK3MjQo4mo7cQvoedZNJfVeyQnj5v6TJn2P0kM qCqtr+2KVRNgBTefor7kz9momXEY+0pKjaXvqSRFNtBkpmPXcb2xkv/5x ZujM8hHbkz/nYCrhmqEsWjozfQFJmPLQ67RH5cSIeeRzG7Byd+YGsp2n9 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BIBQDtSaFV/51dJa1bgxRUaQa9IAqFdwKBJTwQAQEBAQEBAYEKhCMBAQEEAQEBNzICCA8EAgEIEQQBAQEKFAkHJwsUCQgCBAESCIgmDc5rAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLTIQuJzgGgxGBFAWUMQGNQocnkAUmg3tvgQVCgQQBAQE
X-IronPort-AV: E=Sophos;i="5.15,454,1432598400"; d="scan'208";a="14593480"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 11 Jul 2015 16:56:41 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t6BGuffM007496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 11 Jul 2015 16:56:41 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.83]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Sat, 11 Jul 2015 11:56:40 -0500
From: "Arild Fuldseth (arilfuld)" <arilfuld@cisco.com>
To: Jean-Marc Valin <jmvalin@jmvalin.ca>, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>, "Timothy B. Terriberry" <tterribe@xiph.org>, "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: [video-codec] Minor comments on draft-fuldseth-netvc-thor-00
Thread-Index: AQHQuPhpsyAwiuUU1UuYiPuRb2BdX53SCXlAgAGcX4CAAcGAgIABGwNw
Date: Sat, 11 Jul 2015 16:56:40 +0000
Message-ID: <D93780CEB41CE1419C1A7542E3096BC210FED317@xmb-aln-x08.cisco.com>
References: <559C3EAA.2060809@xiph.org> <D93780CEB41CE1419C1A7542E3096BC210FED1C8@xmb-aln-x08.cisco.com> <D1C40F34.514DA%mzanaty@cisco.com> <55A01661.309@jmvalin.ca>
In-Reply-To: <55A01661.309@jmvalin.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.70.173]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/wArgwAb8XiQ-yUD2a6vqP80yt0g>
Subject: Re: [video-codec] Minor comments on draft-fuldseth-netvc-thor-00
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 11 Jul 2015 16:56:43 -0000

For the time being, we have decided to limit the number of intra prediction=
 modes to 8. In our simulations, the upright mode provides less coding gain=
 than the other 8 modes. The quote is a typo. It should read:

 "The upleft direction is exactly 45 degrees"

Regards,

Arild

-----Original Message-----
From: Jean-Marc Valin [mailto:jmvalin@jmvalin.ca]=20
Sent: 10. juli 2015 21:01
To: Mo Zanaty (mzanaty); Arild Fuldseth (arilfuld); Timothy B. Terriberry; =
video-codec@ietf.org
Subject: Re: [video-codec] Minor comments on draft-fuldseth-netvc-thor-00

I see in section 4 that there are only 8 intra modes including DC, rather t=
han 9. I didn't understand why "upright" is missing, nor what "The upright =
and upleft directions are exactly 45 degrees" means in that context. Can yo=
u explain?

Cheers,

	Jean-Marc


On 07/09/2015 12:11 PM, Mo Zanaty (mzanaty) wrote:
> Another correction in section 9.2.6:
> Table 3, Index=3D2 should show abs(coeff)=3D4 and level=3D4.
> Figure 10, the last 0 should be removed.
> All corrections will be updated in a new draft version once submission=20
> reopens.
>=20
> Mo
>=20
> On 7/8/15, 4:36 PM, video-codec on behalf of Arild Fuldseth (arilfuld)=20
> <video-codec-bounces@ietf.org on behalf of arilfuld@cisco.com> wrote:
>=20
> Tim,
>=20
> Yes, you are right on all points.
>=20
> Thank you for pointing that out.
>=20
> Regards,
>=20
> Arild
>=20
> -----Original Message-----
> From: video-codec [mailto:video-codec-bounces@ietf.org] On Behalf Of=20
> Timothy B. Terriberry
> Sent: 7. juli 2015 23:04
> To: video-codec@ietf.org
> Subject: [video-codec] Minor comments on draft-fuldseth-netvc-thor-00
>=20
> In section 8.1.1, step 4, the calculations of c' and d' are supposed=20
> to use subtractions instead of additions, right?
>=20
> A similar question applies to the calculation of c' in 8.2.1 step 3.
>=20
> In Table 3 in Section 9.2.6, index 9 should code (run=3D2,level>1), right=
?
>=20
> _______________________________________________
> video-codec mailing list
> video-codec@ietf.org
> https://www.ietf.org/mailman/listinfo/video-codec
>=20
> _______________________________________________
> video-codec mailing list
> video-codec@ietf.org
> https://www.ietf.org/mailman/listinfo/video-codec
>=20
> _______________________________________________
> video-codec mailing list
> video-codec@ietf.org
> https://www.ietf.org/mailman/listinfo/video-codec
>=20


From nobody Mon Jul 13 14:35:49 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 B5FE61A03A2 for <video-codec@ietfa.amsl.com>; Mon, 13 Jul 2015 14:35:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.201
X-Spam-Level: 
X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 rBNAS2tvVFHK for <video-codec@ietfa.amsl.com>; Mon, 13 Jul 2015 14:35:45 -0700 (PDT)
Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (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 AFC991A015F for <video-codec@ietf.org>; Mon, 13 Jul 2015 14:35:45 -0700 (PDT)
Received: by padck2 with SMTP id ck2so48877473pad.0 for <video-codec@ietf.org>; Mon, 13 Jul 2015 14:35:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=17O1t5va1vvknThPwuljmRkSFNLqUKu1wSVHXE8XiII=; b=eWz+2LSjo3K9zT3bW/IbLrxhHjl1VHFuj0oc8d4pK747NBo9V7UnjGELQwLsEfK8+M MCtRa1YK4lt/yQKGiOPA0kvvWs45pke9Jfms9irUTu8brJCNqlsgWkABRCryL+RDTWRx rzzmF8y+1WU6bMxDUTVkaFlp74dIl2cB7AShHrJTjMwn1friWYN0c++zqVqyKLA9potm REVMqTLTr962rLDh/aEHrcIdPKbY3gI6dNRdDRr8+sQdY+CVLOWiB7Eq9fQ/onHFjxpH h9leOjL8GzrIKmGiko1bdIuIw+nWzewzod5vC94Z4k6eBqoQejosIRCq9Sm0AYGgRmQ8 JRzw==
X-Gm-Message-State: ALoCoQmXWYCdlkOrj1D824Y3Lxelgq6ZezaE0u6VTqz36i9y78I1zCTOUdsP0aMp/6jQL3S+sblS
X-Received: by 10.66.156.68 with SMTP id wc4mr73280681pab.126.1436823345256; Mon, 13 Jul 2015 14:35:45 -0700 (PDT)
Received: from ?IPv6:2620:101:80fc:224:7e7a:91ff:fe9e:8126? ([2620:101:80fc:224:7e7a:91ff:fe9e:8126]) by smtp.gmail.com with ESMTPSA id d7sm19503279pbu.41.2015.07.13.14.35.43 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Jul 2015 14:35:44 -0700 (PDT)
To: Filippov Alexey <Alexey.Filippov@huawei.com>, "video-codec@ietf.org" <video-codec@ietf.org>
References: <A95DB243D3936149BBFA3B43ED710745705088DC@szxema508-mbs.china.huawei.com>
From: Thomas Daede <tdaede@mozilla.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <55A42F2D.30008@mozilla.com>
Date: Mon, 13 Jul 2015 14:35:41 -0700
User-Agent: http://a.pomf.se/cszdno.opus
MIME-Version: 1.0
In-Reply-To: <A95DB243D3936149BBFA3B43ED710745705088DC@szxema508-mbs.china.huawei.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/zDxrg9YM5rvMl1K87z6FNcrqelg>
Subject: Re: [video-codec] Interlacing support
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: <https://mailarchive.ietf.org/arch/browse/video-codec/>
List-Post: <mailto:video-codec@ietf.org>
List-Help: <mailto:video-codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/video-codec>, <mailto:video-codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jul 2015 21:35:48 -0000

On 07/07/2015 11:23 PM, Filippov Alexey wrote:
> I agree that a common way to avoid dealing with interlaced formats is to
> use a deinterlacer before encoding. The main disadvantage of this
> approach is blurring caused by applying a low-pass filter (deinterlacer)
> to an interlaced picture. So, it's necessary to show that deinterlacing
> before encoding is better than using specific tools inside the codec. If
> anyone has counterarguments, I'd like to hear them.

Any blurring caused by the deinterlacer will also happen if the video is
encoded interlaced, it will just happen on the decoder side instead.

I agree that we should test this. We also need a way to compare the
quality of the two methods. Here is my suggested test:

original video -> deinterlacer
original video -> x265 -> deinterlacer
original video -> deinterlacer -> x265

All three will result in progressive output that can be compared with
standard metrics.


From nobody Mon Jul 20 02:13:30 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 03FB71A014C for <video-codec@ietfa.amsl.com>; Mon, 20 Jul 2015 02:13:29 -0700 (PDT)
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 kt8yCTpEnJoi for <video-codec@ietfa.amsl.com>; Mon, 20 Jul 2015 02:13:27 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B141A0123 for <video-codec@ietf.org>; Mon, 20 Jul 2015 02:13:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=198; q=dns/txt; s=iport; t=1437383596; x=1438593196; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=jOtqrHLertguKaf2u5c7PGOHnAJExj+4MJvB6EVwRdc=; b=PezqawuRLbtHtHriQQUkix4MmhE4B0MsgiWDdoo8gVmAokJwNysFyyxo Yt+15MPf4FQPAnoRZx0CoZdabl6vtPv75wwde0KjHPeGS7LSl6GvBNEWx amcx0AwafQYZvfwFJF5HXVaEabzkzpi9UG3Tgp0ittpDDDsULChvdNBoK s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ArAwCSuqxV/4MNJK1cgxOBQ7tkCYdigTA4FAEBAQEBAQGBCoQqOlEBPkInBIhBn26lJwEBCAIglQQFlFIBjCCZByaDfII2gQQBAQE
X-IronPort-AV: E=Sophos;i="5.15,507,1432598400"; d="scan'208";a="170396141"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP; 20 Jul 2015 09:13:15 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t6K9DFMb008307 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <video-codec@ietf.org>; Mon, 20 Jul 2015 09:13:15 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.42]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Mon, 20 Jul 2015 04:13:15 -0500
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: Note takers and jabber scribe
Thread-Index: AQHQwsxPHDlY6ID6HkSBRCx41o/NBg==
Date: Mon, 20 Jul 2015 09:13:14 +0000
Message-ID: <D1D23346.51D2B%mzanaty@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.2.150604
x-originating-ip: [64.100.32.216]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <E0FE8543586542478FD936D6F2F51494@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/6GQdYenNx9haAf0kqGPuABPUat4>
Subject: [video-codec] Note takers and jabber scribe
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: <https://mailarchive.ietf.org/arch/browse/video-codec/>
List-Post: <mailto:video-codec@ietf.org>
List-Help: <mailto:video-codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/video-codec>, <mailto:video-codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jul 2015 09:13:29 -0000

In preparation for today's meeting, the chairs would like to request any
volunteers for note takers and a jabber scribe, so we don't have to
"volunteer" you during the meeting. :)

Thanks,
Mo


From nobody Mon Jul 20 05:41:49 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 EB2E21A7D82 for <video-codec@ietfa.amsl.com>; Mon, 20 Jul 2015 05:41:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 O4pgeBRx-qD0 for <video-codec@ietfa.amsl.com>; Mon, 20 Jul 2015 05:41:47 -0700 (PDT)
Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 09F8C1A6EDA for <video-codec@ietf.org>; Mon, 20 Jul 2015 05:41:47 -0700 (PDT)
Received: by igbpg9 with SMTP id pg9so80291759igb.0 for <video-codec@ietf.org>; Mon, 20 Jul 2015 05:41:46 -0700 (PDT)
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=2QakBGeV4UYzdVDCIgPM9fwvqL/pIdRpcQMcBdDYYdo=; b=l51JHBCTsVDyb34zRy8Lfyh+pIOCtXDAElO08nHZq88qmIRk854s5CaappqWnMPKt9 43/BNi6ChkiUxAI65AwHna0s6ZY0fUOkLoyipFmtE1bON5X5xUDy24MG1EyG3Q4MDdnR W02PWdwR6ABSBHjtLmpARd7XFNX2AJpmUkGzZaYlIRFrPZrokZy2OP7zM4sKIC34YHht gz709GEnOXh6EE/FM6IG6xbPjwk0hLv3T1IV0K5xXjWXkjCU/Nbw9zKIONLcjuuJt9cM Q6s/eDrdVlzPjwos1HZmyYJ5ccoPX2xh+UzF6arH29q/Wy0BS+oo8LVjqOLp4OzBm5L9 QrDA==
MIME-Version: 1.0
X-Received: by 10.50.8.68 with SMTP id p4mr14915853iga.4.1437396106488; Mon, 20 Jul 2015 05:41:46 -0700 (PDT)
Sender: metajack@gmail.com
Received: by 10.79.65.88 with HTTP; Mon, 20 Jul 2015 05:41:46 -0700 (PDT)
Date: Mon, 20 Jul 2015 06:41:46 -0600
X-Google-Sender-Auth: zdhyc7A1tD5CGZDxZ38z9Rbgw1Y
Message-ID: <CAP7VpsWawtVUNHUwgNqf0ESBhurXRBHcS2LR-Huir-JQrBHisg@mail.gmail.com>
From: Jack Moffitt <jack@metajack.im>
To: "video-codec@ietf.org" <video-codec@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/u9_xAf4U-Fg3Smsfmo0bGJJUeBs>
Subject: [video-codec] missing rounding behavior in draft-fuldseth-netvc-thor
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: <https://mailarchive.ietf.org/arch/browse/video-codec/>
List-Post: <mailto:video-codec@ietf.org>
List-Help: <mailto:video-codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/video-codec>, <mailto:video-codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jul 2015 12:41:48 -0000

In section 8.2 on the constrained lowpass filter, the delta is computed with

Delta = max(-1,min(1,(A+B+C+D-4X+2)>>2))

but the Thor code uses a slightly more complex calculation. The draft
should probably be updated to match the code.

jack.


From nobody Tue Jul 21 04:11:55 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 583D31A0024 for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 04:11:54 -0700 (PDT)
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 Iusa2lGLD2wB for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 04:11:52 -0700 (PDT)
Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (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 8FFD01A004C for <video-codec@ietf.org>; Tue, 21 Jul 2015 04:11:52 -0700 (PDT)
Received: by wibud3 with SMTP id ud3so123858143wib.0 for <video-codec@ietf.org>; Tue, 21 Jul 2015 04:11:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=8zZbZKr/tDyMhUG8E/nBic2J3vD6dcj4e0MXR82O9D4=; b=FQl8LpUNpWaom+1gq47OuBfz0IWUN7uSapQ+xhOhN8NL78bxj8S5oJNQ8t3JfhCOcs mQgHSjaWDJ7frhcals96gAIg0jp4Lfwd2rmKNCc8NVDtCp5eDmjMq7skWO4D2cEUnanj EgwvjzVMcZLdm1L4VKte9QkY2XC5zMY1RvOF4xHdoVrGFn1m7EZjz3r5X5RU5DGEQ7/v hd9twaG7pnEPK25eDbWt5n69OTIsSq3ssHA7F5BbzV8nTo3be/ajdR4r+mytRd7iwWhD 9XvZazTh7YzTxQn7nNA2Z+dqrS/qWP46djXbasb1T2Y0e7UuGPNTPTQ3VyQ/g/xOnCPe sdLw==
X-Gm-Message-State: ALoCoQmEupdiA5FuONRI0BZ81/2B/0uk8ovppzur2tLX+sShyFvnINNkyzIuNpcMO4k6fyht3bvL
X-Received: by 10.180.83.137 with SMTP id q9mr31960027wiy.68.1437477111172; Tue, 21 Jul 2015 04:11:51 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:168:7e7a:91ff:fe9e:8126? ([2001:67c:370:168:7e7a:91ff:fe9e:8126]) by smtp.gmail.com with ESMTPSA id ex8sm36477661wjc.34.2015.07.21.04.11.50 for <video-codec@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jul 2015 04:11:50 -0700 (PDT)
To: "video-codec@ietf.org" <video-codec@ietf.org>
From: Thomas Daede <tdaede@mozilla.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <55AE28F6.6070100@mozilla.com>
Date: Tue, 21 Jul 2015 13:11:50 +0200
User-Agent: http://a.pomf.se/cszdno.opus
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/M5HU70idkjeLOq4CXHJ-l1c3svU>
Subject: [video-codec] Low-latency rate control constraints
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Jul 2015 11:11:54 -0000

At the Monday NETVC session, it was suggested that CBR mode with a fixed
buffer size was not a very good representation of what rate control for
video conferencing would do.

Are there suggestions of a better model? Keep in mind that this is only
for relatively short (~15s) clips.

Another option is just to not specify CBR bounds, so that this test
would be like the high latency test but with lookahead and 2 pass
constraints.


From nobody Tue Jul 21 07:22:53 2015
Return-Path: <abegen@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 188C61B2E50 for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 07:22:47 -0700 (PDT)
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 InZl7EaEMFsA for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 07:22:40 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16171B2E6E for <video-codec@ietf.org>; Tue, 21 Jul 2015 07:22:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1262; q=dns/txt; s=iport; t=1437488560; x=1438698160; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=4VEDp3z3a4vJ4fRUNjdlIZxcLi45jQzfrVpVUpvVIOc=; b=akCQF21Xk5fN/wyZsjrBcYT+Ar0gdq4fpLCQ/gjetO0fkIuGCvgXi53+ T0msUzlkn6XPurH/4thTWT76IRA2XWWcSbty7d0u5/331J6EuNtSHRoSO ZEkJ8J5yp/+p34+0MwW8WwJ1NSELR2goKPftDdxqEgyShUENdMdrJqo1X c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ALBQBQVa5V/49dJa1cgxOBQ8QngR47EQEBAQEBAQGBCoQqIxFXASICJgIEMBUSBIhBpQKPX5ZEAQEBAQEFAQEBAQEBAQEagSKSHy+BFAWRSIMLAYwpgUOHLHCPLyaDfII2gQQBAQE
X-IronPort-AV: E=Sophos;i="5.15,516,1432598400"; d="scan'208";a="170688463"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP; 21 Jul 2015 14:22:39 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t6LEMdS5015168 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <video-codec@ietf.org>; Tue, 21 Jul 2015 14:22:39 GMT
Received: from xmb-aln-x01.cisco.com ([169.254.2.64]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 21 Jul 2015 09:22:39 -0500
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: draft-filippov-netvc-requirements-01
Thread-Index: AQHQw8CyW0GCvpXJZECxIZTezzBngA==
Date: Tue, 21 Jul 2015 14:22:39 +0000
Message-ID: <32AA73C5-0D17-4ECE-A02D-041C5147D9E5@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.150701
x-originating-ip: [10.61.108.86]
Content-Type: text/plain; charset="utf-8"
Content-ID: <131415CCE744F845868F93DDCF6A2E63@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/MDX2f1BA-jWMAew6Y67Ma6k4wpU>
Subject: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Jul 2015 14:22:47 -0000

SSByZWFkIHRoaXMgZHJhZnQgYWZ0ZXIgc2VlaW5nIHRoZSBwcmVzZW50YXRpb24geWVzdGVyZGF5
LiBPdmVyYWxsLCBJIGRvbnQgbGlrZSB0aGUgZmFjdCB0aGF0IHRoaXMgZHJhZnQgdHJpZXMgdG8g
Y292ZXIgYSBsb3Qgb2YgdXNlIGNhc2VzIHF1aXRlIG5hcnJvd2x5LiBUaGVyZSBhcmUgc28gbWFu
eSBvbWlzc2lvbnMgaGVyZSBhbmQgdGhlcmUuDQoNClRoZSBjaGFydGVyIGZvciB0aGlzIFdHIGlz
IHRvIHByb3ZpZGUgYSBnb29kIGNvZGVjIGZvciBpbnRlcmFjdGl2ZSB2aWRlbyBhcHBsaWNhdGlv
bnMuIFNvIGFsbCB0aGUgcmVzdCBvZiB0aGUgdXNlIGNhc2VzIHNob3VsZCBiZSBkcm9wcGVkIGFu
ZCBub3QgZGlzY3Vzc2VkIGF0IGFsbC4NCg0KVGhpcyBXRyBzaG91bGQgc3BlbmQgd2hhdGV2ZXIg
ZW5lcmd5IGl0IGhhcyB0byBmb2N1cyBvbiB0aGUgcHJpbWFyeSB1c2UgY2FzZSAoaW50ZXJhY3Rp
dmUgdmlkZW8pIGxpa2UgUlRDd2ViLCBjb25mZXJlbmNpbmcsIGV0Yy4gSSBkb250IHRoaW5rIHdl
IGhhdmUgdGhlIGVuZXJneSB0byBjcmVhdGUgYSBjb2RlYyB0aGF0IHdpbGwgc2F0aXNmeSB3b3Js
ZOKAmXMgYWxsIHZpZGVvIGRlbWFuZHMuDQoNClNvIElQVFYsIGdhbWUgc3RyZWFtaW5nIGFuZCB2
aWRlbyBzaGFyaW5nIHNob3VsZCBiZSByZW1vdmVkIGZyb20gdGhlIHJlcXMgZG9jdW1lbnQuIEkg
YW0gbm90IHNvIHN1cmUgYWJvdXQgdmlkZW8gbW9uaXRvcmluZywgdGhvdWdoLCBhcyBpdCBoYXMg
cXVpdGUgbWFueSBzaW1pbGFyaXRpZXMgdG8gaW50ZXJhY3RpdmUgdmlkZW8uIA0KDQpGV0lXLCBJ
IGFyZ3VlIHRoYXQgaW50ZXJsYWNpbmcgc2hvdWxkIG5vdCBiZSBjb25zaWRlcmVkIGluIHRoaXMg
V0cgKG9yIGF0IGFsbCBmb3IgYW55IHZpZGVvIGNvZGVjKSBtb3ZpbmcgZm9yd2FyZC4gDQoNCi1h
Y2JlZ2VuDQo=


From nobody Tue Jul 21 07:29:02 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 7048E1B2D7B for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 07:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.078
X-Spam-Level: 
X-Spam-Status: No, score=-4.078 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, 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 vTHZ5tzRtmkY for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 07:29:00 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (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 0F7501B2E63 for <video-codec@ietf.org>; Tue, 21 Jul 2015 07:29:00 -0700 (PDT)
Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id A5F02C01AF for <video-codec@ietf.org>; Tue, 21 Jul 2015 14:28:59 +0000 (UTC)
X-Virus-Scanned: amavisd-new at mozilla.org
Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okidLWQyhl-f for <video-codec@ietf.org>; Tue, 21 Jul 2015 14:28:59 +0000 (UTC)
Received: from [31.133.169.52] (dhcp-a934.meeting.ietf.org [31.133.169.52]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 0E774C0126 for <video-codec@ietf.org>; Tue, 21 Jul 2015 14:28:58 +0000 (UTC)
Message-ID: <55AE5729.1000103@xiph.org>
Date: Tue, 21 Jul 2015 07:28:57 -0700
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" <video-codec@ietf.org>
References: <32AA73C5-0D17-4ECE-A02D-041C5147D9E5@cisco.com>
In-Reply-To: <32AA73C5-0D17-4ECE-A02D-041C5147D9E5@cisco.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/b4DdbH7MfppDPzQJJZ9LgYJQBe8>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Jul 2015 14:29:01 -0000

Ali C. Begen (abegen) wrote:
> I read this draft after seeing the presentation yesterday. Overall, I dont like the fact that this draft tries to cover a lot of use cases quite narrowly. There are so many omissions here and there.
>
> The charter for this WG is to provide a good codec for interactive video applications. So all the rest of the use cases should be dropped and not discussed at all.

I think at the very least on-demand Netflix/Youtube/etc. streaming is a 
very important internet use case that we want to satisfy. Interactive is 
called out explicitly by the charter because it imposes a set of severe 
technical constraints on what the codec can do, but I don't think the 
intent was to limit us to that use case (as indicated by the words "but 
not necessarily limited to" in the charter).


From nobody Tue Jul 21 07:37:31 2015
Return-Path: <abegen@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 745291A8857 for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 07:37:29 -0700 (PDT)
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 ug-nDK7xa2Uj for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 07:37:28 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 060091A1A8D for <video-codec@ietf.org>; Tue, 21 Jul 2015 07:37:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2206; q=dns/txt; s=iport; t=1437489448; x=1438699048; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=a8figfzJDYBiDR3HwDNYO/flR4Tk4zc86EXZqtDilAk=; b=FfWEZ6j+aqaBVh9sWdH7YNIIw1DJ4+L9bI20cLuKbyjnZCvEq3o9mLUS 21MDZ0KfJjLrHdWkH5VZlZ1S/b9MChMwOCWNZ9kiYENuS+cggbvn0bJS3 OZMIkeXDQoac3P5Pr2InoJ+lAANvwZDWb9SrXgkoJTL52k9Q2MHbrY0zr k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AiAwDYWK5V/4MNJK1cgxNUaQa8CgmBawqGAQIcgR44FAEBAQEBAQGBCoQjAQEBBAEBASAREycXBAIBCBEDAQIBAgImAgICJQsVCAgCBAESiC4NtF+FG5EuAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIooqhC0BJToGgmIvgRQFlFMBjCkBgUKHLJAfJoN8b4EEAR8jgQQBAQE
X-IronPort-AV: E=Sophos;i="5.15,516,1432598400"; d="scan'208";a="170693057"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-3.cisco.com with ESMTP; 21 Jul 2015 14:37:08 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t6LEb8rN026142 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jul 2015 14:37:08 GMT
Received: from xmb-aln-x01.cisco.com ([169.254.2.64]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Tue, 21 Jul 2015 09:37:07 -0500
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: "Timothy B. Terriberry" <tterribe@xiph.org>, "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: [video-codec] draft-filippov-netvc-requirements-01
Thread-Index: AQHQw8CyW0GCvpXJZECxIZTezzBngJ3mT3eAgAAjzgA=
Date: Tue, 21 Jul 2015 14:37:06 +0000
Message-ID: <EB669368-8909-4C63-B9EC-6ADCF6A751BA@cisco.com>
References: <32AA73C5-0D17-4ECE-A02D-041C5147D9E5@cisco.com> <55AE5729.1000103@xiph.org>
In-Reply-To: <55AE5729.1000103@xiph.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.150701
x-originating-ip: [10.61.108.86]
Content-Type: text/plain; charset="utf-8"
Content-ID: <CF192FA57808E14DA89B90C980B9FD69@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/mv4O2a62q_MQ4yRQLv_R98tPpoU>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Jul 2015 14:37:29 -0000

DQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB2aWRlby1jb2RlYyBv
biBiZWhhbGYgb2YgIlRpbW90aHkgQi4gVGVycmliZXJyeSINCkRhdGU6IFR1ZXNkYXksIEp1bHkg
MjEsIDIwMTUgYXQgNDoyOCBQTQ0KVG86ICJ2aWRlby1jb2RlY0BpZXRmLm9yZyINClN1YmplY3Q6
IFJlOiBbdmlkZW8tY29kZWNdIGRyYWZ0LWZpbGlwcG92LW5ldHZjLXJlcXVpcmVtZW50cy0wMQ0K
DQo+QWxpIEMuIEJlZ2VuIChhYmVnZW4pIHdyb3RlOg0KPj4gSSByZWFkIHRoaXMgZHJhZnQgYWZ0
ZXIgc2VlaW5nIHRoZSBwcmVzZW50YXRpb24geWVzdGVyZGF5LiBPdmVyYWxsLCBJIGRvbnQgbGlr
ZSB0aGUgZmFjdCB0aGF0IHRoaXMgZHJhZnQgdHJpZXMgdG8gY292ZXIgYSBsb3Qgb2YgdXNlIGNh
c2VzIHF1aXRlIG5hcnJvd2x5LiBUaGVyZSBhcmUgc28gbWFueSBvbWlzc2lvbnMgaGVyZSBhbmQg
dGhlcmUuDQo+Pg0KPj4gVGhlIGNoYXJ0ZXIgZm9yIHRoaXMgV0cgaXMgdG8gcHJvdmlkZSBhIGdv
b2QgY29kZWMgZm9yIGludGVyYWN0aXZlIHZpZGVvIGFwcGxpY2F0aW9ucy4gU28gYWxsIHRoZSBy
ZXN0IG9mIHRoZSB1c2UgY2FzZXMgc2hvdWxkIGJlIGRyb3BwZWQgYW5kIG5vdCBkaXNjdXNzZWQg
YXQgYWxsLg0KPg0KPkkgdGhpbmsgYXQgdGhlIHZlcnkgbGVhc3Qgb24tZGVtYW5kIE5ldGZsaXgv
WW91dHViZS9ldGMuIHN0cmVhbWluZyBpcyBhIA0KPnZlcnkgaW1wb3J0YW50IGludGVybmV0IHVz
ZSBjYXNlIHRoYXQgd2Ugd2FudCB0byBzYXRpc2Z5LiBJbnRlcmFjdGl2ZSBpcyANCj5jYWxsZWQg
b3V0IGV4cGxpY2l0bHkgYnkgdGhlIGNoYXJ0ZXIgYmVjYXVzZSBpdCBpbXBvc2VzIGEgc2V0IG9m
IHNldmVyZSANCj50ZWNobmljYWwgY29uc3RyYWludHMgb24gd2hhdCB0aGUgY29kZWMgY2FuIGRv
LCBidXQgSSBkb24ndCB0aGluayB0aGUgDQo+aW50ZW50IHdhcyB0byBsaW1pdCB1cyB0byB0aGF0
IHVzZSBjYXNlIChhcyBpbmRpY2F0ZWQgYnkgdGhlIHdvcmRzICJidXQgDQo+bm90IG5lY2Vzc2Fy
aWx5IGxpbWl0ZWQgdG8iIGluIHRoZSBjaGFydGVyKS4NCg0KSSB1bmRlcnN0YW5kIHRoYXQgcGFy
dCBidXQgd2hhdCBJIGFtIHNheWluZyBpcyB0aGF0IGRldmVsb3BpbmcgYSBjb2RlYyB0aGF0IHdp
bGwgYm90aCBwZXJmb3JtIGVub3VnaCB3ZWxsIGZvciBpbnRlcmFjdGl2ZSB2aWRlbyBhbmQgc3Ry
ZWFtaW5nIHZpZGVvIGlzIGEgdGVkaW91cyB0YXNrLiBGb2N1c2luZyBvbiB0d28gZGlmZmVyZW50
IHRoaW5ncyB3aWxsIGluY3JlYXNlIHRoZSByaXNrIG9mIGZhaWx1cmUgZm9yIHRoaXMgd2cuIE1h
eWJlIHRoZSB3ZyBzaG91bGQgY29uc2lkZXIgc29sdmluZyB0aGUgZmlyc3QgKGFuZCB0aGUgbW9y
ZSBpbXBvcnRhbnQpIHByb2JsZW0gZmlyc3QgYW5kIHRoZW4gc2VlIHdoZXRoZXIgaXQgY2FuIHRh
Y2tsZSB0aGUgc2Vjb25kIHByb2JsZW0uDQoNCg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQo+dmlkZW8tY29kZWMgbWFpbGluZyBsaXN0DQo+dmlk
ZW8tY29kZWNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L3ZpZGVvLWNvZGVjDQo=


From nobody Tue Jul 21 07:57:31 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 DD6FD1B2EB5 for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 07:57:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.977
X-Spam-Level: 
X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, 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 wtHBZAsH04R8 for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 07:57:26 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.scl3.mozilla.com [63.245.214.156]) (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 E32B01B2E1B for <video-codec@ietf.org>; Tue, 21 Jul 2015 07:57:26 -0700 (PDT)
Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id 7AD0AC054D for <video-codec@ietf.org>; Tue, 21 Jul 2015 14:57:26 +0000 (UTC)
X-Virus-Scanned: amavisd-new at mozilla.org
Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx2.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-dekVR3_YW3 for <video-codec@ietf.org>; Tue, 21 Jul 2015 14:57:26 +0000 (UTC)
Received: from [31.133.169.52] (dhcp-a934.meeting.ietf.org [31.133.169.52]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id CF586C183E for <video-codec@ietf.org>; Tue, 21 Jul 2015 14:57:25 +0000 (UTC)
Message-ID: <55AE5DD1.60400@xiph.org>
Date: Tue, 21 Jul 2015 07:57:21 -0700
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" <video-codec@ietf.org>
References: <32AA73C5-0D17-4ECE-A02D-041C5147D9E5@cisco.com> <55AE5729.1000103@xiph.org> <EB669368-8909-4C63-B9EC-6ADCF6A751BA@cisco.com>
In-Reply-To: <EB669368-8909-4C63-B9EC-6ADCF6A751BA@cisco.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/mCcpd8cDrB4SqRTVUdNi9lQiBaQ>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Jul 2015 14:57:29 -0000

Ali C. Begen (abegen) wrote:
> I understand that part but what I am saying is that developing a codec that will both perform enough well for interactive video and streaming video is a tedious task. Focusing on two different things will increase the risk of failure for this wg. Maybe the wg should consider solving the first (and the more important) problem first and then see whether it can tackle the second problem.

Well, I agree we can probably significantly narrow the set of use cases 
we want to consider, but I think narrowing it down to one is too extreme.

 From the perspective of my employer (Mozilla), for example, we need a 
codec that works in the <video> tag and in WebRTC, and we currently see 
a lot more usage of the former than the latter.

Focusing on interactive first may still be smart, but "success" for us 
means solving both problems. I don't think anything we write in our 
requirements draft precludes the WG from deciding to publish a codec 
that only solves one of them, though, if we later decide the other is 
too hard.


From nobody Tue Jul 21 08:05:49 2015
Return-Path: <abegen@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 BAC081B2E60 for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 08:05:47 -0700 (PDT)
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 Ie0spR1aO_YM for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 08:05:46 -0700 (PDT)
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 5AEFA1B2E4E for <video-codec@ietf.org>; Tue, 21 Jul 2015 08:05:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3038; q=dns/txt; s=iport; t=1437491137; x=1438700737; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=XGNd7YDsx8L6xr3wvJ8nBfOJfoWgAN1FSH+xA7QoKN4=; b=bZ0XHK3mq5Scd1/2dA5AnfE6w1wan0Gc4gNpo96pEjix5tIGYra/ksgP Z0rbnOEMpIHuC4oOa/0LOlTj0eSSadsiq/odJJb7gEXjX3/xeqjNR5jez Qq8PJwnWqN+yxUju6RTVsJp2RkiBBTGw31yBQUPqgvNcK21T/LmyxrrV3 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AFBQDMXq5V/4sNJK1cgxNUaQa8E4FrCoYBAhyBHjoSAQEBAQEBAYEKhCMBAQEDAQEBASAREycXBAIBCBEDAQIBAgImAgICJQsVCAgCBAESiCYIDbR2hRuRLAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSKKKoUNBoJiL4EUBZRTAYwpmQ4mg3xvgUeBBAEBAQ
X-IronPort-AV: E=Sophos;i="5.15,516,1432598400"; d="scan'208";a="170822086"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-8.cisco.com with ESMTP; 21 Jul 2015 15:05:36 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t6LF5aSU012663 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jul 2015 15:05:36 GMT
Received: from xmb-aln-x01.cisco.com ([169.254.2.64]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Tue, 21 Jul 2015 10:05:36 -0500
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: "Timothy B. Terriberry" <tterribe@xiph.org>, "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: [video-codec] draft-filippov-netvc-requirements-01
Thread-Index: AQHQw8CyW0GCvpXJZECxIZTezzBngJ3mT3eAgAAjzgD//+QigIAAI9SA
Date: Tue, 21 Jul 2015 15:05:35 +0000
Message-ID: <874F1405-1E81-4560-8314-B7F8B475A738@cisco.com>
References: <32AA73C5-0D17-4ECE-A02D-041C5147D9E5@cisco.com> <55AE5729.1000103@xiph.org> <EB669368-8909-4C63-B9EC-6ADCF6A751BA@cisco.com> <55AE5DD1.60400@xiph.org>
In-Reply-To: <55AE5DD1.60400@xiph.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.150701
x-originating-ip: [10.61.108.86]
Content-Type: text/plain; charset="utf-8"
Content-ID: <9A8B2CA9CE251C4DA42B2275A7489EA4@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/RkfIv7r3X6uuNlRfkvM4KS-hJqc>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Jul 2015 15:05:47 -0000

DQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB2aWRlby1jb2RlYyBv
biBiZWhhbGYgb2YgIlRpbW90aHkgQi4gVGVycmliZXJyeSINCkRhdGU6IFR1ZXNkYXksIEp1bHkg
MjEsIDIwMTUgYXQgNDo1NyBQTQ0KVG86ICJ2aWRlby1jb2RlY0BpZXRmLm9yZyINClN1YmplY3Q6
IFJlOiBbdmlkZW8tY29kZWNdIGRyYWZ0LWZpbGlwcG92LW5ldHZjLXJlcXVpcmVtZW50cy0wMQ0K
DQo+QWxpIEMuIEJlZ2VuIChhYmVnZW4pIHdyb3RlOg0KPj4gSSB1bmRlcnN0YW5kIHRoYXQgcGFy
dCBidXQgd2hhdCBJIGFtIHNheWluZyBpcyB0aGF0IGRldmVsb3BpbmcgYSBjb2RlYyB0aGF0IHdp
bGwgYm90aCBwZXJmb3JtIGVub3VnaCB3ZWxsIGZvciBpbnRlcmFjdGl2ZSB2aWRlbyBhbmQgc3Ry
ZWFtaW5nIHZpZGVvIGlzIGEgdGVkaW91cyB0YXNrLiBGb2N1c2luZyBvbiB0d28gZGlmZmVyZW50
IHRoaW5ncyB3aWxsIGluY3JlYXNlIHRoZSByaXNrIG9mIGZhaWx1cmUgZm9yIHRoaXMgd2cuIE1h
eWJlIHRoZSB3ZyBzaG91bGQgY29uc2lkZXIgc29sdmluZyB0aGUgZmlyc3QgKGFuZCB0aGUgbW9y
ZSBpbXBvcnRhbnQpIHByb2JsZW0gZmlyc3QgYW5kIHRoZW4gc2VlIHdoZXRoZXIgaXQgY2FuIHRh
Y2tsZSB0aGUgc2Vjb25kIHByb2JsZW0uDQo+DQo+V2VsbCwgSSBhZ3JlZSB3ZSBjYW4gcHJvYmFi
bHkgc2lnbmlmaWNhbnRseSBuYXJyb3cgdGhlIHNldCBvZiB1c2UgY2FzZXMgDQo+d2Ugd2FudCB0
byBjb25zaWRlciwgYnV0IEkgdGhpbmsgbmFycm93aW5nIGl0IGRvd24gdG8gb25lIGlzIHRvbyBl
eHRyZW1lLg0KDQpXZSBkaXNhZ3JlZSwgdGhhdCBpcyBmaW5lLg0KDQo+DQo+IEZyb20gdGhlIHBl
cnNwZWN0aXZlIG9mIG15IGVtcGxveWVyIChNb3ppbGxhKSwgZm9yIGV4YW1wbGUsIHdlIG5lZWQg
YSANCj5jb2RlYyB0aGF0IHdvcmtzIGluIHRoZSA8dmlkZW8+IHRhZyBhbmQgaW4gV2ViUlRDLCBh
bmQgd2UgY3VycmVudGx5IHNlZSANCj5hIGxvdCBtb3JlIHVzYWdlIG9mIHRoZSBmb3JtZXIgdGhh
biB0aGUgbGF0dGVyLg0KDQpTdXJlLCB0aGUgYW1vdW50IG9mIHN0cmVhbWluZyB2aWRlbyBpcyBm
YXIgYmlnZ2VyIHRoYW4gYW55IHdlYnJ0YyB0cmFmZmljIG5vdywgYW5kIGl0IHdpbGwgYmUgbGlr
ZSB0aGF0IG1heWJlIGZvcmV2ZXIuIFdoYXQgSSBhbSBzYXlpbmcgaXMgdGhhdCBpdCB0YWtlcyBh
IGxvdCBtb3JlIGVmZm9ydCB0byBiZWF0IHRoZSBjdXJyZW50IGRlIGZhY3RvIGNvZGVjcyB0aGF0
IGFyZSB1c2VkIGZvciBzdHJlYW1pbmcgYW5kIGVudGVydGFpbm1lbnQgdmlkZW8uIFRoZSBwYXRo
IHRvIHN1Y2Nlc3MgaXMgZWFzaWVyIGZvciB0aGUgaW50ZXJhY3RpdmUgdmlkZW8uIEZvciBlbnRl
cnRhaW5tZW50IHZpZGVvLCBwZW9wbGUgcGF5IGZvciBxdWFsaXR5LCB0aGV5IG1heSBhbHNvIHBh
eSBmb3Igd2VicnRjIHNlcnZpY2VzIGJ1dCBpdCB3aWxsIGJlIG11Y2ggbGVzcyAkLg0KDQo+DQo+
Rm9jdXNpbmcgb24gaW50ZXJhY3RpdmUgZmlyc3QgbWF5IHN0aWxsIGJlIHNtYXJ0LCBidXQgInN1
Y2Nlc3MiIGZvciB1cyANCj5tZWFucyBzb2x2aW5nIGJvdGggcHJvYmxlbXMuIEkgZG9uJ3QgdGhp
bmsgYW55dGhpbmcgd2Ugd3JpdGUgaW4gb3VyIA0KPnJlcXVpcmVtZW50cyBkcmFmdCBwcmVjbHVk
ZXMgdGhlIFdHIGZyb20gZGVjaWRpbmcgdG8gcHVibGlzaCBhIGNvZGVjIA0KPnRoYXQgb25seSBz
b2x2ZXMgb25lIG9mIHRoZW0sIHRob3VnaCwgaWYgd2UgbGF0ZXIgZGVjaWRlIHRoZSBvdGhlciBp
cyANCj50b28gaGFyZC4NCg0KRmFpciBlbm91Z2gsIGJ1dCB0aGVuIEkgaGF2ZSB0byBzYXkgdGhh
dCBJIGRpc2FncmVlIG9uIHNvbWUgb2YgdGhlIHJlcXMgbWVudGlvbmVkIGluIHRoZSBzZWN0aW9u
cyBJIHN1Z2dlc3RlZCBmb3IgcmVtb3ZhbC4gTW9zdCBvZiB0aGVtIGFyZSBub3QgZXZlbiByZXFz
IGJ1dCBqdXN0IGEgY29sbGVjdGlvbiBvZiB3aGF0IGlzIGluIHRoZSBtYXJrZXQgdG9kYXkuIE9i
dmlvdXNseSBpZiB0aG9zZSBzZWN0aW9ucyBhcmUgdG8gc3RheSwgdGhleSBuZWVkIHF1aXRlIGEg
Yml0IHdvcmsuDQoNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KPnZpZGVvLWNvZGVjIG1haWxpbmcgbGlzdA0KPnZpZGVvLWNvZGVjQGlldGYub3Jn
DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92aWRlby1jb2RlYw0K


From nobody Tue Jul 21 08:10: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 AFC311A88A4 for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 08:10:44 -0700 (PDT)
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 yX8H5F-3R5oM for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 08:10:42 -0700 (PDT)
Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (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 A197B1B2EE8 for <video-codec@ietf.org>; Tue, 21 Jul 2015 08:10:10 -0700 (PDT)
Received: by wgkl9 with SMTP id l9so159029305wgk.1 for <video-codec@ietf.org>; Tue, 21 Jul 2015 08:10:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=XVAWeu4MFaCgdj2Z4qL8YHSfte/at00FfqiqT0Yup9I=; b=a2QZboUFuYD82wsBWYmFsY2mped2l12Aqt37PYzAWhOqvJLkKIFFBejsYFCDuUN6Q5 El8twRSqyMfImSOGrCbb26e3GjEUiQAd+ac6pX0lE+4rpZnQSJmiu21jYZQnC4WanbzR GU5Yax7AIWLuRVtStk6WR/4carS8uu4daAJvKYbH4jcJahRDSDQGnauoEmJW56QkaCeI LvTMcr76TkZivKM481Rr1pzSurHhh0aPd1PfvMCQMQ489XLn+eAcGCul0tENwEb/wOSN pQkwKw2HvmwO9qgjq/rIXH1+ICaa78Lo8kHqLeUgaPdtJqt/PGUkOt8JvLfOjX9p5ykX ThlA==
X-Gm-Message-State: ALoCoQlGUc0UF3eycqIVKZ8jZmW1sIhw2a9BirV4ier/7u6d4sM8SAswGMhEdxua+UIYj5J/7Tdg
X-Received: by 10.180.38.78 with SMTP id e14mr33488871wik.10.1437491409343; Tue, 21 Jul 2015 08:10:09 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:168:7e7a:91ff:fe9e:8126? ([2001:67c:370:168:7e7a:91ff:fe9e:8126]) by smtp.gmail.com with ESMTPSA id lq9sm37480662wjb.35.2015.07.21.08.10.08 for <video-codec@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jul 2015 08:10:08 -0700 (PDT)
To: video-codec@ietf.org
References: <32AA73C5-0D17-4ECE-A02D-041C5147D9E5@cisco.com>
From: Thomas Daede <tdaede@mozilla.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <55AE60D0.3040201@mozilla.com>
Date: Tue, 21 Jul 2015 17:10:08 +0200
User-Agent: http://a.pomf.se/cszdno.opus
MIME-Version: 1.0
In-Reply-To: <32AA73C5-0D17-4ECE-A02D-041C5147D9E5@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/uJsinabiLZOfpTroC73xitF9Zjc>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Jul 2015 15:10:45 -0000

On 07/21/2015 04:22 PM, Ali C. Begen (abegen) wrote:
> This WG should spend whatever energy it has to focus on the primary use case (interactive video) like RTCweb, conferencing, etc. I dont think we have the energy to create a codec that will satisfy world’s all video demands.

I think that this would dangerously narrow the adoption of the codec.
Would Opus have done nearly as well if it was only SILK?

> So IPTV, game streaming and video sharing should be removed from the reqs document. I am not so sure about video monitoring, though, as it has quite many similarities to interactive video. 

I have many issues with the categories in the requirements draft:

- All of the use cases should specify either a high latency or low
latency requirement.
- Error resilience should be moved out of the use cases. It can be
implied by low latency, as can a lot of other things (transport, etc)
- IPTV seems to intend to describe UDP multicast sorts of IPTV, which is
not very common in the US but has some traction in other countries / as
a backend for cable distribution. If this is the case, it really needs
to be made clear.
- The big list of resolutions is overly verbose and not necessary. A
simple range of resolutions and frame rates would be better.
- Game streaming needs to be split into high latency (twitch) and low
latency (steam remote play) applications.

> FWIW, I argue that interlacing should not be considered in this WG (or at all for any video codec) moving forward. 

I think that interlacing tools should not be supported by the video
codec, but it would be good to test on content that was originally
provided in interlaced format and then run through a deinterlacer. How
this is done exactly should be specified.


From nobody Tue Jul 21 08:39:43 2015
Return-Path: <abegen@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 BD8211A8A3D for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 08:39:42 -0700 (PDT)
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 PnwzRzz4aSL4 for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 08:39:41 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5C051B2E6E for <video-codec@ietf.org>; Tue, 21 Jul 2015 08:39:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3376; q=dns/txt; s=iport; t=1437493157; x=1438702757; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=oJrJyznb17f3+vqZcDRk91R+l5dYjbgn1dKdibrEsuM=; b=OpV38tNJibiewGdwXhSZMUyiS8TAJO29Pz93rdJv2BT56s9uPXJMsqHQ Q3qdUtCBwkHeawtotlef3FRZ3dDH6FOD/Mx67fEZPvvvbWyC0wK/x1kqM Ce8yXkBtpBfKuc1JbEMts7T76I5JXJZlr71Q9BEcQ5Zjp0D2fLqnvEsw1 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AiAwB2Zq5V/5FdJa1cgxNUaQa8CgmBawqGAQIcgR44FAEBAQEBAQGBCoQjAQEBAwEBAQEgEToXBAIBCA4DAwECAQICJgICAiULFQgIAgQBEogmCA21FJZFAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIooqhFMYIgaCYi+BFAWRSBOCeAGMKYFDhByEAI8vJoN8b4FHgQQBAQE
X-IronPort-AV: E=Sophos;i="5.15,517,1432598400"; d="scan'208";a="11732823"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-9.cisco.com with ESMTP; 21 Jul 2015 15:39:16 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t6LFdGWh031757 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jul 2015 15:39:16 GMT
Received: from xmb-aln-x01.cisco.com ([169.254.2.64]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Tue, 21 Jul 2015 10:39:16 -0500
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: Thomas Daede <tdaede@mozilla.com>, "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: [video-codec] draft-filippov-netvc-requirements-01
Thread-Index: AQHQw8CyW0GCvpXJZECxIZTezzBngJ3mWvkAgAApqwA=
Date: Tue, 21 Jul 2015 15:39:16 +0000
Message-ID: <29BD22C6-8790-451B-B754-ED55D2F41C90@cisco.com>
References: <32AA73C5-0D17-4ECE-A02D-041C5147D9E5@cisco.com> <55AE60D0.3040201@mozilla.com>
In-Reply-To: <55AE60D0.3040201@mozilla.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.150701
x-originating-ip: [10.61.108.86]
Content-Type: text/plain; charset="utf-8"
Content-ID: <E7744EFA368B1443AD96C34DC7589A42@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/C31snWmLYkgx8GDrUhosmnkWolo>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Jul 2015 15:39:42 -0000

DQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB2aWRlby1jb2RlYyBv
biBiZWhhbGYgb2YgVGhvbWFzIERhZWRlDQpEYXRlOiBUdWVzZGF5LCBKdWx5IDIxLCAyMDE1IGF0
IDU6MTAgUE0NClRvOiAidmlkZW8tY29kZWNAaWV0Zi5vcmciDQpTdWJqZWN0OiBSZTogW3ZpZGVv
LWNvZGVjXSBkcmFmdC1maWxpcHBvdi1uZXR2Yy1yZXF1aXJlbWVudHMtMDENCg0KPk9uIDA3LzIx
LzIwMTUgMDQ6MjIgUE0sIEFsaSBDLiBCZWdlbiAoYWJlZ2VuKSB3cm90ZToNCj4+IFRoaXMgV0cg
c2hvdWxkIHNwZW5kIHdoYXRldmVyIGVuZXJneSBpdCBoYXMgdG8gZm9jdXMgb24gdGhlIHByaW1h
cnkgdXNlIGNhc2UgKGludGVyYWN0aXZlIHZpZGVvKSBsaWtlIFJUQ3dlYiwgY29uZmVyZW5jaW5n
LCBldGMuIEkgZG9udCB0aGluayB3ZSBoYXZlIHRoZSBlbmVyZ3kgdG8gY3JlYXRlIGEgY29kZWMg
dGhhdCB3aWxsIHNhdGlzZnkgd29ybGTigJlzIGFsbCB2aWRlbyBkZW1hbmRzLg0KPg0KPkkgdGhp
bmsgdGhhdCB0aGlzIHdvdWxkIGRhbmdlcm91c2x5IG5hcnJvdyB0aGUgYWRvcHRpb24gb2YgdGhl
IGNvZGVjLg0KPldvdWxkIE9wdXMgaGF2ZSBkb25lIG5lYXJseSBhcyB3ZWxsIGlmIGl0IHdhcyBv
bmx5IFNJTEs/DQoNCkFuZCBwbGVhc2UgdGVsbCBtZSB3aGVyZSBPcHVzIGlzIHVzZWQgaW4gdGhl
IGVudGVydGFpbm1lbnQgd29ybGQ/DQoNCj4NCj4+IFNvIElQVFYsIGdhbWUgc3RyZWFtaW5nIGFu
ZCB2aWRlbyBzaGFyaW5nIHNob3VsZCBiZSByZW1vdmVkIGZyb20gdGhlIHJlcXMgZG9jdW1lbnQu
IEkgYW0gbm90IHNvIHN1cmUgYWJvdXQgdmlkZW8gbW9uaXRvcmluZywgdGhvdWdoLCBhcyBpdCBo
YXMgcXVpdGUgbWFueSBzaW1pbGFyaXRpZXMgdG8gaW50ZXJhY3RpdmUgdmlkZW8uIA0KPg0KPkkg
aGF2ZSBtYW55IGlzc3VlcyB3aXRoIHRoZSBjYXRlZ29yaWVzIGluIHRoZSByZXF1aXJlbWVudHMg
ZHJhZnQ6DQo+DQo+LSBBbGwgb2YgdGhlIHVzZSBjYXNlcyBzaG91bGQgc3BlY2lmeSBlaXRoZXIg
YSBoaWdoIGxhdGVuY3kgb3IgbG93DQo+bGF0ZW5jeSByZXF1aXJlbWVudC4NCg0KQW5kIHdoZXJl
IGlzIHRoZSBib3JkZXJsaW5lPw0KDQo+LSBFcnJvciByZXNpbGllbmNlIHNob3VsZCBiZSBtb3Zl
ZCBvdXQgb2YgdGhlIHVzZSBjYXNlcy4gSXQgY2FuIGJlDQo+aW1wbGllZCBieSBsb3cgbGF0ZW5j
eSwgYXMgY2FuIGEgbG90IG9mIG90aGVyIHRoaW5ncyAodHJhbnNwb3J0LCBldGMpDQo+LSBJUFRW
IHNlZW1zIHRvIGludGVuZCB0byBkZXNjcmliZSBVRFAgbXVsdGljYXN0IHNvcnRzIG9mIElQVFYs
IHdoaWNoIGlzDQo+bm90IHZlcnkgY29tbW9uIGluIHRoZSBVUyBidXQgaGFzIHNvbWUgdHJhY3Rp
b24gaW4gb3RoZXIgY291bnRyaWVzIC8gYXMNCj5hIGJhY2tlbmQgZm9yIGNhYmxlIGRpc3RyaWJ1
dGlvbi4gSWYgdGhpcyBpcyB0aGUgY2FzZSwgaXQgcmVhbGx5IG5lZWRzDQo+dG8gYmUgbWFkZSBj
bGVhci4NCg0KSSBzdGlsbCBhcmd1ZSBpcHR2IHNob3VsZCBiZSByZW1vdmVkIGVudGlyZWx5Lg0K
DQo+LSBUaGUgYmlnIGxpc3Qgb2YgcmVzb2x1dGlvbnMgaXMgb3Zlcmx5IHZlcmJvc2UgYW5kIG5v
dCBuZWNlc3NhcnkuIEENCj5zaW1wbGUgcmFuZ2Ugb2YgcmVzb2x1dGlvbnMgYW5kIGZyYW1lIHJh
dGVzIHdvdWxkIGJlIGJldHRlci4NCg0KQWdyZWVkLg0KDQo+LSBHYW1lIHN0cmVhbWluZyBuZWVk
cyB0byBiZSBzcGxpdCBpbnRvIGhpZ2ggbGF0ZW5jeSAodHdpdGNoKSBhbmQgbG93DQo+bGF0ZW5j
eSAoc3RlYW0gcmVtb3RlIHBsYXkpIGFwcGxpY2F0aW9ucy4NCg0KSW5kZWVkLg0KDQo+DQo+PiBG
V0lXLCBJIGFyZ3VlIHRoYXQgaW50ZXJsYWNpbmcgc2hvdWxkIG5vdCBiZSBjb25zaWRlcmVkIGlu
IHRoaXMgV0cgKG9yIGF0IGFsbCBmb3IgYW55IHZpZGVvIGNvZGVjKSBtb3ZpbmcgZm9yd2FyZC4g
DQo+DQo+SSB0aGluayB0aGF0IGludGVybGFjaW5nIHRvb2xzIHNob3VsZCBub3QgYmUgc3VwcG9y
dGVkIGJ5IHRoZSB2aWRlbw0KPmNvZGVjLCBidXQgaXQgd291bGQgYmUgZ29vZCB0byB0ZXN0IG9u
IGNvbnRlbnQgdGhhdCB3YXMgb3JpZ2luYWxseQ0KPnByb3ZpZGVkIGluIGludGVybGFjZWQgZm9y
bWF0IGFuZCB0aGVuIHJ1biB0aHJvdWdoIGEgZGVpbnRlcmxhY2VyLiBIb3cNCj50aGlzIGlzIGRv
bmUgZXhhY3RseSBzaG91bGQgYmUgc3BlY2lmaWVkLg0KDQpBcmUgeW91IGludGVyZXN0ZWQgaW4g
cmUtZW5jb2Rpbmcgb2YgcHJlLWVuY29kZWQgY29udGVudD8gSWYgc28sIHdoeT8gSWYgbm90LCB3
aHkgYm90aGVyIHdpdGggdGhpcyB0ZXN0Pw0KDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCj52aWRlby1jb2RlYyBtYWlsaW5nIGxpc3QNCj52aWRl
by1jb2RlY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
dmlkZW8tY29kZWMNCg==


From nobody Tue Jul 21 09:12:19 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 B8F0C1A8BBE for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 09:12:17 -0700 (PDT)
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 orHQkIvIoBag for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 09:12:15 -0700 (PDT)
Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (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 2F7951A8BBF for <video-codec@ietf.org>; Tue, 21 Jul 2015 09:12:15 -0700 (PDT)
Received: by wibud3 with SMTP id ud3so132588697wib.0 for <video-codec@ietf.org>; Tue, 21 Jul 2015 09:12:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=DEWZcRpFuWgTpnVzNTmcDr0q5M/C3D/6xks/fLWr9K0=; b=SUmiEdi93mC8Vib5cQGmWGTa6TcSI1L4CoSDGoz7gh0GF09y15lKqyiDcsgG6l4UfY 5geT1p93fWTcGMhU96e3ikgzrYOaeQY5Dj+YVpw8BQFbrmzx8WZciruplOnhpvVPIbev UTolrRtWDgpgelCP99itvxsuzI4F50Es/8c3RYwP+/k873okkJybKjSiQApXxx6uAV/8 /Ehubs3Bgid8GvnGQI6ieTohqiCHqPKs0XGx8MPO/B904ALPOTDAHKqyabG1zjg+ajOM R+Kn6wAVFCg+TPYiVwT9o9BNlXVvzznUbUfzVwnpEo1GEqitAh8/B1TUzxrKPiU2yp+i yFhw==
X-Gm-Message-State: ALoCoQmvtSE6298rITy+JOfY/rAxD1mrMi3jIMPBmNXHVUEAwDCk989EP2+BiufyhFCRzBJACWy8
X-Received: by 10.194.93.198 with SMTP id cw6mr71129476wjb.113.1437495133805;  Tue, 21 Jul 2015 09:12:13 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:168:7e7a:91ff:fe9e:8126? ([2001:67c:370:168:7e7a:91ff:fe9e:8126]) by smtp.gmail.com with ESMTPSA id qq1sm37762538wjc.0.2015.07.21.09.12.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jul 2015 09:12:12 -0700 (PDT)
To: "Ali C. Begen (abegen)" <abegen@cisco.com>, "video-codec@ietf.org" <video-codec@ietf.org>
References: <32AA73C5-0D17-4ECE-A02D-041C5147D9E5@cisco.com> <55AE60D0.3040201@mozilla.com> <29BD22C6-8790-451B-B754-ED55D2F41C90@cisco.com>
From: Thomas Daede <tdaede@mozilla.com>
Message-ID: <55AE6F5C.8000805@mozilla.com>
Date: Tue, 21 Jul 2015 18:12:12 +0200
User-Agent: http://a.pomf.se/cszdno.opus
MIME-Version: 1.0
In-Reply-To: <29BD22C6-8790-451B-B754-ED55D2F41C90@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/DdVOSqbEbJx0UcxvyvmmxAAJ6Vk>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Jul 2015 16:12:17 -0000

>> - All of the use cases should specify either a high latency or low
>> latency requirement.
> 
> And where is the borderline?

What is a borderline use case? I would much rather keep the number of
configurations as low as possible.

> I still argue iptv should be removed entirely.

I would be fine with this. If it stays, it needs a much clearer use case
definition.

Thomas


From nobody Tue Jul 21 09:15:03 2015
Return-Path: <abegen@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 211FE1A8AAB for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 09:15:02 -0700 (PDT)
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 4OCPM9ZWxspE for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 09:14:58 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB2C1A0110 for <video-codec@ietf.org>; Tue, 21 Jul 2015 09:14:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=712; q=dns/txt; s=iport; t=1437495297; x=1438704897; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/ljKjR7Wc80CTOsLFE7+pYuSlBxtqBSw8FzkJvafYF4=; b=bIrvwpnNtpvYabZ8X5ilW6W789Am4TyXm9DceYASWnbY/h7GlT9HewzC R+iHNL0wwVfYCUaQAMsuyw4+tIKCjHZtcqbEs2tkhOYkhLTrGlZTgePH6 QBwmMq4oueFNbCCuc6EnuaJYjgKDXAxUsht0TYulzFuv0hcRDGUNgO5Rj E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ACBQAcb65V/4QNJK1cgxOBPQa8E4d2AhyBHjoSAQEBAQEBAYEKhCMBAQEEIxFRBAIBCA4DAwECAwImAgICMBUICAIEARKILrVAlkABAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSKKKoUNBoJiL4EUAQSUUwGMKZkOJoN8b4FHgQQBAQE
X-IronPort-AV: E=Sophos;i="5.15,517,1432598400"; d="scan'208";a="13649073"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP; 21 Jul 2015 16:14:57 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t6LGEviL029566 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jul 2015 16:14:57 GMT
Received: from xmb-aln-x01.cisco.com ([169.254.2.64]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Tue, 21 Jul 2015 11:14:57 -0500
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: Thomas Daede <tdaede@mozilla.com>, "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: [video-codec] draft-filippov-netvc-requirements-01
Thread-Index: AQHQw8CyW0GCvpXJZECxIZTezzBngJ3mWvkAgAApqwD//+esAIAAIksA
Date: Tue, 21 Jul 2015 16:14:56 +0000
Message-ID: <48DABB00-F56E-4725-B4FB-F0F91857CA1A@cisco.com>
References: <32AA73C5-0D17-4ECE-A02D-041C5147D9E5@cisco.com> <55AE60D0.3040201@mozilla.com> <29BD22C6-8790-451B-B754-ED55D2F41C90@cisco.com> <55AE6F5C.8000805@mozilla.com>
In-Reply-To: <55AE6F5C.8000805@mozilla.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.150701
x-originating-ip: [10.61.108.86]
Content-Type: text/plain; charset="utf-8"
Content-ID: <2A62C90DB6224C4997FEB230F2CF32AF@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/P5yWQUlXRzLeGPougBbaKWzXhpg>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Jul 2015 16:15:02 -0000

DQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBUaG9tYXMgRGFlZGUN
CkRhdGU6IFR1ZXNkYXksIEp1bHkgMjEsIDIwMTUgYXQgNjoxMiBQTQ0KVG86ICJBbGkgQy4gQmVn
ZW4iLCAidmlkZW8tY29kZWNAaWV0Zi5vcmciDQpTdWJqZWN0OiBSZTogW3ZpZGVvLWNvZGVjXSBk
cmFmdC1maWxpcHBvdi1uZXR2Yy1yZXF1aXJlbWVudHMtMDENCg0KPj4+LSBBbGwgb2YgdGhlIHVz
ZSBjYXNlcyBzaG91bGQgc3BlY2lmeSBlaXRoZXIgYSBoaWdoIGxhdGVuY3kgb3IgbG93DQo+Pj5s
YXRlbmN5IHJlcXVpcmVtZW50Lg0KPj5BbmQgd2hlcmUgaXMgdGhlIGJvcmRlcmxpbmU/DQo+DQo+
V2hhdCBpcyBhIGJvcmRlcmxpbmUgdXNlIGNhc2U/IEkgd291bGQgbXVjaCByYXRoZXIga2VlcCB0
aGUgbnVtYmVyIG9mDQo+Y29uZmlndXJhdGlvbnMgYXMgbG93IGFzIHBvc3NpYmxlLg0KDQpJIG1l
YW4gd2hhdCBpcyBsb3cgbGF0ZW5jeSB2cyBoaWdoIGxhdGVuY3kuIEFuZCB3aG8gZGVjaWRlcyB0
aGF0Pw0K


From nobody Tue Jul 21 09:18:37 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 2D4F91B2F98 for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 09:18:35 -0700 (PDT)
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 UTQMbKf8xwod for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 09:18:32 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (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 C2F401B2FAC for <video-codec@ietf.org>; Tue, 21 Jul 2015 09:18:27 -0700 (PDT)
Received: by wibud3 with SMTP id ud3so132861166wib.0 for <video-codec@ietf.org>; Tue, 21 Jul 2015 09:18:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=bUeDFYk+ppq810xo4tlnH1mIaDIMdGTHlqhO54DiOwQ=; b=AwPz9+TyLvhr7idEU/zC5jipULur/+0rLP6gzDnQYPWNfm8QbbMxdeGwdJlSxobEfb Am8uNwpSC/iJL0BoYPbtLA4qZ5ON8XMNVdJb8FNLuwH0FYh8YFdXLqDZh9ZK4CDmuiG/ ym6aocjLxsFXF9bLWaNayZkTG4wFQVdQv/Du+jPfxXiDOb4QvlHHXRifhZo2WzKsVQ47 HVVLPG5FrjANLVJrFxDxzFnSavGmqYNLOfH0GruU4VzgxpDI6beTsY1X2QASWbmXxLv/ ern1RijuWCig+fqI3q/72VMNJfOmAc8l6fLYiAWG1vaeZT1x62TpiuM0X5iSignTd5vM szkg==
X-Gm-Message-State: ALoCoQkT8mqOady8NuNhsc6DFVp6MNbnt76UltKMmUgjhPGseQCPaoMHObxAnGCx3CKWcw1WJLfs
X-Received: by 10.194.192.72 with SMTP id he8mr69208077wjc.11.1437495506499; Tue, 21 Jul 2015 09:18:26 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:168:7e7a:91ff:fe9e:8126? ([2001:67c:370:168:7e7a:91ff:fe9e:8126]) by smtp.gmail.com with ESMTPSA id df1sm17571696wib.12.2015.07.21.09.18.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jul 2015 09:18:26 -0700 (PDT)
To: "Ali C. Begen (abegen)" <abegen@cisco.com>, "video-codec@ietf.org" <video-codec@ietf.org>
References: <32AA73C5-0D17-4ECE-A02D-041C5147D9E5@cisco.com> <55AE60D0.3040201@mozilla.com> <29BD22C6-8790-451B-B754-ED55D2F41C90@cisco.com>
From: Thomas Daede <tdaede@mozilla.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <55AE70D1.3020902@mozilla.com>
Date: Tue, 21 Jul 2015 18:18:25 +0200
User-Agent: http://a.pomf.se/cszdno.opus
MIME-Version: 1.0
In-Reply-To: <29BD22C6-8790-451B-B754-ED55D2F41C90@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/k_dsNYTUZIicRY16btc5D4QcjwE>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Jul 2015 16:18:35 -0000

On 07/21/2015 05:39 PM, Ali C. Begen (abegen) wrote:
>> I think that this would dangerously narrow the adoption of the codec.
>> Would Opus have done nearly as well if it was only SILK?
> 
> And please tell me where Opus is used in the entertainment world?

Youtube uses Opus in DASH. WebM defines VP9/Opus as one of its standard
profiles.

But not to get sidetracked, I want to clarify that I want NETVC to
produce something that is acceptable for the <video> tag or DASH.
Bluray, non-end-user usage, etc is totally out of scope.


From nobody Tue Jul 21 09:21:09 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 99E621A1BC6 for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 09:21:07 -0700 (PDT)
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 eRpaL2E7JwJs for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 09:21:05 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (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 4AF021A0AF8 for <video-codec@ietf.org>; Tue, 21 Jul 2015 09:21:05 -0700 (PDT)
Received: by wicmv11 with SMTP id mv11so46400395wic.0 for <video-codec@ietf.org>; Tue, 21 Jul 2015 09:21:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=5h/G6KOjgbFKdNLMlaB0TX1Yyd9CcDzw8I3/e8z1Ir4=; b=kUdYjH2uZlp7X0NPflgdAVHctvBJYklN2u5POwqirI3rIYt6ckS4aqLp0/xsUkiJft jZJOsQD56ePtkMMZNADU9YNZ/DXSOyS7ISP/ynegNpDJsuFVcdbzS+YcQkVfBagDbOy0 q0Sahjcpiq0dlZAz06Gdw+3X7vC/hRotx7DI2HLyQ5dPFAbQZkkkvkx9g5N5XabenVjF tKvErr99+Rh4d1Ab8PegsE8PwCft8dh+GwC/AcPTqYXXab82Rh5ll+YO4DRDdcQ5ddKn zPaDhFg0PNwt5CquBhwqor7CrpAMhdFHrfe3NxebSuE5oiG9QFiSsZjcy3a3+RdZJky4 LY9Q==
X-Gm-Message-State: ALoCoQlVJT4AqNuUg6Hv0Z9gP2xuoFAWRL347cN4hQ8hA/DKrOD276/NgvZhtQdu5Xr0qj/9ghAI
X-Received: by 10.180.94.168 with SMTP id dd8mr33370080wib.76.1437495663999; Tue, 21 Jul 2015 09:21:03 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:168:7e7a:91ff:fe9e:8126? ([2001:67c:370:168:7e7a:91ff:fe9e:8126]) by smtp.gmail.com with ESMTPSA id d17sm37756473wjs.32.2015.07.21.09.21.03 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jul 2015 09:21:03 -0700 (PDT)
To: "Ali C. Begen (abegen)" <abegen@cisco.com>, "video-codec@ietf.org" <video-codec@ietf.org>
References: <32AA73C5-0D17-4ECE-A02D-041C5147D9E5@cisco.com> <55AE60D0.3040201@mozilla.com> <29BD22C6-8790-451B-B754-ED55D2F41C90@cisco.com> <55AE6F5C.8000805@mozilla.com> <48DABB00-F56E-4725-B4FB-F0F91857CA1A@cisco.com>
From: Thomas Daede <tdaede@mozilla.com>
Message-ID: <55AE716E.8090305@mozilla.com>
Date: Tue, 21 Jul 2015 18:21:02 +0200
User-Agent: http://a.pomf.se/cszdno.opus
MIME-Version: 1.0
In-Reply-To: <48DABB00-F56E-4725-B4FB-F0F91857CA1A@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/3SqoKaSYzMryCTv8bY4qrZkrXLA>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Jul 2015 16:21:07 -0000

On 07/21/2015 06:14 PM, Ali C. Begen (abegen) wrote:

>>>> - All of the use cases should specify either a high latency or low
>>>> latency requirement.
>>> And where is the borderline?
>>
>> What is a borderline use case? I would much rather keep the number of
>> configurations as low as possible.
> 
> I mean what is low latency vs high latency. And who decides that?
> 

It is defined in draft-daede-netvc-testing-01 [1]. And some of the
definition should probably be moved into the requirements draft, though
individual codec parameters still belong in the testing draft.

https://datatracker.ietf.org/doc/draft-daede-netvc-testing/


From nobody Tue Jul 21 09:25:23 2015
Return-Path: <abegen@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 005DC1A8ABC for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 09:25:23 -0700 (PDT)
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 lD5V2Vstl9Mx for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 09:25:21 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B29151A8A1F for <video-codec@ietf.org>; Tue, 21 Jul 2015 09:25:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1644; q=dns/txt; s=iport; t=1437495921; x=1438705521; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=15I6fuPU4GSMrnGocuJ282z3yf3VZY72IzmHcmZvgYk=; b=Jj7Bwaiv50NLHyEtpdtReMT9Zaui0siAd/gzsQyJuhY/8PDT7uoJvvnO OdyFS7C5HTjyczEb5ix4ZbCnGzykKWmIrzqRzHvq4nGLbn8ULtVTLDlIs Nh4PzIvBNbKdQYDCqJatI0H5EIcvWGwzDIM15Ha+3uxFSdEyTEOWFV/En 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADBQD9cK5V/4UNJK1cgxOBPQbECQIcgR47EQEBAQEBAQGBCoQjAQEBBCMRUQQCAQgOAwMBAgECAiYCAgIwFQgIAgQBEogutU6WPAEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIooqhFMYIgaCYi+BFAWUUwGMKYFDhByTLyaDfG+BR4EEAQEB
X-IronPort-AV: E=Sophos;i="5.15,517,1432598400"; d="scan'208";a="170968664"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jul 2015 16:25:21 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t6LGPKm3001306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jul 2015 16:25:21 GMT
Received: from xmb-aln-x01.cisco.com ([169.254.2.64]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Tue, 21 Jul 2015 11:25:20 -0500
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: Thomas Daede <tdaede@mozilla.com>, "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: [video-codec] draft-filippov-netvc-requirements-01
Thread-Index: AQHQw8CyW0GCvpXJZECxIZTezzBngJ3mWvkAgAApqwD//+lpgIAAI3YA
Date: Tue, 21 Jul 2015 16:25:20 +0000
Message-ID: <AA781197-CB07-4D59-BB4D-CC7BC490E819@cisco.com>
References: <32AA73C5-0D17-4ECE-A02D-041C5147D9E5@cisco.com> <55AE60D0.3040201@mozilla.com> <29BD22C6-8790-451B-B754-ED55D2F41C90@cisco.com> <55AE70D1.3020902@mozilla.com>
In-Reply-To: <55AE70D1.3020902@mozilla.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.150701
x-originating-ip: [10.61.108.86]
Content-Type: text/plain; charset="utf-8"
Content-ID: <A0FE87448356564DA2E9DEFB09E84C41@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/1d8MmGP9ZKuJ4Uoq4a9cMIxhIsE>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Jul 2015 16:25:23 -0000

DQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBUaG9tYXMgRGFlZGUN
CkRhdGU6IFR1ZXNkYXksIEp1bHkgMjEsIDIwMTUgYXQgNjoxOCBQTQ0KVG86ICJBbGkgQy4gQmVn
ZW4iLCAidmlkZW8tY29kZWNAaWV0Zi5vcmciDQpTdWJqZWN0OiBSZTogW3ZpZGVvLWNvZGVjXSBk
cmFmdC1maWxpcHBvdi1uZXR2Yy1yZXF1aXJlbWVudHMtMDENCg0KPk9uIDA3LzIxLzIwMTUgMDU6
MzkgUE0sIEFsaSBDLiBCZWdlbiAoYWJlZ2VuKSB3cm90ZToNCj4+PiBJIHRoaW5rIHRoYXQgdGhp
cyB3b3VsZCBkYW5nZXJvdXNseSBuYXJyb3cgdGhlIGFkb3B0aW9uIG9mIHRoZSBjb2RlYy4NCj4+
PiBXb3VsZCBPcHVzIGhhdmUgZG9uZSBuZWFybHkgYXMgd2VsbCBpZiBpdCB3YXMgb25seSBTSUxL
Pw0KPj4gDQo+PiBBbmQgcGxlYXNlIHRlbGwgbWUgd2hlcmUgT3B1cyBpcyB1c2VkIGluIHRoZSBl
bnRlcnRhaW5tZW50IHdvcmxkPw0KPg0KPllvdXR1YmUgdXNlcyBPcHVzIGluIERBU0guIFdlYk0g
ZGVmaW5lcyBWUDkvT3B1cyBhcyBvbmUgb2YgaXRzIHN0YW5kYXJkDQo+cHJvZmlsZXMuDQoNCllv
dXR1YmUgY3JlYXRlcyBhIGxvdCBvZiB0cmFmZmljIGFuZCBJIHN1cHBvc2UgYSBsYXJnZSBwb3J0
aW9uIG9mIGl0IGlzIHZwOS9vcHVzIGJ1dCA5OS45JSBvZiB0aGUgeW91dHViZSB2aWRlbyBpcyBu
b3Qgc29tZXRoaW5nIEkgd291bGQgY29uc2lkZXIg4oCcZW50ZXJ0YWlubWVudCBncmFkZeKAnS4g
RG9udCBnZXQgbWUgd3JvbmcsIGJ1dCB3aGVuIHlvdSBsb29rIGF0IENFIGRldmljZXMgdGhhdCBj
b25zdW1lIHN0cmVhbWluZyB2aWRlbywgdnA5L29wdXMgaXMgbm90IG9uIHRoZSB0b3Agb2YgdGhl
IGxpc3QuDQoNCj4NCj5CdXQgbm90IHRvIGdldCBzaWRldHJhY2tlZCwgSSB3YW50IHRvIGNsYXJp
ZnkgdGhhdCBJIHdhbnQgTkVUVkMgdG8NCj5wcm9kdWNlIHNvbWV0aGluZyB0aGF0IGlzIGFjY2Vw
dGFibGUgZm9yIHRoZSA8dmlkZW8+IHRhZyBvciBEQVNILg0KDQpEQVNIIGlzIGNvZGVjIGFnbm9z
dGljLCBzbyBpdCBkb2VzIG5vdCBjYXJlLiBXaGV0aGVyIHNvbWVvbmUgd2lsbCB1c2UgbmV0dmMg
Zm9yIERBU0gsIEkgYW0gbm90IGhvbGRpbmcgbXkgYnJlYXRoLiANCg0KPkJsdXJheSwgbm9uLWVu
ZC11c2VyIHVzYWdlLCBldGMgaXMgdG90YWxseSBvdXQgb2Ygc2NvcGUuDQoNCkNlcnRhaW5seS4N
Cg==


From nobody Tue Jul 21 09:28:37 2015
Return-Path: <abegen@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 D02CF1B2F9B for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 09:28:35 -0700 (PDT)
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 deXQ72OZDmWm for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 09:28:34 -0700 (PDT)
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 48EC01B2FA9 for <video-codec@ietf.org>; Tue, 21 Jul 2015 09:28:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1372; q=dns/txt; s=iport; t=1437496111; x=1438705711; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=mUp+1dpgKsaNzk1GUBT3VQuUoodNrDP+yiD6J320DyI=; b=mJvPvyBi9p0Yj//pDgh/4jlsgQbtzEv9S9ai3kTAeQqafGXFtiYjkw75 TbGSNyPeNqywrjdqhg9oS+CJDI3rXlX6tZE81gyrvXEnLZDNnYCLL9x3V TDF6dbaUGuqh0Bv2AisiiPR0CyzpjpoCS6aNxUJiNjPS4ywiEPp/ukZt+ M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AhAwC1cq5V/5xdJa1cgxNUaQa8CgmBdYYBAhyBHjgUAQEBAQEBAYEKhCMBAQEEIxFRBAIBCA4DAwECAQICJgICAjAVCAgCBAESiC4NtUWWOgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSKKKoRTGCIGgmIvgRQFlFMBhHSHNZkOJoN8b4FHgQQBAQE
X-IronPort-AV: E=Sophos;i="5.15,517,1432598400"; d="scan'208";a="170850186"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP; 21 Jul 2015 16:28:30 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t6LGSUBr003747 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jul 2015 16:28:30 GMT
Received: from xmb-aln-x01.cisco.com ([169.254.2.64]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0195.001; Tue, 21 Jul 2015 11:28:30 -0500
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: Thomas Daede <tdaede@mozilla.com>, "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: [video-codec] draft-filippov-netvc-requirements-01
Thread-Index: AQHQw8CyW0GCvpXJZECxIZTezzBngJ3mWvkAgAApqwD//+esAIAAIksA///gLQCAACOdAA==
Date: Tue, 21 Jul 2015 16:28:30 +0000
Message-ID: <8E255F2B-E72A-4634-A6AB-335C77BE2448@cisco.com>
References: <32AA73C5-0D17-4ECE-A02D-041C5147D9E5@cisco.com> <55AE60D0.3040201@mozilla.com> <29BD22C6-8790-451B-B754-ED55D2F41C90@cisco.com> <55AE6F5C.8000805@mozilla.com> <48DABB00-F56E-4725-B4FB-F0F91857CA1A@cisco.com> <55AE716E.8090305@mozilla.com>
In-Reply-To: <55AE716E.8090305@mozilla.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.150701
x-originating-ip: [10.61.108.86]
Content-Type: text/plain; charset="utf-8"
Content-ID: <ED5CA0D8656598419BBE54299DCADC7B@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/E9mPaEXdsqLSKJXOaG7iyOPeutA>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Jul 2015 16:28:36 -0000

DQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBUaG9tYXMgRGFlZGUN
CkRhdGU6IFR1ZXNkYXksIEp1bHkgMjEsIDIwMTUgYXQgNjoyMSBQTQ0KVG86ICJBbGkgQy4gQmVn
ZW4iLCAidmlkZW8tY29kZWNAaWV0Zi5vcmciDQpTdWJqZWN0OiBSZTogW3ZpZGVvLWNvZGVjXSBk
cmFmdC1maWxpcHBvdi1uZXR2Yy1yZXF1aXJlbWVudHMtMDENCg0KPk9uIDA3LzIxLzIwMTUgMDY6
MTQgUE0sIEFsaSBDLiBCZWdlbiAoYWJlZ2VuKSB3cm90ZToNCj4NCj4+Pj4+IC0gQWxsIG9mIHRo
ZSB1c2UgY2FzZXMgc2hvdWxkIHNwZWNpZnkgZWl0aGVyIGEgaGlnaCBsYXRlbmN5IG9yIGxvdw0K
Pj4+Pj4gbGF0ZW5jeSByZXF1aXJlbWVudC4NCj4+Pj4gQW5kIHdoZXJlIGlzIHRoZSBib3JkZXJs
aW5lPw0KPj4+DQo+Pj4gV2hhdCBpcyBhIGJvcmRlcmxpbmUgdXNlIGNhc2U/IEkgd291bGQgbXVj
aCByYXRoZXIga2VlcCB0aGUgbnVtYmVyIG9mDQo+Pj4gY29uZmlndXJhdGlvbnMgYXMgbG93IGFz
IHBvc3NpYmxlLg0KPj4gDQo+PiBJIG1lYW4gd2hhdCBpcyBsb3cgbGF0ZW5jeSB2cyBoaWdoIGxh
dGVuY3kuIEFuZCB3aG8gZGVjaWRlcyB0aGF0Pw0KPj4gDQo+DQo+SXQgaXMgZGVmaW5lZCBpbiBk
cmFmdC1kYWVkZS1uZXR2Yy10ZXN0aW5nLTAxIFsxXS4gQW5kIHNvbWUgb2YgdGhlDQo+ZGVmaW5p
dGlvbiBzaG91bGQgcHJvYmFibHkgYmUgbW92ZWQgaW50byB0aGUgcmVxdWlyZW1lbnRzIGRyYWZ0
LCB0aG91Z2gNCj5pbmRpdmlkdWFsIGNvZGVjIHBhcmFtZXRlcnMgc3RpbGwgYmVsb25nIGluIHRo
ZSB0ZXN0aW5nIGRyYWZ0Lg0KPg0KPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry
YWZ0LWRhZWRlLW5ldHZjLXRlc3RpbmcvDQoNCkkgc2VhcmNoZWQgZm9yIGxhdGVuY3kgYW5kIGRl
bGF5LCBub3RoaW5nIHNob3dlZCB1cC4gVGhlIG9ubHkgdGltZSByZWxhdGVkIG51bWJlciBzZWVt
cyB0byBiZSAzMDBtcyBpbiBzZWN0aW9uIDUuMy4NCg==


From nobody Tue Jul 21 09:33:58 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 BAF731B2FD5 for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 09:33:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.977
X-Spam-Level: 
X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, 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 LvrPoXZmXZ7B for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 09:33:51 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (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 D76611A8ABC for <video-codec@ietf.org>; Tue, 21 Jul 2015 09:33:51 -0700 (PDT)
Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 9138FC1B36 for <video-codec@ietf.org>; Tue, 21 Jul 2015 16:33:51 +0000 (UTC)
X-Virus-Scanned: amavisd-new at mozilla.org
Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gyd1aWPiEFkV for <video-codec@ietf.org>; Tue, 21 Jul 2015 16:33:51 +0000 (UTC)
Received: from [31.133.169.52] (dhcp-a934.meeting.ietf.org [31.133.169.52]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 0206CC1894 for <video-codec@ietf.org>; Tue, 21 Jul 2015 16:33:50 +0000 (UTC)
Message-ID: <55AE746D.8070806@xiph.org>
Date: Tue, 21 Jul 2015 09:33:49 -0700
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" <video-codec@ietf.org>
References: <32AA73C5-0D17-4ECE-A02D-041C5147D9E5@cisco.com> <55AE60D0.3040201@mozilla.com> <29BD22C6-8790-451B-B754-ED55D2F41C90@cisco.com> <55AE70D1.3020902@mozilla.com> <AA781197-CB07-4D59-BB4D-CC7BC490E819@cisco.com>
In-Reply-To: <AA781197-CB07-4D59-BB4D-CC7BC490E819@cisco.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/6LyDgi5n2D-1_YodQCM4GElKZ58>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Jul 2015 16:33:55 -0000

Ali C. Begen (abegen) wrote:
>>> And please tell me where Opus is used in the entertainment world?
>>
>> Youtube uses Opus in DASH. WebM defines VP9/Opus as one of its standard
>> profiles.
>
> Youtube creates a lot of traffic and I suppose a large portion of it is vp9/opus but 99.9% of the youtube video is not something I would consider “entertainment grade”. Dont get me wrong, but when you look at CE devices that consume streaming video, vp9/opus is not on the top of the list.

It's still #3 on the Alexa Top 500 global sites.

Also #7 Wikipedia: 
https://commons.wikimedia.org/wiki/Commons:File_types#Sound

Broadcast:
http://www.tieline.com/products/G5/Merlin
http://www.gatesair.com/products/transport/audio-contribution-distribution/intraplex-ip-link
http://www.comrex.com/products/briclinkII.html
http://www.obe.tv/about-us/obe-blog/item/14-using-opus-audio-in-broadcasting
http://ebu.io/opensource#codecs

Internet radio:
http://lists.xiph.org/pipermail/icecast/2012-July/012237.html

Wireless headphones and mics:
http://www.dialog-semiconductor.com/products/audio-wireless-voice/smartbeat-wireless-audio

Video games:
Opus is included in the Playstation 4, FMOD (used in many games), and 
others.

There are probably lots more. One of the benefits of being completely 
open is that no one has to tell me when they start using Opus.


From nobody Tue Jul 21 09:36: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 E55D21A9061 for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 09:36:30 -0700 (PDT)
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 lA_uUqwrMZxg for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 09:36:29 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F4FE1A8A39 for <video-codec@ietf.org>; Tue, 21 Jul 2015 09:36:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1499; q=dns/txt; s=iport; t=1437496589; x=1438706189; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=O1IiG23Yz+gIARb71AI5yYi83UPUV/P8OTx0eADLFYM=; b=MU/rYydo7Adq3sspQl4Un2FL2Dh0FShblazjLL0L62CAIacbap0Ssuz4 SW7ClcPhDtw/axAUYD4ODCX9518KB6Yxbsvp8lcNGTVDdK9G8XgWkgy8i c7WYgPWMYbtcEnXbBdvRSZVyc8zcHfNe/FCDzPuyf2uJ62CJ9pMmiUTmy k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AEBQAMdK5V/4oNJK1cgxNUWg+8GYFrCoYBAoE7ORMBAQEBAQEBgQqEIwEBAQMBAQEBNzQLBQcEAgEIEQMBAgEeECcLHQgCBA4FiCYIDcwHAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLTIRTMwcGgxGBFAWUUwGEdIc1mQ4mg3xvgksBAQE
X-IronPort-AV: E=Sophos;i="5.15,517,1432598400"; d="scan'208";a="11750003"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-8.cisco.com with ESMTP; 21 Jul 2015 16:36:28 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t6LGaS0n031627 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jul 2015 16:36:28 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.112]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Tue, 21 Jul 2015 11:36:28 -0500
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>
Thread-Topic: [video-codec] draft-filippov-netvc-requirements-01
Thread-Index: AQHQw8CyW0GCvpXJZECxIZTezzBngJ3mWvkAgAApqwD//+esAIAAIksA///gLQCAACOdAP//jOHb
Date: Tue, 21 Jul 2015 16:36:27 +0000
Message-ID: <2DECBC26-B567-420F-93EC-447E9B61169E@cisco.com>
References: <32AA73C5-0D17-4ECE-A02D-041C5147D9E5@cisco.com> <55AE60D0.3040201@mozilla.com> <29BD22C6-8790-451B-B754-ED55D2F41C90@cisco.com> <55AE6F5C.8000805@mozilla.com> <48DABB00-F56E-4725-B4FB-F0F91857CA1A@cisco.com> <55AE716E.8090305@mozilla.com>, <8E255F2B-E72A-4634-A6AB-335C77BE2448@cisco.com>
In-Reply-To: <8E255F2B-E72A-4634-A6AB-335C77BE2448@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/4J28n7s5yDwdjJrhTvDAEnkSCK0>
Cc: "video-codec@ietf.org" <video-codec@ietf.org>, Thomas Daede <tdaede@mozilla.com>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Jul 2015 16:36:31 -0000

300 ms (* bitrate) refers to the rate control buffer not coding latency.=20

I think the testing draft should define low latency as zero frame delay, i.=
e. no reordering. The high latency condition can be unrestricted.=20

Mo (as individual)

On Jul 21, 2015, at 6:28 PM, Ali C. Begen (abegen) <abegen@cisco.com> wrote=
:






-----Original Message-----
From: Thomas Daede
Date: Tuesday, July 21, 2015 at 6:21 PM
To: "Ali C. Begen", "video-codec@ietf.org"
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01

> On 07/21/2015 06:14 PM, Ali C. Begen (abegen) wrote:
>=20
>>>>> - All of the use cases should specify either a high latency or low
>>>>> latency requirement.
>>>> And where is the borderline?
>>>=20
>>> What is a borderline use case? I would much rather keep the number of
>>> configurations as low as possible.
>>=20
>> I mean what is low latency vs high latency. And who decides that?
>=20
> It is defined in draft-daede-netvc-testing-01 [1]. And some of the
> definition should probably be moved into the requirements draft, though
> individual codec parameters still belong in the testing draft.
>=20
> https://datatracker.ietf.org/doc/draft-daede-netvc-testing/

I searched for latency and delay, nothing showed up. The only time related =
number seems to be 300ms in section 5.3.
_______________________________________________
video-codec mailing list
video-codec@ietf.org
https://www.ietf.org/mailman/listinfo/video-codec


From nobody Tue Jul 21 10:10:19 2015
Return-Path: <abegen@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 320ED1B2F5A for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 10:10:18 -0700 (PDT)
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 gnTHwSs4aYvj for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 10:10:14 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E7D1B2BBB for <video-codec@ietf.org>; Tue, 21 Jul 2015 10:10:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2528; q=dns/txt; s=iport; t=1437498614; x=1438708214; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=e0xocRHAfOFceRtqeEfRCCMHraL/++9NXrF2oolCBbU=; b=EDNc/8ywLGSrYqrfsMLmVscdooiP5efhUD6ywUr73PiVu7YkxVqTY92a Tl0gKFYA6/k9DNL02klZT0v4SZUMwIPckMLrT0yNM5BXrlndkUrLfjWb9 Hu9++ME1raF+Xd1iCGA3/YpQA3QLLPd6WVXAiEP22zoHEqRGzpSLMZOvt w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BrBQAUfK5V/4gNJK1cgxNUabsYgQGBawyFfwKBOzoSAQEBAQEBAYEKhCMBAQEDAQEBAWsLBQsCAQgYLicBCiUCBA4FiCYIDct+AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tMhFMzAgWDF4EUBZRTAYR0hF6CV4FDRoNWj06DYSaCDRyBU28BgkoBAQE
X-IronPort-AV: E=Sophos;i="5.15,517,1432598400"; d="scan'208";a="13682952"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-4.cisco.com with ESMTP; 21 Jul 2015 17:10:13 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t6LHADdK001515 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jul 2015 17:10:13 GMT
Received: from xmb-aln-x01.cisco.com ([169.254.2.64]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Tue, 21 Jul 2015 12:10:13 -0500
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: "Timothy B. Terriberry" <tterribe@xiph.org>
Thread-Topic: [video-codec] draft-filippov-netvc-requirements-01
Thread-Index: AQHQw8CyW0GCvpXJZECxIZTezzBngJ3mWvkAgAApqwD//+lpgIAAI3YA///g2ID//7ZZDw==
Date: Tue, 21 Jul 2015 17:10:12 +0000
Message-ID: <6783B69D-9FB7-4634-9382-25857D3FD6CE@cisco.com>
References: <32AA73C5-0D17-4ECE-A02D-041C5147D9E5@cisco.com> <55AE60D0.3040201@mozilla.com> <29BD22C6-8790-451B-B754-ED55D2F41C90@cisco.com> <55AE70D1.3020902@mozilla.com> <AA781197-CB07-4D59-BB4D-CC7BC490E819@cisco.com>,<55AE746D.8070806@xiph.org>
In-Reply-To: <55AE746D.8070806@xiph.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/EI8QAPCcqeASuLYQFLcHDHA0yuM>
Cc: "video-codec@ietf.org" <video-codec@ietf.org>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Jul 2015 17:10:18 -0000

Sorry your links do not prove much. When you use a vpX or opus enabled devi=
ce or browser youtube most likely sends the content with those codecs. But =
the world has many other devices or browsers  that are not capable of rende=
ring them so...

I did not mean to create a codec discussion but looks like it is to late to=
 revert back. Opus is a great codec and it is widely used but only under ce=
rtain apps and conditions. But there are lots of other codecs that it will =
never replace.  I hope netvc will be equally or even more successful.  But =
again there will be other codecs that it will never replace nor it should. =
So my point is we should focus on where we have the highest chance to succe=
ed in a reasonable time frame.=20

-acbegen=20
Sent using iThumbs - DYAC

> On Jul 21, 2015, at 6:34 PM, Timothy B. Terriberry <tterribe@xiph.org> wr=
ote:
>=20
> Ali C. Begen (abegen) wrote:
>>>> And please tell me where Opus is used in the entertainment world?
>>>=20
>>> Youtube uses Opus in DASH. WebM defines VP9/Opus as one of its standard
>>> profiles.
>>=20
>> Youtube creates a lot of traffic and I suppose a large portion of it is =
vp9/opus but 99.9% of the youtube video is not something I would consider =
=93entertainment grade=94. Dont get me wrong, but when you look at CE devic=
es that consume streaming video, vp9/opus is not on the top of the list.
>=20
> It's still #3 on the Alexa Top 500 global sites.
>=20
> Also #7 Wikipedia: https://commons.wikimedia.org/wiki/Commons:File_types#=
Sound
>=20
> Broadcast:
> http://www.tieline.com/products/G5/Merlin
> http://www.gatesair.com/products/transport/audio-contribution-distributio=
n/intraplex-ip-link
> http://www.comrex.com/products/briclinkII.html
> http://www.obe.tv/about-us/obe-blog/item/14-using-opus-audio-in-broadcast=
ing
> http://ebu.io/opensource#codecs
>=20
> Internet radio:
> http://lists.xiph.org/pipermail/icecast/2012-July/012237.html
>=20
> Wireless headphones and mics:
> http://www.dialog-semiconductor.com/products/audio-wireless-voice/smartbe=
at-wireless-audio
>=20
> Video games:
> Opus is included in the Playstation 4, FMOD (used in many games), and oth=
ers.
>=20
> There are probably lots more. One of the benefits of being completely ope=
n is that no one has to tell me when they start using Opus.
>=20
> _______________________________________________
> video-codec mailing list
> video-codec@ietf.org
> https://www.ietf.org/mailman/listinfo/video-codec


From nobody Tue Jul 21 10:19:50 2015
Return-Path: <Alexey.Filippov@huawei.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 06CEF1A1A66 for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 10:19:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 p2tW87REYxRy for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 10:19:46 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50EFB1A1B61 for <video-codec@ietf.org>; Tue, 21 Jul 2015 10:19:30 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYZ93783; Tue, 21 Jul 2015 17:19:28 +0000 (GMT)
Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 21 Jul 2015 18:19:14 +0100
Received: from SZXEMA508-MBS.china.huawei.com ([169.254.8.36]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0158.001; Wed, 22 Jul 2015 01:19:02 +0800
From: Filippov Alexey <Alexey.Filippov@huawei.com>
To: "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: Re: [video-codec] draft-filippov-netvc-requirements-01
Thread-Index: AdDD2VSTclZbnnUKQHiwc/xj0lwJmw==
Date: Tue, 21 Jul 2015 17:19:01 +0000
Message-ID: <A95DB243D3936149BBFA3B43ED71074570524AFB@szxema508-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.76.163]
Content-Type: multipart/alternative; boundary="_000_A95DB243D3936149BBFA3B43ED71074570524AFBszxema508mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/mzoD9XeyhsQ7LaoEoivWB46nHis>
Cc: "tdaede at mozilla.com" <tdaede@mozilla.com>, Paul Coverdale <coverdale@sympatico.ca>, "abegen@cisco.com" <abegen@cisco.com>, "mzanaty@cisco.com" <mzanaty@cisco.com>, "tterribe@xiph.org" <tterribe@xiph.org>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Jul 2015 17:19:50 -0000

--_000_A95DB243D3936149BBFA3B43ED71074570524AFBszxema508mbschi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thank you for your feedback.


>Ali C. Begen (abegen) wrote:
>> I understand that part but what I am saying is that developing a codec t=
hat will both perform enough well for interactive video and streaming video=
 is a tedious task. Focusing on two different things will increase the risk=
 of failure for this wg. Maybe the wg should consider solving the first (an=
d the more important) problem first and then see whether it can tackle the =
second problem.
>
>Well, I agree we can probably significantly narrow the set of use cases
>we want to consider, but I think narrowing it down to one is too extreme.

I agree that use cases such as screencasting and game streaming considerabl=
e differ from other. As Mr. Zanaty proposed, a separate profile can be deve=
loped for them in future (if needed). There are two options:
-              I can remove them
-              I can keep them in the draft but I'll explicitly write that =
they don't have a high priority and a separate profile will cover them
I prefer the 2nd option because screencasting and game streaming are use ca=
ses relevant to Internet video codec.



> Maybe the wg should consider solving the first (and the more important) p=
roblem first and then see whether it can tackle the second problem.

Anyway, we should fix the requirements first (maybe making some of them opt=
ional). I guess WG roadmap could be worked out properly but it's the next s=
tep.

>> So IPTV, game streaming and video sharing should be removed from the req=
s document. I am not so sure about video monitoring, though, as it has quit=
e many similarities to interactive video.
>I have many issues with the categories in the requirements draft:
>Fair enough, but then I have to say that I disagree on some of the reqs me=
ntioned in the sections I suggested for removal. Most of them are not even =
reqs but just a collection of what is in the market today. Obviously if tho=
se sections are to stay, they need quite a bit work.

That's true, they need quite a bit of work .  That's what all of us are cur=
rently doing actually.



>- All of the use cases should specify either a high latency or low latency=
 requirement
I agree with it. By default, I assumed high latency. Where a low-delay conf=
iguration is needed, I mentioned it. I can write it explicitly

> And where is the borderline?
The borderline is the necessity of feedback. For example, in the case of vi=
deo conferencing, replies are needed. In the case of IPTV broadcasting, use=
r is switching between channels and doesn't want to wait long enough (more,=
 than 1 sec). If a person selected a movie and wants to watch it, there is =
no reasons for any feedback.



>- Error resilience should be moved out of the use cases. It can be implied=
 by low latency, as can a lot of other things (transport, etc)

I agree that this requirement is caused by the necessity of low-delay confi=
guration. Of course, error resilience mechanisms can be implemented on tran=
sport level but they can be implemented on the codec level as well (e.g., r=
edundant frames). For some use cases, such error resilience mechanisms can =
work more efficiently than error protection on the transport level.  I prop=
ose to consider it as an optional requirements that should be complementary=
 to the mechanisms implemented on the transport level.



>> I still argue iptv should be removed entirely.
>I would be fine with this. If it stays, it needs a much clearer use case d=
efinition.

IPTV is a very popular use case for Internet users. If it will be removed, =
it is reasonable to discuss not an Internet video codec but a codec for int=
eractive video. I agree that use case definition should be described more c=
learly but I disagree that this application should be removed.


>- The big list of resolutions is overly verbose and not necessary. A
>simple range of resolutions and frame rates would be better.

Agreed.

>FWIW, I argue that interlacing should not be considered in this WG (or at =
all for any video codec) moving forward.
Agreed




--_000_A95DB243D3936149BBFA3B43ED71074570524AFBszxema508mbschi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-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-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
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]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Thank you for your feedback.<o:p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"RU"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"RU"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal">&gt;Ali C. Begen (abegen) wrote:<o:p></o:p></p>
<p class=3D"MsoNormal">&gt;&gt; I understand that part but what I am saying=
 is that developing a codec that will both perform enough well for interact=
ive video and streaming video is a tedious task. Focusing on two different =
things will increase the risk of failure
 for this wg. Maybe the wg should consider solving the first (and the more =
important) problem first and then see whether it can tackle the second prob=
lem.<o:p></o:p></p>
<p class=3D"MsoNormal">&gt;<o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">&gt;Well, I agree we can probably significantly narr=
ow the set of use cases
<o:p></o:p></p>
<p class=3D"MsoNormal">&gt;we want to consider, but I think narrowing it do=
wn to one is too extreme.<o:p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"RU"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal">I agree that use cases such as screencasting and gam=
e streaming considerable differ from other. As Mr. Zanaty proposed, a separ=
ate profile can be developed for them in future (if needed). There are two =
options:<o:p></o:p></p>
<p class=3D"MsoNormal">-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; I can remove them<o:p></o:p></p>
<p class=3D"MsoNormal">-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; I can keep them in the draft but I&#8217;ll exp=
licitly write that they don&#8217;t have a high priority and a separate pro=
file will cover them<o:p></o:p></p>
<p class=3D"MsoNormal">I prefer the 2nd option because screencasting and ga=
me streaming are use cases relevant to Internet video codec.<o:p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"RU"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"RU"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"RU"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal">&gt; Maybe the wg should consider solving the first =
(and the more important) problem first and then see whether it can tackle t=
he second problem.<o:p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"RU"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal">Anyway, we should fix the requirements first (maybe =
making some of them optional). I guess WG roadmap could be worked out prope=
rly but it&#8217;s the next step.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">&gt;&gt; So IPTV, game streaming and video sharing s=
hould be removed from the reqs document. I am not so sure about video monit=
oring, though, as it has quite many similarities to interactive video.
<o:p></o:p></p>
<p class=3D"MsoNormal">&gt;I have many issues with the categories in the re=
quirements draft:<o:p></o:p></p>
<p class=3D"MsoNormal">&gt;Fair enough, but then I have to say that I disag=
ree on some of the reqs mentioned in the sections I suggested for removal. =
Most of them are not even reqs but just a collection of what is in the mark=
et today. Obviously if those sections
 are to stay, they need quite a bit work.<o:p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"RU"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal">That&#8217;s true, they need quite a bit of work .&n=
bsp; That&#8217;s what all of us are currently doing actually.&nbsp;
<o:p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"RU"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"RU"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"RU"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal">&gt;- All of the use cases should specify either a h=
igh latency or low latency requirement<o:p></o:p></p>
<p class=3D"MsoNormal">I agree with it. By default, I assumed high latency.=
 Where a low-delay configuration is needed, I mentioned it. I can write it =
explicitly<o:p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"RU"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal">&gt; And where is the borderline?<o:p></o:p></p>
<p class=3D"MsoNormal">The borderline is the necessity of feedback. For exa=
mple, in the case of video conferencing, replies are needed. In the case of=
 IPTV broadcasting, user is switching between channels and doesn&#8217;t wa=
nt to wait long enough (more, than 1 sec).
 If a person selected a movie and wants to watch it, there is no reasons fo=
r any feedback.<o:p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"RU"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"RU"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"RU"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal">&gt;- Error resilience should be moved out of the us=
e cases. It can be implied by low latency, as can a lot of other things (tr=
ansport, etc)<o:p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"RU"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal">I agree that this requirement is caused by the neces=
sity of low-delay configuration. Of course, error resilience mechanisms can=
 be implemented on transport level but they can be implemented on the codec=
 level as well (e.g., redundant frames).
 For some use cases, such error resilience mechanisms can work more efficie=
ntly than error protection on the transport level.&nbsp; I propose to consi=
der it as an optional requirements that should be complementary to the mech=
anisms implemented on the transport level.<o:p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"RU"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"RU"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"RU"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal">&gt;&gt; I still argue iptv should be removed entire=
ly.<o:p></o:p></p>
<p class=3D"MsoNormal">&gt;I would be fine with this. If it stays, it needs=
 a much clearer use case definition.<o:p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"RU"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal">IPTV is a very popular use case for Internet users. =
If it will be removed, it is reasonable to discuss not an Internet video co=
dec but a codec for interactive video. I agree that use case definition sho=
uld be described more clearly but
 I disagree that this application should be removed. <o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">&gt;- The big list of resolutions is overly verbose =
and not necessary. A<o:p></o:p></p>
<p class=3D"MsoNormal">&gt;simple range of resolutions and frame rates woul=
d be better.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Agreed.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">&gt;FWIW, I argue that interlacing should not be con=
sidered in this WG (or at all for any video codec) moving forward.<o:p></o:=
p></p>
<p class=3D"MsoNormal">Agreed<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_A95DB243D3936149BBFA3B43ED71074570524AFBszxema508mbschi_--


From nobody Tue Jul 21 15:21:56 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 1998C1A0264 for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 15:21:56 -0700 (PDT)
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 ghxqNzYFHM8W for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 15:21:54 -0700 (PDT)
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (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 AAC471A020B for <video-codec@ietf.org>; Tue, 21 Jul 2015 15:21:53 -0700 (PDT)
Received: by wibud3 with SMTP id ud3so145671626wib.0 for <video-codec@ietf.org>; Tue, 21 Jul 2015 15:21:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=lK8LminOyDZzSoqC2Q1gy18Ah0jX6yq8/0Ba8a6YMCI=; b=IrHjpQmIUC0e4LLovISz0PC4JgyvkvS0lVw035+DVz7DaQNjQROvIubIn6Sflzq/Ew KSLD6Lh3BB1bggk+YZiUuQnYuSpvCZ6H4kvzBGec6G9N2D2YHjaqkAiYeMenPFNAWDN8 x++DaSNPiivhr/HPxC33FzuEq1O7KPFjFYyHweOWWMTIs4OXlyDORb4WuZSwXQnR456N TUrH85H0cWqbVqpAmHrgtNP0fCqymfJt1D0oFO2mtHr48bEo7sPMDl83iunKRULqQVZo ge5RT+b2DIj7n1/Hbrmz4LnSHIx51x6cfssaNsca7/bySprEiuZKdKT8GegB6BZF9nbW OEOg==
X-Gm-Message-State: ALoCoQkpBKz8l+RygYNuHRHMkcwEv+oVtqG9eQX3xxyP+tPNTCEc/o1Gbi3nJQzIil3NbBOB9zaC
X-Received: by 10.180.37.111 with SMTP id x15mr348519wij.33.1437517312385; Tue, 21 Jul 2015 15:21:52 -0700 (PDT)
Received: from [192.168.10.237] (static-84-42-170-138.net.upcbroadband.cz. [84.42.170.138]) by smtp.gmail.com with ESMTPSA id lz10sm39034349wjb.48.2015.07.21.15.21.51 for <video-codec@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jul 2015 15:21:51 -0700 (PDT)
To: video-codec@ietf.org
References: <A95DB243D3936149BBFA3B43ED71074570524AFB@szxema508-mbs.china.huawei.com>
From: Thomas Daede <tdaede@mozilla.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <55AEC5FE.6080107@mozilla.com>
Date: Wed, 22 Jul 2015 00:21:50 +0200
User-Agent: http://a.pomf.se/cszdno.opus
MIME-Version: 1.0
In-Reply-To: <A95DB243D3936149BBFA3B43ED71074570524AFB@szxema508-mbs.china.huawei.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/JEdSVN8kKaGx6gASV2mWMv3oF24>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Jul 2015 22:21:56 -0000

On 07/21/2015 07:19 PM, Filippov Alexey wrote:

> The borderline is the necessity of feedback. For example, in the case of
> video conferencing, replies are needed. In the case of IPTV
> broadcasting, user is switching between channels and doesnt want to
> wait long enough (more, than 1 sec). If a person selected a movie and
> wants to watch it, there is no reasons for any feedback.

The feature you are looking for is seekability, aka frequent I-frames,
*not* low latency. The "high latency" configuration I specified would be
fine for this use case.

> IPTV is a very popular use case for Internet users. If it will be
> removed, it is reasonable to discuss not an Internet video codec but a
> codec for interactive video. I agree that use case definition should be
> described more clearly but I disagree that this application should be
> removed.

You still need to specify exactly what IPTV is, and most importantly,
what sort of transport it is expected be delivered over. I assumed DASH,
but you mentioned error resilience which is not required for DASH. If
you intended some other transport, it should be made clear.

Thomas


From nobody Tue Jul 21 15:36:24 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 5BA3E1A1BF8 for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 15:36:23 -0700 (PDT)
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 m_wzAyDyW0dc for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 15:36:21 -0700 (PDT)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.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 38DBD1A036A for <video-codec@ietf.org>; Tue, 21 Jul 2015 15:36:21 -0700 (PDT)
Received: by wibxm9 with SMTP id xm9so138242278wib.0 for <video-codec@ietf.org>; Tue, 21 Jul 2015 15:36:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=7N1tghIypokbwKnxy3v26neqrqwjD+3YgpExGFUX5Ag=; b=ke9tR8xmrHn5IqTMpF+wZnMY7qANs5ny4iEkKhkBcRA8CV6H+MOMOii7+O7hzawlDu vF4sJpAbpdR++OUvyQs63NVwAIaLqokeu3eUfL/DWdOLiZy3sWx3rbkH5bInWi5WYKEz sNWfh+qm+adwCjFeTdMQgy04QzUXLBFtBmK70Ftm3l6cs15RXrbb2pJKFkvSkFMDs3he bDx5d5aYfGS7QAZRMoAUyOV7px23/sv7XvSz+5dJ8hDW81JFZDnO1TQY/2tw6FiC3bH4 FVGhgqyKjy76KARkqdt1hXhf5zR5ra+MsXeOI8hq4xJcQnPPO7waPdT/WJ2sZyoOYWQS ikCg==
X-Gm-Message-State: ALoCoQnZ52E8iSYe39+siqRgCcCvXnYOyVYbAFPDX8kXtIcyyybH1K0FETvsw6UW5/71nrqRZqSt
X-Received: by 10.180.99.71 with SMTP id eo7mr463294wib.25.1437518179899; Tue, 21 Jul 2015 15:36:19 -0700 (PDT)
Received: from [192.168.10.237] (static-84-42-170-138.net.upcbroadband.cz. [84.42.170.138]) by smtp.gmail.com with ESMTPSA id fm8sm283757wib.9.2015.07.21.15.36.19 for <video-codec@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jul 2015 15:36:19 -0700 (PDT)
To: video-codec@ietf.org
References: <32AA73C5-0D17-4ECE-A02D-041C5147D9E5@cisco.com> <55AE60D0.3040201@mozilla.com> <29BD22C6-8790-451B-B754-ED55D2F41C90@cisco.com> <55AE70D1.3020902@mozilla.com> <AA781197-CB07-4D59-BB4D-CC7BC490E819@cisco.com> <55AE746D.8070806@xiph.org> <6783B69D-9FB7-4634-9382-25857D3FD6CE@cisco.com>
From: Thomas Daede <tdaede@mozilla.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <55AEC962.3060607@mozilla.com>
Date: Wed, 22 Jul 2015 00:36:18 +0200
User-Agent: http://a.pomf.se/cszdno.opus
MIME-Version: 1.0
In-Reply-To: <6783B69D-9FB7-4634-9382-25857D3FD6CE@cisco.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/c18qcP3GXX3Y_fN8uL6kI3rpShU>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Jul 2015 22:36:23 -0000

On 07/21/2015 07:10 PM, Ali C. Begen (abegen) wrote:
> Sorry your links do not prove much. When you use a vpX or opus enabled device or browser youtube most likely sends the content with those codecs. But the world has many other devices or browsers  that are not capable of rendering them so...

And your lack of links doesn't prove much either :)

> I did not mean to create a codec discussion but looks like it is to late to revert back. Opus is a great codec and it is widely used but only under certain apps and conditions. But there are lots of other codecs that it will never replace.  I hope netvc will be equally or even more successful.  But again there will be other codecs that it will never replace nor it should. So my point is we should focus on where we have the highest chance to succeed in a reasonable time frame. 

I am honestly not sure what codecs Opus will "never replace", other than
maybe lossless codecs, codecs that run at bitrates too low to have
practical uses on the Internet, and future codecs that have not been
invented yet.

In addition, I think spending effort on the high latency case is not
nearly as high a toll as you think. Pretty much the only bitstream
feature that is needed for high latency support is bi-predicted frames.
And Thor already has these.


From nobody Tue Jul 21 18:47:03 2015
Return-Path: <Alexey.Filippov@huawei.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 2D12D1A8861 for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 18:47:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 77pF5iDjJJuq for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 18:46:59 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 323E31A8822 for <video-codec@ietf.org>; Tue, 21 Jul 2015 18:46:58 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZA17684; Wed, 22 Jul 2015 01:46:56 +0000 (GMT)
Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 22 Jul 2015 02:46:55 +0100
Received: from SZXEMA508-MBS.china.huawei.com ([169.254.8.36]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Wed, 22 Jul 2015 09:46:44 +0800
From: Filippov Alexey <Alexey.Filippov@huawei.com>
To: "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: Re: [video-codec] draft-filippov-netvc-requirements-01
Thread-Index: AdDD2VSTclZbnnUKQHiwc/xj0lwJmwANAmnA
Date: Wed, 22 Jul 2015 01:46:44 +0000
Message-ID: <A95DB243D3936149BBFA3B43ED71074570525626@szxema508-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.76.6]
Content-Type: multipart/alternative; boundary="_000_A95DB243D3936149BBFA3B43ED71074570525626szxema508mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/Ds1FUVdLTrgqQStYyCdoKX90K90>
Cc: Paul Coverdale <coverdale@sympatico.ca>, "tdaede at mozilla.com" <tdaede@mozilla.com>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Jul 2015 01:47:02 -0000

--_000_A95DB243D3936149BBFA3B43ED71074570525626szxema508mbschi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>> The borderline is the necessity of feedback. For example, in the case of
>> video conferencing, replies are needed. In the case of IPTV
>> broadcasting, user is switching between channels and doesn't want to
>> wait long enough (more, than 1 sec). If a person selected a movie and
>> wants to watch it, there is no reasons for any feedback.

>The feature you are looking for is seekability, aka frequent I-frames,
>*not* low latency. The "high latency" configuration I specified would be
>fine for this use case.

No, a better word is interaction. I guess http://www.cast-inc.com/blog/whit=
e-paper-understanding-and-reducing-latency-in-video-compression-systems pro=
vides a comprehensive explanation what we are discussing. "Low latency is a=
 design goal for any system where there is real-time interaction with the v=
ideo content, such as video conferencing... When humans interact with video=
 in a live video conference or when playing a game, latency lower than 100m=
s is considered to be low, because most humans don't perceive a delay that =
small." You are absolutely right that frequent intra-frames are needed for =
minimizing the delay while switching between channels but GOP structure, de=
-jitter buffer size, etc. significantly impact the latency as well. When I =
wrote about feedback, I meant that low latency is required in such applicat=
ions where immediate reaction of a user can be needed. So, video-on-demand =
is a high-latency application (e.g., a movie has been already selected and =
a user can wait 1,2, 5 or even 10 sec for the moment when the movie starts =
playing) but video conferencing obviously requires a low latency.



>> IPTV is a very popular use case for Internet users. If it will be
>> removed, it is reasonable to discuss not an Internet video codec but a
>> codec for interactive video. I agree that use case definition should be
>> described more clearly but I disagree that this application should be
>> removed.

>You still need to specify exactly what IPTV is, and most importantly,
>what sort of transport it is expected be delivered over. I assumed DASH,
>but you mentioned error resilience which is not required for DASH. If
>you intended some other transport, it should be made clear.

I think http://iptvpavilion.com/features/iptv-unicast-multicast-0319/ is a =
good description of 2 IPTV use cases. Thus, I propose the following definit=
ion of IPTV: "IPTV is a service for delivering television content over IP-b=
ased networks. IPTV services may be classified into two main groups based o=
n
o             unicast (e.g., for video on demand),
o             multicast/broadcast (e.g., for transmitting news or other liv=
e programs)."
Error resilience is required as "the delivery of high-quality multimedia th=
rough a reliable network is core to IPTV". But not all IP-based networks ar=
e reliable. In the case of video on demand, it is enough to increase buffer=
 size to improve the situation with network reliability. However, error res=
ilience is required to provide low latency (more details can be found in my=
 previous comment).

Alexey

--_000_A95DB243D3936149BBFA3B43ED71074570525626szxema508mbschi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@Batang";
	panose-1:2 3 6 0 0 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-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;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
p.RFCListBullet, li.RFCListBullet, div.RFCListBullet
	{mso-style-name:"RFC List Bullet";
	margin-top:0in;
	margin-right:0in;
	margin-bottom:12.0pt;
	margin-left:.6in;
	text-indent:-.3in;
	line-height:12.0pt;
	mso-line-height-rule:exactly;
	mso-list:l0 level1 lfo1;
	font-size:12.0pt;
	font-family:"Courier New";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:51933628;
	mso-list-type:hybrid;
	mso-list-template-ids:670303566 -894557882 67698691 67698693 67698689 6769=
8691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-style-link:"RFC List Bullet";
	mso-level-text:o;
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.3in;
	font-family:"Courier New";
	mso-bidi-font-family:"Times New Roman";}
@list l0:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></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]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&gt;&gt; The borderlin=
e is the necessity of feedback. For example, in the case of<o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&gt;&gt; video confere=
ncing, replies are needed. In the case of IPTV<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&gt;&gt; broadcasting,=
 user is switching between channels and doesn&#8217;t want to<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&gt;&gt; wait long eno=
ugh (more, than 1 sec). If a person selected a movie and<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&gt;&gt; wants to watc=
h it, there is no reasons for any feedback.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&gt;The feature you ar=
e looking for is seekability, aka frequent I-frames,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&gt;*not* low latency.=
 The &quot;high latency&quot; configuration I specified would be<o:p></o:p>=
</span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&gt;fine for this use =
case.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">No, a better word is i=
nteraction. I guess
<a href=3D"http://www.cast-inc.com/blog/white-paper-understanding-and-reduc=
ing-latency-in-video-compression-systems">
http://www.cast-inc.com/blog/white-paper-understanding-and-reducing-latency=
-in-video-compression-systems</a> provides a comprehensive explanation what=
 we are discussing. &#8220;Low latency is a design goal for any system wher=
e there is real-time interaction with
 the video content, such as video conferencing... When humans interact with=
 video in a live video conference or when playing a game, latency lower tha=
n 100ms is considered to be low, because most humans don&#8217;t perceive a=
 delay that small.&#8221; You are absolutely
 right that frequent intra-frames are needed for minimizing the delay while=
 switching between channels but GOP structure, de-jitter buffer size, etc. =
significantly impact the latency as well. When I wrote about feedback, I me=
ant that low latency is required
 in such applications where immediate reaction of a user can be needed. So,=
 video-on-demand is a high-latency application (e.g., a movie has been alre=
ady selected and a user can wait 1,2, 5 or even 10 sec for the moment when =
the movie starts playing) but video
 conferencing obviously requires a low latency.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&gt;&gt; IPTV is a ver=
y popular use case for Internet users. If it will be<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&gt;&gt; removed, it i=
s reasonable to discuss not an Internet video codec but a<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&gt;&gt; codec for int=
eractive video. I agree that use case definition should be<o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&gt;&gt; described mor=
e clearly but I disagree that this application should be<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&gt;&gt; removed.<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&gt;You still need to =
specify exactly what IPTV is, and most importantly,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&gt;what sort of trans=
port it is expected be delivered over. I assumed DASH,<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&gt;but you mentioned =
error resilience which is not required for DASH. If<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&gt;you intended some =
other transport, it should be made clear.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">I think <a href=3D"htt=
p://iptvpavilion.com/features/iptv-unicast-multicast-0319/">
http://iptvpavilion.com/features/iptv-unicast-multicast-0319/</a> is a good=
 description of 2 IPTV use cases. Thus, I propose the following definition =
of IPTV: &#8220;IPTV is a service for delivering television content over IP=
-based networks. IPTV services may be
 classified into two main groups based on<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">o&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; unicast (e.g., for vide=
o on demand),<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">o&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; multicast/broadcast (e.=
g., for transmitting news or other live programs).&#8221;<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Error resilience is re=
quired as &#8220;the delivery of high-quality multimedia through a reliable=
 network is core to IPTV&#8221;. But not all IP-based networks are reliable=
. In the case of video on demand, it is enough to
 increase buffer size to improve the situation with network reliability. Ho=
wever, error resilience is required to provide low latency (more details ca=
n be found in my previous comment).<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Alexey &nbsp;<o:p></o:=
p></span></p>
</div>
</body>
</html>

--_000_A95DB243D3936149BBFA3B43ED71074570525626szxema508mbschi_--


From nobody Wed Jul 22 00:00:49 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 9BF541ACDF3 for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 00:00:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.977
X-Spam-Level: 
X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, 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 6BLDkhGqup2q for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 00:00:45 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.scl3.mozilla.com [63.245.214.156]) (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 7A63F1ACDF2 for <video-codec@ietf.org>; Wed, 22 Jul 2015 00:00:45 -0700 (PDT)
Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id D17C1C05F8 for <video-codec@ietf.org>; Wed, 22 Jul 2015 07:00:44 +0000 (UTC)
X-Virus-Scanned: amavisd-new at mozilla.org
Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx2.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KPtywKM0wFJ for <video-codec@ietf.org>; Wed, 22 Jul 2015 07:00:44 +0000 (UTC)
Received: from [31.133.171.145] (dhcp-ab91.meeting.ietf.org [31.133.171.145]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 2CE16C010F for <video-codec@ietf.org>; Wed, 22 Jul 2015 07:00:43 +0000 (UTC)
Message-ID: <55AF3F9A.8080702@xiph.org>
Date: Wed, 22 Jul 2015 00:00:42 -0700
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: <32AA73C5-0D17-4ECE-A02D-041C5147D9E5@cisco.com> <55AE60D0.3040201@mozilla.com> <29BD22C6-8790-451B-B754-ED55D2F41C90@cisco.com> <55AE70D1.3020902@mozilla.com> <AA781197-CB07-4D59-BB4D-CC7BC490E819@cisco.com> <55AE746D.8070806@xiph.org> <6783B69D-9FB7-4634-9382-25857D3FD6CE@cisco.com> <55AEC962.3060607@mozilla.com>
In-Reply-To: <55AEC962.3060607@mozilla.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/0eXGZsjtB7oK2EyOoIvBFppzxTs>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Jul 2015 07:00:47 -0000

Thomas Daede wrote:
> In addition, I think spending effort on the high latency case is not
> nearly as high a toll as you think. Pretty much the only bitstream
> feature that is needed for high latency support is bi-predicted frames.
> And Thor already has these.

Also, as I have said before, network effects dominate. Having tried this 
royalty-free codec thing several times now, I believe that to the extent 
Opus has been more successful than our prior efforts it is precisely 
because it is better on all fronts across a very wide range of 
applications. You don't build network effects by being a niche codec, 
especially when your competition (as here) is not a niche codec.

I do think focusing on interactive first has some benefits. If you focus 
on streaming/random access first, you wind up with a laundry list of 
features that are not, e.g., robust to packet loss, and thus have to be 
shut off for interactive applications with some large penalty (> 5% 
rate), while alternative features could have been designed that would 
have been nearly as good (within 1-2% rate) and also been robust to 
packet loss. This has already come up several times in Daala and we have 
opted for the latter approach. You can't do that for all features (frame 
re-ordering being one big exception, as you mention), but you can do it 
for a lot of them.


From nobody Wed Jul 22 00:48:14 2015
Return-Path: <abegen@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 4DFCD1ACE32 for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 00:48:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.111
X-Spam-Level: 
X-Spam-Status: No, score=-13.111 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 oiySCO-8B5YP for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 00:48:10 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 746C41ACE24 for <video-codec@ietf.org>; Wed, 22 Jul 2015 00:48:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4608; q=dns/txt; s=iport; t=1437551290; x=1438760890; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=mqCXBRSVkuHV07XNhEJdG/skdowXX56lhz9nxzBDrYY=; b=C5tCR78yF7MnS0P0rHUgZI1S5Bwpn5NQKz4ZhZU+alK0SdbOLJJfr0o6 GDYfyB5XBbNJmX2ap7OULAO3Jq5thUbRZg2OfTlzWetxno/b7AuCWmlSm n9uyy4alurQ6DePv9BsXN5abogEzRj+sCnkA5O7bLHJlAiQM0C/+ctJbA A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BnBQBTSa9V/5NdJa1cgxVUaQaDHbpFCoYBAhyBKDwQAQEBAQEBAYEKhCMBAQEDAQEBASAROhcEAgEIDgMDAQIBAgIQFgICAiULFQgHAQIEARKIJggNtWWWMQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSKJKIEChEIpIgaCYoFDBZRXAYwxgUOTbYNhJoINHIEET2+BR4EEAQEB
X-IronPort-AV: E=Sophos;i="5.15,521,1432598400"; d="scan'208";a="170964762"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP; 22 Jul 2015 07:48:09 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t6M7m92q029107 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 07:48:09 GMT
Received: from xmb-aln-x01.cisco.com ([169.254.2.64]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 02:48:09 -0500
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: Thomas Daede <tdaede@mozilla.com>, "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: [video-codec] draft-filippov-netvc-requirements-01
Thread-Index: AQHQw8CyW0GCvpXJZECxIZTezzBngJ3mWvkAgAApqwD//+lpgIAAI3YA///g2ID//7ZZDwAV3b0AABd2z4A=
Date: Wed, 22 Jul 2015 07:48:08 +0000
Message-ID: <6C43041C-9C21-4E30-96CA-822458111700@cisco.com>
References: <32AA73C5-0D17-4ECE-A02D-041C5147D9E5@cisco.com> <55AE60D0.3040201@mozilla.com> <29BD22C6-8790-451B-B754-ED55D2F41C90@cisco.com> <55AE70D1.3020902@mozilla.com> <AA781197-CB07-4D59-BB4D-CC7BC490E819@cisco.com> <55AE746D.8070806@xiph.org> <6783B69D-9FB7-4634-9382-25857D3FD6CE@cisco.com> <55AEC962.3060607@mozilla.com>
In-Reply-To: <55AEC962.3060607@mozilla.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.150701
x-originating-ip: [10.61.214.86]
Content-Type: text/plain; charset="utf-8"
Content-ID: <17883BBDC9FDBC4580E6E281C87D396C@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/FRnDRhmHz2MTAzOvi9XPqfVkFPQ>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Jul 2015 07:48:12 -0000

DQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB2aWRlby1jb2RlYyBv
biBiZWhhbGYgb2YgVGhvbWFzIERhZWRlDQpEYXRlOiBXZWRuZXNkYXksIEp1bHkgMjIsIDIwMTUg
YXQgMTI6MzYgQU0NClRvOiAidmlkZW8tY29kZWNAaWV0Zi5vcmciDQpTdWJqZWN0OiBSZTogW3Zp
ZGVvLWNvZGVjXSBkcmFmdC1maWxpcHBvdi1uZXR2Yy1yZXF1aXJlbWVudHMtMDENCg0KPk9uIDA3
LzIxLzIwMTUgMDc6MTAgUE0sIEFsaSBDLiBCZWdlbiAoYWJlZ2VuKSB3cm90ZToNCj4+IFNvcnJ5
IHlvdXIgbGlua3MgZG8gbm90IHByb3ZlIG11Y2guIFdoZW4geW91IHVzZSBhIHZwWCBvciBvcHVz
IGVuYWJsZWQgZGV2aWNlIG9yIGJyb3dzZXIgeW91dHViZSBtb3N0IGxpa2VseSBzZW5kcyB0aGUg
Y29udGVudCB3aXRoIHRob3NlIGNvZGVjcy4gQnV0IHRoZSB3b3JsZCBoYXMgbWFueSBvdGhlciBk
ZXZpY2VzIG9yIGJyb3dzZXJzICB0aGF0IGFyZSBub3QgY2FwYWJsZSBvZiByZW5kZXJpbmcgdGhl
bSBzby4uLg0KPg0KPkFuZCB5b3VyIGxhY2sgb2YgbGlua3MgZG9lc24ndCBwcm92ZSBtdWNoIGVp
dGhlciA6KQ0KDQpJZiB5b3UgZ29vZ2xlIGZvciBlbmNvZGluZy5jb23igJlzIGdsb2JhbCBtZWRp
YSByZXBvcnQgMjAxNSB5b3Ugd2lsbCBzZWUgdGhhdCB0aGV5IHJlcG9ydCBITFMgYmVpbmcgdGhl
IG1hcmtldCBsZWFkZXIgd2l0aCA3NSUsIHRoZW4gc21vb3RoIHN0cmVhbWluZyBjb21lcyBhbG9u
ZyAoaW4gdGhlIHN0cmVhbWluZyBkb21haW4pLiBOZWl0aGVyIG9mIHRoZXNlIHVzZSB2cFgvb3B1
cyB0byBteSBrbm93bGVkZ2UuIA0KDQpZb3UgY2FuIGFsc28gZ29vZ2xlIEpXIHBsYXllcuKAmXMg
dHJlbmRzIGluIG9ubGluZSB2aWRlbyByZXBvcnQsIGFuZCB5b3Ugd2lsbCBzZWUgdGhhdCB3ZWJt
IG9ubHkgaGFzIDklIHNoYXJlLg0KDQpJZiB5b3Ugc3RyZWFtIHlvdXR1YmUgdG8geW91ciBpT1Mg
ZGV2aWNlcyB0b2RheSwgaXQgaXMgaDI2NCBhbmQgYWFjLiBUaGlzIGFsc28gaGFwcGVucyB3aXRo
IG1vc3QgYnJvd3NlcnMgb3RoZXIgdGhhbiBjaHJvbWUgYW5kIGZpcmVmb3guIE5lZWRsZXNzIHRv
IG1lbnRpb24sIGFwcGxlIHR2LCBSb2t1LCBhbGwgdGhvc2Ugc3RyZWFtaW5nIHBsYXllcnMgKHBy
b2JhYmx5IGV4Y2VwdCBjaHJvbWVjYXN0KSBkbyBub3QgdXNlIHZwWC9vcHVzIHRvIG15IGtub3ds
ZWRnZS4gDQoNCkFsc28gZG8gbm90IGZvcmdldCBhYm91dCB0aGUgY29ubmVjdGVkIFRWcywgYWxs
IHRob3NlIGRldmljZXMgYWxyZWFkeSBoYXZlIHRvIHN1cHBvcnQgaDI2NCBhbmQgbW9zdCBuZXcg
b25lcyBzdXBwb3J0IGgyNjUsIHRvbywgYW5kIHRoYXQgaXMgd2hhdCB0aGV5IHVzZSB0byBzdHJl
YW0gb25saW5lIGNvbnRlbnQuIEh5YnJpZCBzZXR0b3BzIHRoYXQgYXJlIGluIG91ciBob3VzZXMg
KGZyb20gYW55IGNhYmxlL2lwdHYvc2F0IHByb3ZpZGVyKSwgdGhleSBzdXBwb3J0IHRoZSBleGlz
dGluZyB3ZWxsIGtub3duIGNvZGVjcy4gSG9uZXN0bHkgc3BlYWtpbmcsIHRoZXJlIGFyZSBzdGls
bCBib3hlcyBvdXQgdGhlcmUgdGhhdCBvbmx5IHN1cHBvcnQgbXBlZzIgbm90IGV2ZW4gaDI2NCBi
ZWNhdXNlIGl0IHByb2JhYmx5IGNvc3RzIG1vcmUgdG8gdGhlIHNlcnZpY2UgcHJvdmlkZXIgdG8g
cmVwbGFjZSB0aGVtLg0KDQpOZXRmbGl4LCB0aGUgbGFyZ2VzdCBzdHJlYW1pbmcgY29tcGFueSBm
b3IgdHYgc2hvd3MsIG1vdmllcywgKGFuZCBoYXMgdGhlIGxhcmdlc3Qgd29ybGR3aWRlIHN1YnNj
cmliZXIgbnVtYmVyKSBkb2VzIG5vdCB1c2UgdnBYL29wdXMuIEFtYXpvbiBwcmltZSB1c2VzIGF2
YyBhbmQgYWFjLg0KDQo+DQo+PiBJIGRpZCBub3QgbWVhbiB0byBjcmVhdGUgYSBjb2RlYyBkaXNj
dXNzaW9uIGJ1dCBsb29rcyBsaWtlIGl0IGlzIHRvIGxhdGUgdG8gcmV2ZXJ0IGJhY2suIE9wdXMg
aXMgYSBncmVhdCBjb2RlYyBhbmQgaXQgaXMgd2lkZWx5IHVzZWQgYnV0IG9ubHkgdW5kZXIgY2Vy
dGFpbiBhcHBzIGFuZCBjb25kaXRpb25zLiBCdXQgdGhlcmUgYXJlIGxvdHMgb2Ygb3RoZXIgY29k
ZWNzIHRoYXQgaXQgd2lsbCBuZXZlciByZXBsYWNlLiAgSSBob3BlIG5ldHZjIHdpbGwgYmUgZXF1
YWxseSBvciBldmVuIG1vcmUgc3VjY2Vzc2Z1bC4gIEJ1dCBhZ2FpbiB0aGVyZSB3aWxsIGJlIG90
aGVyIGNvZGVjcyB0aGF0IGl0IHdpbGwgbmV2ZXIgcmVwbGFjZSBub3IgaXQgc2hvdWxkLiBTbyBt
eSBwb2ludCBpcyB3ZSBzaG91bGQgZm9jdXMgb24gd2hlcmUgd2UgaGF2ZSB0aGUgaGlnaGVzdCBj
aGFuY2UgdG8gc3VjY2VlZCBpbiBhIHJlYXNvbmFibGUgdGltZSBmcmFtZS4gDQo+DQo+SSBhbSBo
b25lc3RseSBub3Qgc3VyZSB3aGF0IGNvZGVjcyBPcHVzIHdpbGwgIm5ldmVyIHJlcGxhY2UiLCBv
dGhlciB0aGFuDQo+bWF5YmUgbG9zc2xlc3MgY29kZWNzLCBjb2RlY3MgdGhhdCBydW4gYXQgYml0
cmF0ZXMgdG9vIGxvdyB0byBoYXZlDQo+cHJhY3RpY2FsIHVzZXMgb24gdGhlIEludGVybmV0LCBh
bmQgZnV0dXJlIGNvZGVjcyB0aGF0IGhhdmUgbm90IGJlZW4NCj5pbnZlbnRlZCB5ZXQuDQoNCkFz
IEkgbWVudGlvbmVkIHNpdHVhdGlvbiBpcyBkaWZmZXJlbnQgKGJldHRlcikgZm9yIG9wdXMgdGhh
biBuZXR2YywgYnV0IGlmIHlvdSBhcmUgdGVsbGluZyBtZSB0aGF0IG9wdXMgd2lsbCByZXBsYWNl
IEFBQywgb3Igb3RoZXIgbXVsdGktY2hhbm5lbCB0ZWNobm9sb2dpZXMgKGxpa2UgZG9sYnkgc3R1
ZmYpLCBJIGRpc2FncmVlLg0KDQo+DQo+SW4gYWRkaXRpb24sIEkgdGhpbmsgc3BlbmRpbmcgZWZm
b3J0IG9uIHRoZSBoaWdoIGxhdGVuY3kgY2FzZSBpcyBub3QNCj5uZWFybHkgYXMgaGlnaCBhIHRv
bGwgYXMgeW91IHRoaW5rLiBQcmV0dHkgbXVjaCB0aGUgb25seSBiaXRzdHJlYW0NCj5mZWF0dXJl
IHRoYXQgaXMgbmVlZGVkIGZvciBoaWdoIGxhdGVuY3kgc3VwcG9ydCBpcyBiaS1wcmVkaWN0ZWQg
ZnJhbWVzLg0KDQpJdCBpcyBtb3JlIHRoYW4gdGhhdC4gRXZlbiBpZiB3ZSBoYXZlIGFuIG9uIHBh
ciBvciBiZXR0ZXIgY29kZWMsIGl0IG1heSBub3QgZ2V0IGFkb3B0ZWQgZHVlIHRvIHRoZSByZWFz
b25zIHdlIGRvIG5vdCBjb250cm9sLiBIZW5jZSwgSSBzYWlkLCB3ZSBzaG91bGQgZm9jdXMgb3Vy
IGVuZXJneSB3aGVyZSBpdCBjYW4gbWFrZSB0aGUgbW9zdCBpbXBhY3QuDQoNCj5BbmQgVGhvciBh
bHJlYWR5IGhhcyB0aGVzZS4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KPnZpZGVvLWNvZGVjIG1haWxpbmcgbGlzdA0KPnZpZGVvLWNvZGVjQGll
dGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92aWRlby1jb2Rl
Yw0K


From nobody Wed Jul 22 00:48:25 2015
Return-Path: <abegen@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 A46BF1ACE24 for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 00:48:20 -0700 (PDT)
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 RR0HcLan9fTb for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 00:48:15 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF4141B2D56 for <video-codec@ietf.org>; Wed, 22 Jul 2015 00:48:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2772; q=dns/txt; s=iport; t=1437551294; x=1438760894; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+0ubp1ibhzi/204AardHd8FH6RUHAx4jOmD3OX/4AbU=; b=m4NlSO9rx6hIY6T49tZgsH1I+gcyTOAhxGfR5eDdQw7ybBeYqigAyjSd 62/Nt1rT4nYqmUWqul3hFIcImi7Ok5Qla+ANTRulthT52luVJRvcVqVm1 JAyvBH6laKG0xubkRHmAZA7YRrEpdAXn4UcyPYsfVIKCZy/l07rnsf5f6 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BdAwCCSq9V/4QNJK1cgxVUaQaDHbhRCYFrCoYBAhyBKDgUAQEBAQEBAYEKhCMBAQEDAQEBASAROhcEAgEIDgMDAQIBAgImAgICJQsVCAgBAQQBEogmCA21ZZYwAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIooqhFMYIgaCYi+BFAWUVwGMMZkRJoN8b4FHgQQBAQE
X-IronPort-AV: E=Sophos;i="5.15,522,1432598400"; d="scan'208";a="171139046"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP; 22 Jul 2015 07:48:10 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t6M7mA8o025579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 07:48:10 GMT
Received: from xmb-aln-x01.cisco.com ([169.254.2.64]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 02:48:10 -0500
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: Thomas Daede <tdaede@mozilla.com>, "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: [video-codec] draft-filippov-netvc-requirements-01
Thread-Index: AdDD2VSTW0GCvpXJZECxIZTezzBngAAVDe0AABf4mQA=
Date: Wed, 22 Jul 2015 07:48:09 +0000
Message-ID: <FC80295B-A4F8-4A51-A99C-710CE3F67651@cisco.com>
References: <A95DB243D3936149BBFA3B43ED71074570524AFB@szxema508-mbs.china.huawei.com> <55AEC5FE.6080107@mozilla.com>
In-Reply-To: <55AEC5FE.6080107@mozilla.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.150701
x-originating-ip: [10.61.214.86]
Content-Type: text/plain; charset="utf-8"
Content-ID: <FAD1124986AC964092E9096F3B73A034@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/ua3Yp60ZT07jIaiJPrIKJmQguUo>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Jul 2015 07:48:20 -0000

DQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB2aWRlby1jb2RlYyBv
biBiZWhhbGYgb2YgVGhvbWFzIERhZWRlDQpEYXRlOiBXZWRuZXNkYXksIEp1bHkgMjIsIDIwMTUg
YXQgMTI6MjEgQU0NClRvOiAidmlkZW8tY29kZWNAaWV0Zi5vcmciDQpTdWJqZWN0OiBSZTogW3Zp
ZGVvLWNvZGVjXSBkcmFmdC1maWxpcHBvdi1uZXR2Yy1yZXF1aXJlbWVudHMtMDENCg0KPk9uIDA3
LzIxLzIwMTUgMDc6MTkgUE0sIEZpbGlwcG92IEFsZXhleSB3cm90ZToNCj4NCj4+IFRoZSBib3Jk
ZXJsaW5lIGlzIHRoZSBuZWNlc3NpdHkgb2YgZmVlZGJhY2suIEZvciBleGFtcGxlLCBpbiB0aGUg
Y2FzZSBvZg0KPj4gdmlkZW8gY29uZmVyZW5jaW5nLCByZXBsaWVzIGFyZSBuZWVkZWQuIEluIHRo
ZSBjYXNlIG9mIElQVFYNCj4+IGJyb2FkY2FzdGluZywgdXNlciBpcyBzd2l0Y2hpbmcgYmV0d2Vl
biBjaGFubmVscyBhbmQgZG9lc27igJl0IHdhbnQgdG8NCj4+IHdhaXQgbG9uZyBlbm91Z2ggKG1v
cmUsIHRoYW4gMSBzZWMpLiBJZiBhIHBlcnNvbiBzZWxlY3RlZCBhIG1vdmllIGFuZA0KPj4gd2Fu
dHMgdG8gd2F0Y2ggaXQsIHRoZXJlIGlzIG5vIHJlYXNvbnMgZm9yIGFueSBmZWVkYmFjay4NCj4N
Cj5UaGUgZmVhdHVyZSB5b3UgYXJlIGxvb2tpbmcgZm9yIGlzIHNlZWthYmlsaXR5LCBha2EgZnJl
cXVlbnQgSS1mcmFtZXMsDQo+Km5vdCogbG93IGxhdGVuY3kuIFRoZSAiaGlnaCBsYXRlbmN5IiBj
b25maWd1cmF0aW9uIEkgc3BlY2lmaWVkIHdvdWxkIGJlDQo+ZmluZSBmb3IgdGhpcyB1c2UgY2Fz
ZS4NCg0KSWYgeW91IGltcGxlbWVudCBSRkMgNjI4NSwgeW91IGRvbnQgbmVlZCBmcmVxdWVudCBJ
LWZyYW1lcywgZWl0aGVyLiBUaGlzIGlzIHNvbWV0aGluZyBpbXBsZW1lbnRlZCBpbiBtb3N0IElQ
VFYgZGVwbG95bWVudHMuDQoNCj4NCj4+IElQVFYgaXMgYSB2ZXJ5IHBvcHVsYXIgdXNlIGNhc2Ug
Zm9yIEludGVybmV0IHVzZXJzLiBJZiBpdCB3aWxsIGJlDQo+PiByZW1vdmVkLCBpdCBpcyByZWFz
b25hYmxlIHRvIGRpc2N1c3Mgbm90IGFuIEludGVybmV0IHZpZGVvIGNvZGVjIGJ1dCBhDQo+PiBj
b2RlYyBmb3IgaW50ZXJhY3RpdmUgdmlkZW8uIEkgYWdyZWUgdGhhdCB1c2UgY2FzZSBkZWZpbml0
aW9uIHNob3VsZCBiZQ0KPj4gZGVzY3JpYmVkIG1vcmUgY2xlYXJseSBidXQgSSBkaXNhZ3JlZSB0
aGF0IHRoaXMgYXBwbGljYXRpb24gc2hvdWxkIGJlDQo+PiByZW1vdmVkLg0KPg0KPllvdSBzdGls
bCBuZWVkIHRvIHNwZWNpZnkgZXhhY3RseSB3aGF0IElQVFYgaXMsIGFuZCBtb3N0IGltcG9ydGFu
dGx5LA0KPndoYXQgc29ydCBvZiB0cmFuc3BvcnQgaXQgaXMgZXhwZWN0ZWQgYmUgZGVsaXZlcmVk
IG92ZXIuIEkgYXNzdW1lZCBEQVNILA0KPmJ1dCB5b3UgbWVudGlvbmVkIGVycm9yIHJlc2lsaWVu
Y2Ugd2hpY2ggaXMgbm90IHJlcXVpcmVkIGZvciBEQVNILiBJZg0KPnlvdSBpbnRlbmRlZCBzb21l
IG90aGVyIHRyYW5zcG9ydCwgaXQgc2hvdWxkIGJlIG1hZGUgY2xlYXIuDQoNCklQVFYgZG9lcyBu
b3QgKGFuZCBzaG91bGQgbm90KSBtZWFuIERBU0ggbGlrZSBzdHJlYW1pbmcgc2VydmljZXMgb3Ig
cHJvZ3Jlc3NpdmUgZG93bmxvYWQuIElQVFYgbWVhbnMgbXVsdGljYXN0IGZvciBsaW5lYXIgZGVs
aXZlcnkgYW5kIHVuaWNhc3QgZm9yIFZvRCBkZWxpdmVyeSBvdmVyIGEgUW9TIGVuYWJsZWQgU1Ag
bmV0d29yayAobm90IGV2ZW4gdGhlIG9wZW4gSW50ZXJuZXQpLg0KDQpJZiB5b3Ugd2FubmEgbWVh
biBzdHJlYW1pbmcgc2VydmljZXMsIGp1c3Qgc2F5IHN0cmVhbWluZy4gTm8gbmVlZCB0byBjb25m
dXNlIHBlb3BsZSB3aXRoIG90aGVyIHRlcm1zLiANCg0KPg0KPlRob21hcw0KPg0KPl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+dmlkZW8tY29kZWMgbWFp
bGluZyBsaXN0DQo+dmlkZW8tY29kZWNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL3ZpZGVvLWNvZGVjDQo=


From nobody Wed Jul 22 01:00:48 2015
Return-Path: <mohammedsraad@raadtech.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 0A1321B2D44 for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 01:00:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.577
X-Spam-Level: 
X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 HHCs-ysF6bvL for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 01:00:44 -0700 (PDT)
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (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 15AB21A8A1A for <video-codec@ietf.org>; Wed, 22 Jul 2015 01:00:44 -0700 (PDT)
Received: by wicgb10 with SMTP id gb10so86046632wic.1 for <video-codec@ietf.org>; Wed, 22 Jul 2015 01:00:42 -0700 (PDT)
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=esoqEMa1JYBCffA6SR/O1hMgzrnXublhEWrla4Gc/V4=; b=gLRlqAtflnWi8oJHkYVhUrp0IrlhscXIliJkbfyMS76c2z/npJn+BF3OJpQHjLzs+N +GRtSlVXbxfUxylRxICMKeP0wzeT6BzQFbtOaRjQPgK9nG9ZXFpJGFHvTzxNe48F20wt DSDS+e9s/zdtUjhR+VY4bO6Knw/410Y47P5tbt6SoVkWx/OTF+Vuk4oAt9KRN2+rbkbR jETJyThz0to6jYViz9L4hXK3HDf45UG4r8XxbPWdjVy0OSjHpuFZVcq6WHAtjHXN6464 TRMtez9eWM6T/IdkYG5SJLO3CdprcRlC7n64W+N9/GYNRGMC1H6vX6xRzusGEjQV3BZv UHAQ==
X-Gm-Message-State: ALoCoQk4C+Oe/5k/YK4JXRljgJlLsPWLOw3Fdm1mk33rYj8AnJgEpq9XW6TlMtOoA1d40pQ27g8N
MIME-Version: 1.0
X-Received: by 10.180.103.42 with SMTP id ft10mr3964464wib.43.1437552042728; Wed, 22 Jul 2015 01:00:42 -0700 (PDT)
Received: by 10.194.243.106 with HTTP; Wed, 22 Jul 2015 01:00:42 -0700 (PDT)
In-Reply-To: <6C43041C-9C21-4E30-96CA-822458111700@cisco.com>
References: <32AA73C5-0D17-4ECE-A02D-041C5147D9E5@cisco.com> <55AE60D0.3040201@mozilla.com> <29BD22C6-8790-451B-B754-ED55D2F41C90@cisco.com> <55AE70D1.3020902@mozilla.com> <AA781197-CB07-4D59-BB4D-CC7BC490E819@cisco.com> <55AE746D.8070806@xiph.org> <6783B69D-9FB7-4634-9382-25857D3FD6CE@cisco.com> <55AEC962.3060607@mozilla.com> <6C43041C-9C21-4E30-96CA-822458111700@cisco.com>
Date: Wed, 22 Jul 2015 11:00:42 +0300
Message-ID: <CA+E6M0m4adjQZ908X2DzNAKPRtBTXQVAjc0vR24Pb1GY1gOSgA@mail.gmail.com>
From: Mohammed Raad <mohammedsraad@raadtech.com>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>
Content-Type: multipart/alternative; boundary=f46d044401c6da7e03051b722aee
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/I2rypa1XfyqhfyHxMIOSS5N3-RQ>
Cc: "video-codec@ietf.org" <video-codec@ietf.org>, Thomas Daede <tdaede@mozilla.com>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Jul 2015 08:00:47 -0000

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

But what's the argument here, that if vpx/opus has not dominated yet then
the netvc effort will not produce something that will dominate on the web?

I gather that what is meant by "interactive" is real time communications.
If you limit the netvc effort to only real time communications then you are
ensuring that it will not have a chance to be dominant once it is complete
because the argument for adoption will be weakened by the fact that another
codec will be needed for the high quality material.


Mohammed

On Wed, Jul 22, 2015 at 10:48 AM, Ali C. Begen (abegen) <abegen@cisco.com>
wrote:

>
>
>
>
>
> -----Original Message-----
> From: video-codec on behalf of Thomas Daede
> Date: Wednesday, July 22, 2015 at 12:36 AM
> To: "video-codec@ietf.org"
> Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
>
> >On 07/21/2015 07:10 PM, Ali C. Begen (abegen) wrote:
> >> Sorry your links do not prove much. When you use a vpX or opus enabled
> device or browser youtube most likely sends the content with those codecs=
.
> But the world has many other devices or browsers  that are not capable of
> rendering them so...
> >
> >And your lack of links doesn't prove much either :)
>
> If you google for encoding.com=E2=80=99s global media report 2015 you wil=
l see
> that they report HLS being the market leader with 75%, then smooth
> streaming comes along (in the streaming domain). Neither of these use
> vpX/opus to my knowledge.
>
> You can also google JW player=E2=80=99s trends in online video report, an=
d you
> will see that webm only has 9% share.
>
> If you stream youtube to your iOS devices today, it is h264 and aac. This
> also happens with most browsers other than chrome and firefox. Needless t=
o
> mention, apple tv, Roku, all those streaming players (probably except
> chromecast) do not use vpX/opus to my knowledge.
>
> Also do not forget about the connected TVs, all those devices already hav=
e
> to support h264 and most new ones support h265, too, and that is what the=
y
> use to stream online content. Hybrid settops that are in our houses (from
> any cable/iptv/sat provider), they support the existing well known codecs=
.
> Honestly speaking, there are still boxes out there that only support mpeg=
2
> not even h264 because it probably costs more to the service provider to
> replace them.
>
> Netflix, the largest streaming company for tv shows, movies, (and has the
> largest worldwide subscriber number) does not use vpX/opus. Amazon prime
> uses avc and aac.
>
> >
> >> I did not mean to create a codec discussion but looks like it is to
> late to revert back. Opus is a great codec and it is widely used but only
> under certain apps and conditions. But there are lots of other codecs tha=
t
> it will never replace.  I hope netvc will be equally or even more
> successful.  But again there will be other codecs that it will never
> replace nor it should. So my point is we should focus on where we have th=
e
> highest chance to succeed in a reasonable time frame.
> >
> >I am honestly not sure what codecs Opus will "never replace", other than
> >maybe lossless codecs, codecs that run at bitrates too low to have
> >practical uses on the Internet, and future codecs that have not been
> >invented yet.
>
> As I mentioned situation is different (better) for opus than netvc, but i=
f
> you are telling me that opus will replace AAC, or other multi-channel
> technologies (like dolby stuff), I disagree.
>
> >
> >In addition, I think spending effort on the high latency case is not
> >nearly as high a toll as you think. Pretty much the only bitstream
> >feature that is needed for high latency support is bi-predicted frames.
>
> It is more than that. Even if we have an on par or better codec, it may
> not get adopted due to the reasons we do not control. Hence, I said, we
> should focus our energy where it can make the most impact.
>
> >And Thor already has these.
> >
> >_______________________________________________
> >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
>



--=20
Mohammed Raad, PhD.
Partner
RAADTECH CONSULTING
P.O. Box 113
Warrawong
NSW 2502 Australia
Phone: +61 414451478
Email: mohammedsraad@raadtech.com

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

<div dir=3D"ltr">But what&#39;s the argument here, that if vpx/opus has not=
 dominated yet then the netvc effort will not produce something that will d=
ominate on the web?<div><br></div><div>I gather that what is meant by &quot=
;interactive&quot; is real time communications. If you limit the netvc effo=
rt to only real time communications then you are ensuring that it will not =
have a chance to be dominant once it is complete because the argument for a=
doption will be weakened by the fact that another codec will be needed for =
the high quality material.</div><div><br></div><div><br></div><div>Mohammed=
</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On We=
d, Jul 22, 2015 at 10:48 AM, Ali C. Begen (abegen) <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:abegen@cisco.com" target=3D"_blank">abegen@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"><span class=3D""><br>
<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: video-codec on behalf of Thomas Daede<br>
</span><span class=3D"">Date: Wednesday, July 22, 2015 at 12:36 AM<br>
To: &quot;<a href=3D"mailto:video-codec@ietf.org">video-codec@ietf.org</a>&=
quot;<br>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01<br>
<br>
</span><span class=3D"">&gt;On 07/21/2015 07:10 PM, Ali C. Begen (abegen) w=
rote:<br>
&gt;&gt; Sorry your links do not prove much. When you use a vpX or opus ena=
bled device or browser youtube most likely sends the content with those cod=
ecs. But the world has many other devices or browsers=C2=A0 that are not ca=
pable of rendering them so...<br>
&gt;<br>
&gt;And your lack of links doesn&#39;t prove much either :)<br>
<br>
</span>If you google for <a href=3D"http://encoding.com" rel=3D"noreferrer"=
 target=3D"_blank">encoding.com</a>=E2=80=99s global media report 2015 you =
will see that they report HLS being the market leader with 75%, then smooth=
 streaming comes along (in the streaming domain). Neither of these use vpX/=
opus to my knowledge.<br>
<br>
You can also google JW player=E2=80=99s trends in online video report, and =
you will see that webm only has 9% share.<br>
<br>
If you stream youtube to your iOS devices today, it is h264 and aac. This a=
lso happens with most browsers other than chrome and firefox. Needless to m=
ention, apple tv, Roku, all those streaming players (probably except chrome=
cast) do not use vpX/opus to my knowledge.<br>
<br>
Also do not forget about the connected TVs, all those devices already have =
to support h264 and most new ones support h265, too, and that is what they =
use to stream online content. Hybrid settops that are in our houses (from a=
ny cable/iptv/sat provider), they support the existing well known codecs. H=
onestly speaking, there are still boxes out there that only support mpeg2 n=
ot even h264 because it probably costs more to the service provider to repl=
ace them.<br>
<br>
Netflix, the largest streaming company for tv shows, movies, (and has the l=
argest worldwide subscriber number) does not use vpX/opus. Amazon prime use=
s avc and aac.<br>
<span class=3D""><br>
&gt;<br>
&gt;&gt; I did not mean to create a codec discussion but looks like it is t=
o late to revert back. Opus is a great codec and it is widely used but only=
 under certain apps and conditions. But there are lots of other codecs that=
 it will never replace.=C2=A0 I hope netvc will be equally or even more suc=
cessful.=C2=A0 But again there will be other codecs that it will never repl=
ace nor it should. So my point is we should focus on where we have the high=
est chance to succeed in a reasonable time frame.<br>
&gt;<br>
&gt;I am honestly not sure what codecs Opus will &quot;never replace&quot;,=
 other than<br>
&gt;maybe lossless codecs, codecs that run at bitrates too low to have<br>
&gt;practical uses on the Internet, and future codecs that have not been<br=
>
&gt;invented yet.<br>
<br>
</span>As I mentioned situation is different (better) for opus than netvc, =
but if you are telling me that opus will replace AAC, or other multi-channe=
l technologies (like dolby stuff), I disagree.<br>
<span class=3D""><br>
&gt;<br>
&gt;In addition, I think spending effort on the high latency case is not<br=
>
&gt;nearly as high a toll as you think. Pretty much the only bitstream<br>
&gt;feature that is needed for high latency support is bi-predicted frames.=
<br>
<br>
</span>It is more than that. Even if we have an on par or better codec, it =
may not get adopted due to the reasons we do not control. Hence, I said, we=
 should focus our energy where it can make the most impact.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt;And Thor already has these.<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" rel=3D"no=
referrer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/video-cod=
ec</a><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" rel=3D"norefe=
rrer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/video-codec</=
a><br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature">Mohammed Raad, PhD.<br>Partner<br>RAADTECH C=
ONSULTING<br>P.O. Box 113<br>Warrawong<br>NSW 2502 Australia<br>Phone: +61 =
414451478<br>Email: <a href=3D"mailto:mohammedsraad@raadtech.com" target=3D=
"_blank">mohammedsraad@raadtech.com</a></div>
</div>

--f46d044401c6da7e03051b722aee--


From nobody Wed Jul 22 01:03:54 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 661611B3023 for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 01:03:52 -0700 (PDT)
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 ZIRb9UFiWbH1 for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 01:03:50 -0700 (PDT)
Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (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 ECA8E1B2F7B for <video-codec@ietf.org>; Wed, 22 Jul 2015 01:03:49 -0700 (PDT)
Received: by wicgb10 with SMTP id gb10so86165410wic.1 for <video-codec@ietf.org>; Wed, 22 Jul 2015 01:03:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=b78hlvV1DeSF65ATzrHXPzwKelbL7e6f/VHWOgCYEPM=; b=bCttam83mSl+GLlQca6mflERysq7xPSUShdQ1I2GUVUTW4BNng3alBNKyP1b+lmYLz 8/gAhy0tNvToHkRbBwMEH4UR6gZBKDv0QMX4/mOOj01nMsGeZwGnCxjeLzYtw9l1lfCl QQNU5THSZ2FdLmUCYNaCQ4c0cylbpfH/PVUHssqCCVc91nWzfKoyH8HwJwEQVDye2QIJ f8M3/apVhCOXb1aN5G4f03hbAcakRHQBxlhQnsV8u/mxVIjK6e+z5/kpA/D5fv9JwHPQ gR7w3wddfNVUyQ1qbJ293dhcU055MX/JTMP7vD4O3gQ4R1G5ytowSa+qR+hhHN6R2QhC nBeQ==
X-Gm-Message-State: ALoCoQkAJaBeJnlhmpBHFv6UiXvUQcruGQCnQIROlnFgzBpCLv9ouG6O0NjUrwwxA7lUAQbH3K5Z
X-Received: by 10.180.216.42 with SMTP id on10mr19461331wic.3.1437552228439; Wed, 22 Jul 2015 01:03:48 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:168:7e7a:91ff:fe9e:8126? ([2001:67c:370:168:7e7a:91ff:fe9e:8126]) by smtp.gmail.com with ESMTPSA id r19sm2057075wib.7.2015.07.22.01.03.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jul 2015 01:03:47 -0700 (PDT)
To: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>, "Ali C. Begen (abegen)" <abegen@cisco.com>
References: <32AA73C5-0D17-4ECE-A02D-041C5147D9E5@cisco.com> <55AE60D0.3040201@mozilla.com> <29BD22C6-8790-451B-B754-ED55D2F41C90@cisco.com> <55AE6F5C.8000805@mozilla.com> <48DABB00-F56E-4725-B4FB-F0F91857CA1A@cisco.com> <55AE716E.8090305@mozilla.com> <8E255F2B-E72A-4634-A6AB-335C77BE2448@cisco.com> <2DECBC26-B567-420F-93EC-447E9B61169E@cisco.com>
From: Thomas Daede <tdaede@mozilla.com>
Message-ID: <55AF4E62.6070805@mozilla.com>
Date: Wed, 22 Jul 2015 10:03:46 +0200
User-Agent: http://a.pomf.se/cszdno.opus
MIME-Version: 1.0
In-Reply-To: <2DECBC26-B567-420F-93EC-447E9B61169E@cisco.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/I3uZPj9bBMLubPXUepUwUiYwz3c>
Cc: "video-codec@ietf.org" <video-codec@ietf.org>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Jul 2015 08:03:52 -0000

I have pending updates for a -02 version of the testing draft that
better machines the slides that I presented. I have pasted the revised
selection below. Note that the encoder parameters haven't been updated
yet, and I also plan to incorporate rate-control-less operating modes,
as per consensus in the room.

## Operating Points

Two operating modes are defined. High latency is intended for on demand
streaming, one-to-many live streaming, and stored video. Low latency is
intended for videoconferencing and remote access.

### High Latency

The encoder should be run at the best quality mode available, using the
mode that will provide the best quality per bitrate (VBR or constant
quality mode). Lookahead and/or two-pass are allowed, if supported.
Example configurations follow:

- x264: --crf=x
- x265: --crf=x
- daala: -v=x
- libvpx: --codec=vp9 --end-usage=q --cq-level=x

### Low Latency

Codecs should be run in CBR mode. The maximum allowed bitrate variance
is determined by a buffer model:

- The buffer starts out empty.
- After each frame is encoded, the buffer is filled by the number of
bits spent for the frame.
- The buffer is then emptied by (bitrate * frame duration) bits.
- The buffer fill level is checked. If it is over the limit, the test is
considered a failure.

The buffer size limit is defined by the bitrate target * 0.3 seconds.


On 07/21/2015 06:36 PM, Mo Zanaty (mzanaty) wrote:
> 300 ms (* bitrate) refers to the rate control buffer not coding latency. 
> 
> I think the testing draft should define low latency as zero frame delay, i.e. no reordering. The high latency condition can be unrestricted. 
> 
> Mo (as individual)
> 
> On Jul 21, 2015, at 6:28 PM, Ali C. Begen (abegen) <abegen@cisco.com> wrote:
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Thomas Daede
> Date: Tuesday, July 21, 2015 at 6:21 PM
> To: "Ali C. Begen", "video-codec@ietf.org"
> Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
> 
>> On 07/21/2015 06:14 PM, Ali C. Begen (abegen) wrote:
>>
>>>>>> - All of the use cases should specify either a high latency or low
>>>>>> latency requirement.
>>>>> And where is the borderline?
>>>>
>>>> What is a borderline use case? I would much rather keep the number of
>>>> configurations as low as possible.
>>>
>>> I mean what is low latency vs high latency. And who decides that?
>>
>> It is defined in draft-daede-netvc-testing-01 [1]. And some of the
>> definition should probably be moved into the requirements draft, though
>> individual codec parameters still belong in the testing draft.
>>
>> https://datatracker.ietf.org/doc/draft-daede-netvc-testing/
> 
> I searched for latency and delay, nothing showed up. The only time related number seems to be 300ms in section 5.3.
> _______________________________________________
> video-codec mailing list
> video-codec@ietf.org
> https://www.ietf.org/mailman/listinfo/video-codec
> 


From nobody Wed Jul 22 01:41:09 2015
Return-Path: <winstein@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 7237F1A0377 for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 01:41:07 -0700 (PDT)
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 1GsdtO72Pzey for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 01:41:05 -0700 (PDT)
Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (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 AE7B41A1B0D for <video-codec@ietf.org>; Wed, 22 Jul 2015 01:41:05 -0700 (PDT)
Received: by igbij6 with SMTP id ij6so130924621igb.1 for <video-codec@ietf.org>; Wed, 22 Jul 2015 01:41:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:reply-to:sender:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=pOGtwzhAqgNk3F8CL+Fpa0YY4c84rMKGGJyLlhxhzto=; b=rNg8tbkh15SdWEzm0gzPc+hFF2tj60fl3H8/tcTTt1hyA8jWgF6zbQ+Wqran0F193w LkatLPX15D68ndDEBxSkKdlYbqbrQ4cJRWupSxQK+2bXttSltTidFXmzxBTWPz01KQq3 oXfHqdy33rRdXlQbfs8CvzmhTTXLoXqHJY/Ddgi1OfV2yZlAlg1GkD8hkCqP8FpZIi93 ok1fCfBj6MJdekAhRn69MHtM5V0OIrmJCFahgUIXPPy/jrCwonr+5S25CPHqSCBRtv48 H/Sd/n15bdZrqx7m0BY1C6i+azDLI6h+8MybkZ9X87eSdoI2WxT3UbtJhUZzg3XRyLH7 g16g==
X-Received: by 10.50.143.43 with SMTP id sb11mr5739537igb.69.1437554465203; Wed, 22 Jul 2015 01:41:05 -0700 (PDT)
MIME-Version: 1.0
Sender: winstein@gmail.com
Received: by 10.107.142.141 with HTTP; Wed, 22 Jul 2015 01:40:25 -0700 (PDT)
In-Reply-To: <55AE28F6.6070100@mozilla.com>
References: <55AE28F6.6070100@mozilla.com>
From: Keith Winstein <keithw@mit.edu>
Date: Wed, 22 Jul 2015 01:40:25 -0700
X-Google-Sender-Auth: N-D32IxU33KHAPxIlvNAeCZTnJ4
Message-ID: <CAMzhQmN17crzSPQSzy3jzz+8gfu8tZr8mFyCOSmvSX1pheppAg@mail.gmail.com>
To: Thomas Daede <tdaede@mozilla.com>
Content-Type: multipart/alternative; boundary=001a1135e91a3e6e0e051b72bb29
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/AoZUuspfrqCTatDqgDyDWQvRcOQ>
Cc: "video-codec@ietf.org" <video-codec@ietf.org>
Subject: Re: [video-codec] Low-latency rate control constraints
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: keithw@mit.edu
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Jul 2015 08:41:07 -0000

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

Hello Thomas,

It seems like constraining the bitrate variation by enforcing a limited
receiver-side VBV buffer is kind of an indirect way to get at what you
really care about. Most receivers can probably buffer at least >5 megabytes
(so >5 seconds of video) with no problem. If the document wants to specify
a model for low-latency video, I think the constraint might be better
expressed in terms of latency directly.

Here would be my proposal for an idealized model for what video
conferencing would require from the video coder:

(a) The source video arrives at 30 fps, and each frame is given an "encode
time" of n/30 seconds.
(b) After being encoded, the coded frames are appended to a sender-side
FIFO.
(c) The sender-side FIFO is drained (and delivered to the receiver) at a
particular link rate given in bits per second.
(d) At the receiver, each frame is given a "display time" of the earliest
moment it can be shown to the user given when its coded representation
finishes being delivered, and any rules of the format about frame
reordering (i.e. the presentation timestamp of MPEG). The receiver doesn't
attempt isochronous presentation of the frames; it just shows each frame at
the earliest possible moment.

For the first 8 seconds, the link rate "(c)" is 4 megabits/sec, and the
coder is informed of this. At t=8 seconds, the link rate "(c)"
instantaneously changes to 500 kilobits/sec. The coder learns of this
change at t=8.25 seconds.

The figure of merit is a combination of (1) visual fidelity (e.g. PSNR,
SSIM, etc.) of the coded frames relative to the source frames, and (2) the
maximum difference between the "encode time" and "display time" of any
frame, taken over all the frames in the video.

Best regards,
Keith

On Tue, Jul 21, 2015 at 4:11 AM, Thomas Daede <tdaede@mozilla.com> wrote:

> At the Monday NETVC session, it was suggested that CBR mode with a fixed
> buffer size was not a very good representation of what rate control for
> video conferencing would do.
>
> Are there suggestions of a better model? Keep in mind that this is only
> for relatively short (~15s) clips.
>
> Another option is just to not specify CBR bounds, so that this test
> would be like the high latency test but with lookahead and 2 pass
> constraints.
>
> _______________________________________________
> video-codec mailing list
> video-codec@ietf.org
> https://www.ietf.org/mailman/listinfo/video-codec
>

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

<div dir=3D"ltr"><div><div>Hello Thomas,</div><div><br></div><div>It seems =
like constraining the bitrate variation by enforcing a limited receiver-sid=
e VBV buffer is kind of an indirect way to get at what you really care abou=
t. Most receivers can probably buffer at least &gt;5 megabytes (so &gt;5 se=
conds of video) with no problem. If the document wants to specify a model f=
or low-latency video, I think the constraint might be better expressed in t=
erms of latency directly.</div><div><br></div><div>Here would be my proposa=
l for an idealized model for what video conferencing would require from the=
 video coder:</div></div><div><br></div><div>(a) The source video arrives a=
t 30 fps, and each frame is given an &quot;encode time&quot; of n/30 second=
s.</div><div>(b) After being encoded, the coded frames are appended to a se=
nder-side FIFO.</div><div>(c) The sender-side FIFO is drained (and delivere=
d to the receiver) at a particular link rate given in bits per second.</div=
><div>(d) At the receiver, each frame is given a &quot;display time&quot; o=
f the earliest moment it can be shown to the user given when its coded repr=
esentation finishes being delivered, and any rules of the format about fram=
e reordering (i.e. the presentation timestamp of MPEG). The receiver doesn&=
#39;t attempt isochronous presentation of the frames; it just shows each fr=
ame at the earliest possible moment.</div><div><br></div><div>For the first=
 8 seconds, the link rate &quot;(c)&quot; is 4 megabits/sec, and the coder =
is informed of this. At t=3D8 seconds, the link rate &quot;(c)&quot; instan=
taneously changes to 500 kilobits/sec. The coder learns of this change at t=
=3D8.25 seconds.</div><div><br></div><div>The figure of merit is a combinat=
ion of (1) visual fidelity (e.g. PSNR, SSIM, etc.) of the coded frames rela=
tive to the source frames, and (2) the maximum difference between the &quot=
;encode time&quot; and &quot;display time&quot; of any frame, taken over al=
l the frames in the video.</div><div><br></div><div>Best regards,</div><div=
>Keith</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tu=
e, Jul 21, 2015 at 4:11 AM, Thomas Daede <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:tdaede@mozilla.com" target=3D"_blank">tdaede@mozilla.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">At the Monday NETVC session, it=
 was suggested that CBR mode with a fixed<br>
buffer size was not a very good representation of what rate control for<br>
video conferencing would do.<br>
<br>
Are there suggestions of a better model? Keep in mind that this is only<br>
for relatively short (~15s) clips.<br>
<br>
Another option is just to not specify CBR bounds, so that this test<br>
would be like the high latency test but with lookahead and 2 pass<br>
constraints.<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" rel=3D"norefe=
rrer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/video-codec</=
a><br>
</blockquote></div><br></div></div>

--001a1135e91a3e6e0e051b72bb29--


From nobody Wed Jul 22 01:53:23 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 232791ACEE3 for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 01:53:22 -0700 (PDT)
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 KKqJ0dOTPtQG for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 01:53:20 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 444931ACEE0 for <video-codec@ietf.org>; Wed, 22 Jul 2015 01:53:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4096; q=dns/txt; s=iport; t=1437555200; x=1438764800; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1kRQp515gkrdzZgUJJsRl3gjD9PibWj84yCAZvRXVRE=; b=T29mlSrJFhXnjjFPf+VJ0KIL9/rM4X7DVWeuah2+ogjHqi3TVpsfiDKo hxfB+76A/M87izuoUf6B+5DSeAajKFeIDGuKkgnNimpIUjxf1G008RAAg k6tegDPr6inCv/3qv+DTRtBjC5swSsp7J3DQiQIoReMUHNQqcud0ZJBMJ 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0APBQBUWa9V/4UNJK1bgxVUaQa7e4FrCoYBAoFGORMBAQEBAQEBgQqEIwEBAQQBAQE3NAsMBAIBCA4DAwECAR4QJwsdCAIEAQ0FiC4NzCkBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIpKgQKELlgHBoQlBZRXAYR0hz2ZESaDfG+BBUKBBAEBAQ
X-IronPort-AV: E=Sophos;i="5.15,522,1432598400"; d="scan'208";a="171223093"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jul 2015 08:53:19 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t6M8rJqw026549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 08:53:19 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.112]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 03:53:19 -0500
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: Thomas Daede <tdaede@mozilla.com>, "Ali C. Begen (abegen)" <abegen@cisco.com>
Thread-Topic: [video-codec] draft-filippov-netvc-requirements-01
Thread-Index: AQHQxFvbUJCwj88TPEK4pVRo7ndEBw==
Date: Wed, 22 Jul 2015 08:53:18 +0000
Message-ID: <D1D4CDD7.521A9%mzanaty@cisco.com>
References: <32AA73C5-0D17-4ECE-A02D-041C5147D9E5@cisco.com> <55AE60D0.3040201@mozilla.com> <29BD22C6-8790-451B-B754-ED55D2F41C90@cisco.com> <55AE6F5C.8000805@mozilla.com> <48DABB00-F56E-4725-B4FB-F0F91857CA1A@cisco.com> <55AE716E.8090305@mozilla.com> <8E255F2B-E72A-4634-A6AB-335C77BE2448@cisco.com> <2DECBC26-B567-420F-93EC-447E9B61169E@cisco.com> <55AF4E62.6070805@mozilla.com>
In-Reply-To: <55AF4E62.6070805@mozilla.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.3.150624
x-originating-ip: [64.100.32.216]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10FD67365F79A54FAF0D06EE52C85E97@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/xCilzhpPIKLSx-msKm6JgFHnDJo>
Cc: "video-codec@ietf.org" <video-codec@ietf.org>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Jul 2015 08:53:22 -0000

I see a much simpler distinction between high/low latency modes.
Low latency is zero frame delay, i.e. no reordering, lookahead, etc.
High latency is unrestricted, i.e. all tools / techniques enabled
to maximize quality or minimize bitrate / file size.

I don't think the definition of these modes should be tied to rate control
modes like VBR or CBR. While I agree interactive applications often have
constraints on both latency and peak bitrate (to remain below available
bandwidth), I think it is confusing to conflate them by defining low
latency in terms of bitrate control.

For example, under the current definition of low latency as CBR with a 300
ms rate control buffer (similar to MPEG VBV model), and no further
constraints, encoders could reorder 18 frames of 1080p60 and still claim
"low latency". I think this violates our goal. The true goal should be
absolute minimum delay, which means zero frame delay restrictions within
the encoder.

Mo (as individual)


On 7/22/15, 4:03 AM, Thomas Daede <tdaede@mozilla.com> wrote:

I have pending updates for a -02 version of the testing draft that
better machines the slides that I presented. I have pasted the revised
selection below. Note that the encoder parameters haven't been updated
yet, and I also plan to incorporate rate-control-less operating modes,
as per consensus in the room.

## Operating Points

Two operating modes are defined. High latency is intended for on demand
streaming, one-to-many live streaming, and stored video. Low latency is
intended for videoconferencing and remote access.

### High Latency

The encoder should be run at the best quality mode available, using the
mode that will provide the best quality per bitrate (VBR or constant
quality mode). Lookahead and/or two-pass are allowed, if supported.
Example configurations follow:

- x264: --crf=3Dx
- x265: --crf=3Dx
- daala: -v=3Dx
- libvpx: --codec=3Dvp9 --end-usage=3Dq --cq-level=3Dx

### Low Latency

Codecs should be run in CBR mode. The maximum allowed bitrate variance
is determined by a buffer model:

- The buffer starts out empty.
- After each frame is encoded, the buffer is filled by the number of
bits spent for the frame.
- The buffer is then emptied by (bitrate * frame duration) bits.
- The buffer fill level is checked. If it is over the limit, the test is
considered a failure.

The buffer size limit is defined by the bitrate target * 0.3 seconds.


On 07/21/2015 06:36 PM, Mo Zanaty (mzanaty) wrote:
> 300 ms (* bitrate) refers to the rate control buffer not coding latency.
>=20
> I think the testing draft should define low latency as zero frame delay,
>i.e. no reordering. The high latency condition can be unrestricted.
>=20
> Mo (as individual)
>=20
> On Jul 21, 2015, at 6:28 PM, Ali C. Begen (abegen) <abegen@cisco.com>
>wrote:
>=20
>=20
>=20
>=20
>=20
>=20
> -----Original Message-----
> From: Thomas Daede
> Date: Tuesday, July 21, 2015 at 6:21 PM
> To: "Ali C. Begen", "video-codec@ietf.org"
> Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
>=20
>> On 07/21/2015 06:14 PM, Ali C. Begen (abegen) wrote:
>>
>>>>>> - All of the use cases should specify either a high latency or low
>>>>>> latency requirement.
>>>>> And where is the borderline?
>>>>
>>>> What is a borderline use case? I would much rather keep the number of
>>>> configurations as low as possible.
>>>
>>> I mean what is low latency vs high latency. And who decides that?
>>
>> It is defined in draft-daede-netvc-testing-01 [1]. And some of the
>> definition should probably be moved into the requirements draft, though
>> individual codec parameters still belong in the testing draft.
>>
>> https://datatracker.ietf.org/doc/draft-daede-netvc-testing/
>=20
> I searched for latency and delay, nothing showed up. The only time
>related number seems to be 300ms in section 5.3.
> _______________________________________________
> video-codec mailing list
> video-codec@ietf.org
> https://www.ietf.org/mailman/listinfo/video-codec
>=20


From nobody Wed Jul 22 02:51:17 2015
Return-Path: <Alexey.Filippov@huawei.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 E33DD1A89FF for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 02:51:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 Twj349dGyLtz for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 02:51:12 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 862D21A87A7 for <video-codec@ietf.org>; Wed, 22 Jul 2015 02:51:08 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZA60985; Wed, 22 Jul 2015 09:51:06 +0000 (GMT)
Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 22 Jul 2015 10:51:05 +0100
Received: from SZXEMA508-MBS.china.huawei.com ([169.254.8.36]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Wed, 22 Jul 2015 17:50:54 +0800
From: Filippov Alexey <Alexey.Filippov@huawei.com>
To: "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: Re: [video-codec] draft-filippov-netvc-requirements-01
Thread-Index: AdDEY+SA0077AnUFRC2IsQvplos36g==
Date: Wed, 22 Jul 2015 09:50:53 +0000
Message-ID: <A95DB243D3936149BBFA3B43ED71074570525F45@szxema508-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.64.80]
Content-Type: multipart/alternative; boundary="_000_A95DB243D3936149BBFA3B43ED71074570525F45szxema508mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/ng49a7LRRjXeHR0QcBuBMHg9a74>
Cc: "tdaede at mozilla.com" <tdaede@mozilla.com>, "Ali C. Begen \(abegen\)" <abegen@cisco.com>, "mohammedsraad@raadtech.com" <mohammedsraad@raadtech.com>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Jul 2015 09:51:15 -0000

--_000_A95DB243D3936149BBFA3B43ED71074570525F45szxema508mbschi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>If you implement RFC 6285, you dont need frequent I-frames, either. This i=
s something implemented in most IPTV deployments.
Yes, RFC 6285 provides a way of how to achieve low latency for a user. If w=
e'll go back to your initial question ("And where is the borderline?"), the=
 borderline is interaction. If an immediate reaction can be needed (video c=
onferencing, switching between channels), latency should be kept low. Other=
wise, it can be high enough.

>IPTV does not (and should not) mean DASH like streaming services or progre=
ssive download. IPTV means multicast for linear delivery and unicast for Vo=
D delivery over a QoS enabled SP network (not even the open Internet).
Does it mean that if we do not have QoS enabled SP network, it is not IPTV =
anymore? I guess this definition is a bit restrictive. Many people watch mo=
vies and live programs using their SmartTV, laptops, tablets, and even smar=
tphones connected to the open Internet, not to "a QoS enabled SP network". =
I don't think it's reasonable to ignore this use case for an Internet video=
 codec (projects like Open IPTV or  Android TV )

>I gather that what is meant by "interactive" is real time communications. =
If you limit the netvc effort to only real time communications then you are=
 ensuring that it will not have a chance to be dominant once it is complete=
 because the argument for adoption will be weakened by the fact that anothe=
r codec will be needed for the high quality material.
I entirely support this point of view.

--_000_A95DB243D3936149BBFA3B43ED71074570525F45szxema508mbschi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-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-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
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]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">&gt;If you implement RFC 6285, you dont need frequen=
t I-frames, either. This is something implemented in most IPTV deployments.=
<o:p></o:p></p>
<p class=3D"MsoNormal">Yes, RFC 6285 provides a way of how to achieve low l=
atency for a user. If we&#8217;ll go back to your initial question (&#8220;=
And where is the borderline?&#8221;), the borderline is interaction. If an =
immediate reaction can be needed (video conferencing,
 switching between channels), latency should be kept low. Otherwise, it can=
 be high enough.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">&gt;IPTV does not (and should not) mean DASH like st=
reaming services or progressive download. IPTV means multicast for linear d=
elivery and unicast for VoD delivery over a QoS enabled SP network (not eve=
n the open Internet).<o:p></o:p></p>
<p class=3D"MsoNormal">Does it mean that if we do not have QoS enabled SP n=
etwork, it is not IPTV anymore? I guess this definition is a bit restrictiv=
e. Many people watch movies and live programs using their SmartTV, laptops,=
 tablets, and even smartphones connected
 to the open Internet, not to &#8220;a QoS enabled SP network&#8221;. I don=
&#8217;t think it&#8217;s reasonable to ignore this use case for an Interne=
t video codec (projects like Open IPTV or&nbsp; Android TV )<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">&gt;I gather that what is meant by &quot;interactive=
&quot; is real time communications. If you limit the netvc effort to only r=
eal time communications then you are ensuring that it will not have a chanc=
e to be dominant once it is complete because the
 argument for adoption will be weakened by the fact that another codec will=
 be needed for the high quality material.<o:p></o:p></p>
<p class=3D"MsoNormal">I entirely support this point of view.<o:p></o:p></p=
>
</div>
</body>
</html>

--_000_A95DB243D3936149BBFA3B43ED71074570525F45szxema508mbschi_--


From nobody Wed Jul 22 03:02:47 2015
Return-Path: <abegen@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 031591ACE16 for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 03:02:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, 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 Wb2mFFZNnIds for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 03:02:43 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FAC91ACD3C for <video-codec@ietf.org>; Wed, 22 Jul 2015 03:02:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14542; q=dns/txt; s=iport; t=1437559363; x=1438768963; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=D14G+QKslYT6k6pAZ/SoJlh0Da0qcZ6bRdlQeSeAZ9w=; b=doQGDZ6bqetKtt2NynS5qC1NXP6aRxqMk+/Wtb80yvnaPbakVKOhn4m+ ItohGBHFpPr7jk+wDD/NKrDDiAvllLixKpIoyRprsd4f7OLrewLz87u6n yBhoEAIG4K4T5p4Dhz6YY6roAiWW/FJPcJlJ1knGCL9z2HWVZYgt9vveh w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CSBQD3aK9V/5JdJa1bgkhNVGkGgx24Y4FtgkuDPgIcgSo5EwEBAQEBAQGBCoQjAQEBBCMKTBACAQgRAwECKAMCAgIwFAkIAQEEAQ0FH4gPtg+WNgEBAQEBAQEBAQEBAQEBAQEBAQEBAReLTIQuRxEHCYJfL4EUBZRXAYR0hRSCKYFDFTGTJ4NhJoN8b4EFQoEEAQEB
X-IronPort-AV: E=Sophos;i="5.15,522,1432598400";  d="scan'208,217";a="171075032"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-6.cisco.com with ESMTP; 22 Jul 2015 10:02:42 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t6MA2gOp014076 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 10:02:42 GMT
Received: from xmb-aln-x01.cisco.com ([169.254.2.64]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 05:02:42 -0500
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: Filippov Alexey <Alexey.Filippov@huawei.com>, "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: [video-codec] draft-filippov-netvc-requirements-01
Thread-Index: AdDEY+SAW0GCvpXJZECxIZTezzBngAAPFTeA
Date: Wed, 22 Jul 2015 10:02:41 +0000
Message-ID: <F9407E60-EA4F-4AA9-91A6-0303912D721B@cisco.com>
References: <A95DB243D3936149BBFA3B43ED71074570525F45@szxema508-mbs.china.huawei.com>
In-Reply-To: <A95DB243D3936149BBFA3B43ED71074570525F45@szxema508-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.150701
x-originating-ip: [10.61.214.86]
Content-Type: multipart/alternative; boundary="_000_F9407E60EA4F4AA991A60303912D721Bciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/yD31HoMWqSmsM91x7APOGbVG_r8>
Cc: "tdaede at mozilla.com" <tdaede@mozilla.com>, "mohammedsraad@raadtech.com" <mohammedsraad@raadtech.com>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Jul 2015 10:02:46 -0000

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

DQoNCkZyb206IEZpbGlwcG92IEFsZXhleQ0KRGF0ZTogV2VkbmVzZGF5LCBKdWx5IDIyLCAyMDE1
IGF0IDExOjUwIEFNDQpUbzogInZpZGVvLWNvZGVjQGlldGYub3JnPG1haWx0bzp2aWRlby1jb2Rl
Y0BpZXRmLm9yZz4iDQpDYzogIkFsaSBDLiBCZWdlbiIsIE1vaGFtbWVkIFJhYWQsICJ0ZGFlZGUg
YXQgbW96aWxsYS5jb20iDQpTdWJqZWN0OiBSZTogW3ZpZGVvLWNvZGVjXSBkcmFmdC1maWxpcHBv
di1uZXR2Yy1yZXF1aXJlbWVudHMtMDENCg0KPklmIHlvdSBpbXBsZW1lbnQgUkZDIDYyODUsIHlv
dSBkb250IG5lZWQgZnJlcXVlbnQgSS1mcmFtZXMsIGVpdGhlci4gVGhpcyBpcyBzb21ldGhpbmcg
aW1wbGVtZW50ZWQgaW4gbW9zdCBJUFRWIGRlcGxveW1lbnRzLg0KWWVzLCBSRkMgNjI4NSBwcm92
aWRlcyBhIHdheSBvZiBob3cgdG8gYWNoaWV2ZSBsb3cgbGF0ZW5jeSBmb3IgYSB1c2VyLiBJZiB3
ZeKAmWxsIGdvIGJhY2sgdG8geW91ciBpbml0aWFsIHF1ZXN0aW9uICjigJxBbmQgd2hlcmUgaXMg
dGhlIGJvcmRlcmxpbmU/4oCdKSwgdGhlIGJvcmRlcmxpbmUgaXMgaW50ZXJhY3Rpb24uIElmIGFu
IGltbWVkaWF0ZSByZWFjdGlvbiBjYW4gYmUgbmVlZGVkICh2aWRlbyBjb25mZXJlbmNpbmcsIHN3
aXRjaGluZyBiZXR3ZWVuIGNoYW5uZWxzKSwgbGF0ZW5jeSBzaG91bGQgYmUga2VwdCBsb3cuIE90
aGVyd2lzZSwgaXQgY2FuIGJlIGhpZ2ggZW5vdWdoLg0KDQpUaGVyZSBpcyBhICpodWdlKiBkaWZm
ZXJlbmNlIGZvciBhIGNhc3VhbCB1c2Vy4oCZcyBmb3JnaXZlbmVzcyBiZXR3ZWVuIHdoZW4gaGUg
ZG9lcyBhIGNoYW5uZWwgY2hhbmdlIHRpbWUgdnMuIGhlIHVzZXMgc2t5cGUsIHdlYmV4IG9yIGFu
b3RoZXIgY29udmVyc2F0aW9uYWwgYXBwbGljYXRpb24uDQoNCk1vc3QgcGVvcGxlIGRvIG5vdCBu
b3RpY2UgYW55dGhpbmcgaWYgdGhlIGNoYW5uZWwgY2hhbmdlIHRpbWUgaXMgMTAwIG1zIHZzIDkw
MCBtcyAoYW55dGhpbmcgbGVzcyB0aGFuIGEgc2Vjb25kIGlzIG1vcmUgdGhhbiBhY2NlcHRhYmxl
IHRvIHVzZXJzKS4gV2hlcmVhcyAxMDBtcyB2cyBldmVuIDMwMCBtcyB3b3VsZCBtYWtlIGEgYmln
IGRpZmZlcmVuY2UgaW4gaG93IG11Y2ggeW91IHdpbGwgZW5qb3kgeW91ciBza3lwZSB0YWxrLg0K
DQpUaGUg4oCcaW50ZXJhY3RpdmXigJ0gYXBwbGljYXRpb25zIG9uIHlvdXIgc2V0dG9wIG9yIGNv
bm5lY3RlZCBUViBkbyBub3QgZGVtYW5kIGEgbG93IGxhdGVuY3kgYXMgbXVjaCBhcyBza3lwZS1s
aWtlIGFwcHMgZG8uIE1vcmUgdGhhbiBvZnRlbiwgdGhlIGxhZyBvbiBUVnMsIHNldHRvcHMgYXJl
IGR1ZSB0byB0aGUgaGFyZHdhcmUgb3IgdGhlIHNvZnR3YXJlLCBub3QgdmlkZW8gZW5jb2Rpbmcv
ZGVjb2RpbmcgcmVsYXRlZCBkZWxheS4gU28gZXZlbiBpZiB5b3UgaGF2ZSB0aGUgYmVzdCBjb2Rl
YywgaXQgd29u4oCZdCBtYWtlIGEgYmlnIGRpZmZlcmVuY2UuDQoNCg0KPklQVFYgZG9lcyBub3Qg
KGFuZCBzaG91bGQgbm90KSBtZWFuIERBU0ggbGlrZSBzdHJlYW1pbmcgc2VydmljZXMgb3IgcHJv
Z3Jlc3NpdmUgZG93bmxvYWQuIElQVFYgbWVhbnMgbXVsdGljYXN0IGZvciBsaW5lYXIgZGVsaXZl
cnkgYW5kIHVuaWNhc3QgZm9yIFZvRCBkZWxpdmVyeSBvdmVyIGEgUW9TIGVuYWJsZWQgU1AgbmV0
d29yayAobm90IGV2ZW4gdGhlIG9wZW4gSW50ZXJuZXQpLg0KRG9lcyBpdCBtZWFuIHRoYXQgaWYg
d2UgZG8gbm90IGhhdmUgUW9TIGVuYWJsZWQgU1AgbmV0d29yaywgaXQgaXMgbm90IElQVFYgYW55
bW9yZT8NCg0KVHJ1ZS4gVGhhdCBpcyB3aGF0IElQVFYgbWVhbnMuIFRoZSB0ZXJtIHlvdSBhcmUg
bG9va2luZyBmb3IgbmV0d29ya3Mgd2l0aG91dCBTUCBRb1MgaXMg4oCcSVAgKG9yIGludGVybmV0
KSB2aWRlb+KAnSBub3QgSVBUVi4NCg0KSSBndWVzcyB0aGlzIGRlZmluaXRpb24gaXMgYSBiaXQg
cmVzdHJpY3RpdmUuIE1hbnkgcGVvcGxlIHdhdGNoIG1vdmllcyBhbmQgbGl2ZSBwcm9ncmFtcyB1
c2luZyB0aGVpciBTbWFydFRWLCBsYXB0b3BzLCB0YWJsZXRzLCBhbmQgZXZlbiBzbWFydHBob25l
cyBjb25uZWN0ZWQgdG8gdGhlIG9wZW4gSW50ZXJuZXQsIG5vdCB0byDigJxhIFFvUyBlbmFibGVk
IFNQIG5ldHdvcmvigJ0uDQoNCkFuZCB0aGF0IGlzIElQIHZpZGVvLCBhbmQgc29tZSBvZiB1cyBj
YWxsIGlzIOKAnG92ZXIgdGhlIHRvcOKAnSB2aWRlby4gSXQgaXMgY2VydGFpbmx5IG5vdCBJUFRW
IGluIHN0cmljdCBzZW5zZS4NCg0KSSBkb27igJl0IHRoaW5rIGl04oCZcyByZWFzb25hYmxlIHRv
IGlnbm9yZSB0aGlzIHVzZSBjYXNlIGZvciBhbiBJbnRlcm5ldCB2aWRlbyBjb2RlYyAocHJvamVj
dHMgbGlrZSBPcGVuIElQVFYgb3IgIEFuZHJvaWQgVFYgKQ0KDQo+SSBnYXRoZXIgdGhhdCB3aGF0
IGlzIG1lYW50IGJ5ICJpbnRlcmFjdGl2ZSIgaXMgcmVhbCB0aW1lIGNvbW11bmljYXRpb25zLiBJ
ZiB5b3UgbGltaXQgdGhlIG5ldHZjIGVmZm9ydCB0byBvbmx5IHJlYWwgdGltZSBjb21tdW5pY2F0
aW9ucyB0aGVuIHlvdSBhcmUgZW5zdXJpbmcgdGhhdCBpdCB3aWxsIG5vdCBoYXZlIGEgY2hhbmNl
IHRvIGJlIGRvbWluYW50IG9uY2UgaXQgaXMgY29tcGxldGUgYmVjYXVzZSB0aGUgYXJndW1lbnQg
Zm9yIGFkb3B0aW9uIHdpbGwgYmUgd2Vha2VuZWQgYnkgdGhlIGZhY3QgdGhhdCBhbm90aGVyIGNv
ZGVjIHdpbGwgYmUgbmVlZGVkIGZvciB0aGUgaGlnaCBxdWFsaXR5IG1hdGVyaWFsLg0KSSBlbnRp
cmVseSBzdXBwb3J0IHRoaXMgcG9pbnQgb2Ygdmlldy4NCg==

--_000_F9407E60EA4F4AA991A60303912D721Bciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <29F8FF6DF624C849806A85A9D15240CD@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7Ij4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUi
PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFu
IGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxp
YnJpOyBmb250LXNpemU6MTJwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVS
LUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1C
T1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVS
LVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJ
TkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bh
bj5GaWxpcHBvdiBBbGV4ZXk8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0
ZTogPC9zcGFuPldlZG5lc2RheSwgSnVseSAyMiwgMjAxNSBhdCAxMTo1MCBBTTxicj4NCjxzcGFu
IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0
bzp2aWRlby1jb2RlY0BpZXRmLm9yZyI+dmlkZW8tY29kZWNAaWV0Zi5vcmc8L2E+JnF1b3Q7PGJy
Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7QWxpIEMu
IEJlZ2VuJnF1b3Q7LCBNb2hhbW1lZCBSYWFkLCAmcXVvdDt0ZGFlZGUgYXQgbW96aWxsYS5jb20m
cXVvdDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFu
PlJlOiBbdmlkZW8tY29kZWNdIGRyYWZ0LWZpbGlwcG92LW5ldHZjLXJlcXVpcmVtZW50cy0wMTxi
cj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9P
S19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBz
b2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdiB4bWxuczp2PSJ1
cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29t
Om9mZmljZTp3b3JkIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmlj
ZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4N
CjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRl
cmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250
LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1
IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3Nl
LTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv
Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn
aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs
aWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu
ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N
CnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJ
Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N
Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdv
cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w
aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48
L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i
ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z
byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9
ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8
ZGl2IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9
IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7SWYgeW91IGltcGxlbWVu
dCBSRkMgNjI4NSwgeW91IGRvbnQgbmVlZCBmcmVxdWVudCBJLWZyYW1lcywgZWl0aGVyLiBUaGlz
IGlzIHNvbWV0aGluZyBpbXBsZW1lbnRlZCBpbiBtb3N0IElQVFYgZGVwbG95bWVudHMuPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIFJGQyA2Mjg1IHByb3ZpZGVzIGEg
d2F5IG9mIGhvdyB0byBhY2hpZXZlIGxvdyBsYXRlbmN5IGZvciBhIHVzZXIuIElmIHdl4oCZbGwg
Z28gYmFjayB0byB5b3VyIGluaXRpYWwgcXVlc3Rpb24gKOKAnEFuZCB3aGVyZSBpcyB0aGUgYm9y
ZGVybGluZT/igJ0pLCB0aGUgYm9yZGVybGluZSBpcyBpbnRlcmFjdGlvbi4gSWYgYW4gaW1tZWRp
YXRlIHJlYWN0aW9uIGNhbiBiZSBuZWVkZWQgKHZpZGVvIGNvbmZlcmVuY2luZywNCiBzd2l0Y2hp
bmcgYmV0d2VlbiBjaGFubmVscyksIGxhdGVuY3kgc2hvdWxkIGJlIGtlcHQgbG93LiBPdGhlcndp
c2UsIGl0IGNhbiBiZSBoaWdoIGVub3VnaC48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGVyZSBpcyBh
ICpodWdlKiBkaWZmZXJlbmNlIGZvciBhIGNhc3VhbCB1c2Vy4oCZcyBmb3JnaXZlbmVzcyBiZXR3
ZWVuIHdoZW4gaGUgZG9lcyBhIGNoYW5uZWwgY2hhbmdlIHRpbWUgdnMuIGhlIHVzZXMgc2t5cGUs
IHdlYmV4IG9yIGFub3RoZXIgY29udmVyc2F0aW9uYWwgYXBwbGljYXRpb24uJm5ic3A7PC9kaXY+
DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Nb3N0IHBlb3BsZSBkbyBub3Qgbm90aWNlIGFueXRo
aW5nIGlmIHRoZSBjaGFubmVsIGNoYW5nZSB0aW1lIGlzIDEwMCBtcyB2cyA5MDAgbXMgKGFueXRo
aW5nIGxlc3MgdGhhbiBhIHNlY29uZCBpcyBtb3JlIHRoYW4gYWNjZXB0YWJsZSB0byB1c2Vycyku
IFdoZXJlYXMgMTAwbXMgdnMgZXZlbiAzMDAgbXMgd291bGQgbWFrZSBhIGJpZyBkaWZmZXJlbmNl
IGluIGhvdyBtdWNoIHlvdSB3aWxsIGVuam95IHlvdXIgc2t5cGUgdGFsay48L2Rpdj4NCjxkaXY+
PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSDigJxpbnRlcmFjdGl2ZeKAnSBhcHBsaWNhdGlvbnMgb24g
eW91ciBzZXR0b3Agb3IgY29ubmVjdGVkIFRWIGRvIG5vdCBkZW1hbmQgYSBsb3cgbGF0ZW5jeSBh
cyBtdWNoIGFzIHNreXBlLWxpa2UgYXBwcyBkby4gTW9yZSB0aGFuIG9mdGVuLCB0aGUgbGFnIG9u
IFRWcywgc2V0dG9wcyBhcmUgZHVlIHRvIHRoZSBoYXJkd2FyZSBvciB0aGUgc29mdHdhcmUsIG5v
dCB2aWRlbyBlbmNvZGluZy9kZWNvZGluZyByZWxhdGVkIGRlbGF5LiBTbyBldmVuDQogaWYgeW91
IGhhdmUgdGhlIGJlc3QgY29kZWMsIGl0IHdvbuKAmXQgbWFrZSBhIGJpZyBkaWZmZXJlbmNlLjwv
ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+
DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5
bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lO
OjAgMCAwIDU7Ij4NCjxkaXYgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi
IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6
dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDov
L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov
L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8ZGl2IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl
IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O0lQVFYgZG9lcyBub3QgKGFu
ZCBzaG91bGQgbm90KSBtZWFuIERBU0ggbGlrZSBzdHJlYW1pbmcgc2VydmljZXMgb3IgcHJvZ3Jl
c3NpdmUgZG93bmxvYWQuIElQVFYgbWVhbnMgbXVsdGljYXN0IGZvciBsaW5lYXIgZGVsaXZlcnkg
YW5kIHVuaWNhc3QgZm9yIFZvRCBkZWxpdmVyeSBvdmVyIGEgUW9TIGVuYWJsZWQgU1AgbmV0d29y
ayAobm90IGV2ZW4gdGhlIG9wZW4gSW50ZXJuZXQpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+RG9lcyBpdCBtZWFuIHRoYXQgaWYgd2UgZG8gbm90IGhhdmUgUW9TIGVuYWJs
ZWQgU1AgbmV0d29yaywgaXQgaXMgbm90IElQVFYgYW55bW9yZT8NCjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8
ZGl2PlRydWUuIFRoYXQgaXMgd2hhdCBJUFRWIG1lYW5zLiBUaGUgdGVybSB5b3UgYXJlIGxvb2tp
bmcgZm9yIG5ldHdvcmtzIHdpdGhvdXQgU1AgUW9TIGlzIOKAnElQIChvciBpbnRlcm5ldCkgdmlk
ZW/igJ0gbm90IElQVFYuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19T
UkNfQk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElP
Tl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElO
RzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdiB4bWxuczp2PSJ1cm46c2NoZW1hcy1t
aWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp
Y2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3Jk
IiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29t
bWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxkaXYgbGFuZz0i
RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp
b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZ3Vlc3MgdGhpcyBkZWZpbml0aW9uIGlzIGEg
Yml0IHJlc3RyaWN0aXZlLiBNYW55IHBlb3BsZSB3YXRjaCBtb3ZpZXMgYW5kIGxpdmUgcHJvZ3Jh
bXMgdXNpbmcgdGhlaXIgU21hcnRUViwgbGFwdG9wcywgdGFibGV0cywgYW5kIGV2ZW4gc21hcnRw
aG9uZXMgY29ubmVjdGVkIHRvIHRoZSBvcGVuIEludGVybmV0LCBub3QgdG8g4oCcYSBRb1MgZW5h
YmxlZCBTUCBuZXR3b3Jr4oCdLg0KPC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j
a3F1b3RlPg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QW5kIHRoYXQgaXMgSVAg
dmlkZW8sIGFuZCBzb21lIG9mIHVzIGNhbGwgaXMg4oCcb3ZlciB0aGUgdG9w4oCdIHZpZGVvLiBJ
dCBpcyBjZXJ0YWlubHkgbm90IElQVFYgaW4gc3RyaWN0IHNlbnNlLjwvZGl2Pg0KPGRpdj48YnI+
DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBp
ZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZU
OiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxk
aXYgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpz
Y2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMt
bWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9z
b2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIv
UkVDLWh0bWw0MCI+DQo8ZGl2IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl
Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRv
buKAmXQgdGhpbmsgaXTigJlzIHJlYXNvbmFibGUgdG8gaWdub3JlIHRoaXMgdXNlIGNhc2UgZm9y
IGFuIEludGVybmV0IHZpZGVvIGNvZGVjIChwcm9qZWN0cyBsaWtlIE9wZW4gSVBUViBvciZuYnNw
OyBBbmRyb2lkIFRWICk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O0kgZ2F0aGVyIHRoYXQg
d2hhdCBpcyBtZWFudCBieSAmcXVvdDtpbnRlcmFjdGl2ZSZxdW90OyBpcyByZWFsIHRpbWUgY29t
bXVuaWNhdGlvbnMuIElmIHlvdSBsaW1pdCB0aGUgbmV0dmMgZWZmb3J0IHRvIG9ubHkgcmVhbCB0
aW1lIGNvbW11bmljYXRpb25zIHRoZW4geW91IGFyZSBlbnN1cmluZyB0aGF0IGl0IHdpbGwgbm90
IGhhdmUgYSBjaGFuY2UgdG8gYmUgZG9taW5hbnQgb25jZSBpdCBpcyBjb21wbGV0ZSBiZWNhdXNl
IHRoZQ0KIGFyZ3VtZW50IGZvciBhZG9wdGlvbiB3aWxsIGJlIHdlYWtlbmVkIGJ5IHRoZSBmYWN0
IHRoYXQgYW5vdGhlciBjb2RlYyB3aWxsIGJlIG5lZWRlZCBmb3IgdGhlIGhpZ2ggcXVhbGl0eSBt
YXRlcmlhbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZW50aXJlbHkg
c3VwcG9ydCB0aGlzIHBvaW50IG9mIHZpZXcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_F9407E60EA4F4AA991A60303912D721Bciscocom_--


From nobody Wed Jul 22 04:18:56 2015
Return-Path: <Alexey.Filippov@huawei.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 B5B441B2A5F for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 04:18:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 7Lxinttg0xS2 for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 04:18:52 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBDE01A00BB for <video-codec@ietf.org>; Wed, 22 Jul 2015 04:18:51 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVL52429; Wed, 22 Jul 2015 11:18:50 +0000 (GMT)
Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 22 Jul 2015 12:18:49 +0100
Received: from SZXEMA508-MBS.china.huawei.com ([169.254.8.36]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Wed, 22 Jul 2015 19:18:39 +0800
From: Filippov Alexey <Alexey.Filippov@huawei.com>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>, "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: [video-codec] draft-filippov-netvc-requirements-01
Thread-Index: AQHQxGWSZM2Xvj5fIU26+3ZNKi5INZ3nVpZw
Date: Wed, 22 Jul 2015 11:18:38 +0000
Message-ID: <A95DB243D3936149BBFA3B43ED7107457052622F@szxema508-mbs.china.huawei.com>
References: <A95DB243D3936149BBFA3B43ED71074570525F45@szxema508-mbs.china.huawei.com> <F9407E60-EA4F-4AA9-91A6-0303912D721B@cisco.com>
In-Reply-To: <F9407E60-EA4F-4AA9-91A6-0303912D721B@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.74.78]
Content-Type: multipart/alternative; boundary="_000_A95DB243D3936149BBFA3B43ED7107457052622Fszxema508mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/XF-URQw21DXi21omol_ChIUM-i0>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Jul 2015 11:18:54 -0000

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

PlRoZXJlIGlzIGEgKmh1Z2UqIGRpZmZlcmVuY2UgZm9yIGEgY2FzdWFsIHVzZXLigJlzIGZvcmdp
dmVuZXNzIGJldHdlZW4gd2hlbiBoZSBkb2VzIGEgY2hhbm5lbCBjaGFuZ2UgdGltZSB2cy4gaGUg
dXNlcyBza3lwZSwgd2ViZXggb3IgYW5vdGhlciBjb252ZXJzYXRpb25hbCBhcHBsaWNhdGlvbi4N
Cg0KPk1vc3QgcGVvcGxlIGRvIG5vdCBub3RpY2UgYW55dGhpbmcgaWYgdGhlIGNoYW5uZWwgY2hh
bmdlIHRpbWUgaXMgMTAwIG1zIHZzIDkwMCBtcyAoYW55dGhpbmcgbGVzcyB0aGFuIGEgc2Vjb25k
IGlzIG1vcmUgdGhhbiBhY2NlcHRhYmxlIHRvIHVzZXJzKS4gV2hlcmVhcyAxMDBtcyB2cyBldmVu
IDMwMCBtcyB3b3VsZCBtYWtlIGEgYmlnIGRpZmZlcmVuY2UgaW4gaG93IG11Y2ggeW91IHdpbGwg
ZW5qb3kgeW91ciBza3lwZSB0YWxrLg0KDQpJIGFncmVlIHRoYXQgdGhlIHRvbGVyYW5jZSBmb3Ig
ZGVsYXkgaXMgbW9yZSBpbiB0aGUgY2FzZSBvZiBjaGFubmVsIGNoYW5nZSBidXQgaXQgZG9lcyBu
b3QgbWVhbiB0aGF0IGFueSBkZWxheSBpcyBhY2NlcHRhYmxlLiBZZXMsIHRoZSBhcHByb3ByaWF0
ZSBjaGFubmVsIGNoYW5nZSB0aW1lIGlzIGxlc3MgdGhhbiAxIHNlYyBidXQgZm9yIHZpZGVvIG9u
IGRlbWFuZCwgNSwgMTUgc2VjIG9yIG1vcmUgYXJlIE9LLiBTb21lIHBlb3BsZSBhcmUgcmVhZHkg
dG8gd2FpdCAzMCBtaW4gd2hpbGUgZG93bmxvYWRpbmcgYSBtb3ZpZSBiZWNhdXNlIG5vIHJlYWwt
dGltZSBpbnRlcmFjdGlvbiB3aXRoIHRoZSB2aWRlbyBjb250ZW50IGlzIHJlcXVpcmVkLiBBbm90
aGVyIHVzZS1jYXNlIHdpdGhvdXQgaW50ZXJhY3Rpb24gaXMgdXBsb2FkaW5nIHZpZGVvIHRvIGEg
dmlkZW8gaG9zdGluZyBzZXJ2ZXIuIEl0IGNhbiB0YWtlLCBmb3IgZXhhbXBsZSwgNSBtaW4gYW5k
IHRoaXMgdGltZSBhY2NlcHRhYmxlIGJlY2F1c2UgYW55IHJlYWwtdGltZSBpbnRlcmFjdGlvbiBp
cyBub3QgbmVlZGVkLiBZb3UgbWVudGlvbmVkIHRoYXQgMTAwbXMgdnMgZXZlbiAzMDAgbXMgbWFr
ZSBhIGJpZyBkaWZmZXJlbmNlIGZvciBjb252ZXJzYXRpb25hbCBhcHBsaWNhdGlvbnMgYnV0IGZv
ciBnYW1lIHN0cmVhbWluZywgdGhpcyBsYXRlbmN5IGNhbiBiZSBldmVuIG1vcmUgY3J1Y2lhbCAo
QlRXLCB3aGF0IGlzIG1vcmUgaW50ZXJhY3RpdmUgdGhhbiBnYW1lcyBvdmVyIHRoZSBJbnRlcm5l
dD8gQnV0IHlvdSBwcm9wb3NlIHRvIHJlbW92ZSB0aGlzIHVzZSBjYXNlKS4gT2YgY291cnNlLCBh
IGNvbmNyZXRlIHZhbHVlIGRlcGVuZHMgb24gdGhlIHR5cGUgb2YgaW50ZXJhY3Rpb24uIEhvd2V2
ZXIsIHRoZSBib3JkZXJsaW5lIGJldHdlZW4gbG93LWxhdGVuY3kgYW5kIGhpZ2gtbGF0ZW5jeSBh
cHBsaWNhdGlvbnMgaXMgaW4gdGhlIG5lY2Vzc2l0eSBvZiBpbnRlcmFjdGlvbiB3aXRoIHRoZSB2
aWRlbyBjb250ZW50IChpdOKAmXMgbm90IGp1c3QgbXkgb3BpbmlvbjogIGh0dHA6Ly93d3cuY2Fz
dC1pbmMuY29tL2Jsb2cvd2hpdGUtcGFwZXItdW5kZXJzdGFuZGluZy1hbmQtcmVkdWNpbmctbGF0
ZW5jeS1pbi12aWRlby1jb21wcmVzc2lvbi1zeXN0ZW1zKS4NCg0KPlRoZSDigJxpbnRlcmFjdGl2
ZeKAnSBhcHBsaWNhdGlvbnMgb24geW91ciBzZXR0b3Agb3IgY29ubmVjdGVkIFRWIGRvIG5vdCBk
ZW1hbmQgYSBsb3cgbGF0ZW5jeSBhcyBtdWNoIGFzIHNreXBlLWxpa2UgYXBwcyBkby4gTW9yZSB0
aGFuIG9mdGVuLCB0aGUgbGFnIG9uIFRWcywgc2V0dG9wcyBhcmUgZHVlIHRvIHRoZSBoYXJkd2Fy
ZSBvciB0aGUgc29mdHdhcmUsIG5vdCB2aWRlbyBlbmNvZGluZy9kZWNvZGluZyByZWxhdGVkIGRl
bGF5LiBTbyBldmVuIGlmIHlvdSBoYXZlIHRoZSBiZXN0IGNvZGVjLCBpdCB3b27igJl0IG1ha2Ug
YSBiaWcgZGlmZmVyZW5jZQ0KSWYgZ3Vlc3MgaWYgeW91IGhhdmUgdGhlIGJlc3QgY29kZWMgYnV0
IHRoZSBkZS1qaXR0ZXIgYnVmZmVyIHNpemUgaXMgYmlnIG9yIEhXL1NXIGRvZXNu4oCZdCB3b3Jr
IHdlbGwsIGl0IHdvbuKAmXQgbWFrZSBhIGJpZyBkaWZmZXJlbmNlIGFzIHdlbGwuIE9idmlvdXNs
eSwgbG93LWRlbGF5IGNvZGVjIGRvZXMgbm90IGd1YXJhbnRlZSBsb3ctZGVsYXkgc29sdXRpb24u
IFdoYXQgd2UgY291bGQgKGFuZCBwcm9iYWJseSBzaG91bGQpIGRvIGlzIHRvIHNwZWNpZnkgdmFs
dWVzIG9mIGRlbGF5IHRoYXQgY291bGQgYmUgaW50cm9kdWNlZCBieSBhIGNvZGVjLg0KDQo+VHJ1
ZS4gVGhhdCBpcyB3aGF0IElQVFYgbWVhbnMuIFRoZSB0ZXJtIHlvdSBhcmUgbG9va2luZyBmb3Ig
bmV0d29ya3Mgd2l0aG91dCBTUCBRb1MgaXMg4oCcSVAgKG9yIGludGVybmV0KSB2aWRlb+KAnSBu
b3QgSVBUVi4NCkZyb20gdGhlIGNvZGVjIHBvaW50IG9mIHZpZXcgdGhlIG9ubHkgZGlmZmVyZW5j
ZSBiZXR3ZWVuIOKAnElQVFbigJ0gYW5kIOKAnElQIHZpZGVv4oCdKE9UVCwgT3BlbklQVFYsIGV0
Yy4pICBpcyBtYW5hZ2VkIG9yIHVubWFuYWdlZCBuZXR3b3JrIChpLmUuIGVycm9yIHJvYnVzdG5l
c3MpLiBDb3JyZWN0PyBJZiBzbywgd2UgY2FuIGNvbnNpZGVyIHRoZXNlIHR3byBhcHBsaWNhdGlv
bnMgYXMgYSBzaW5nbGUgdXNlLWNhc2Ugd2l0aCBhIHJlcXVpcmVtZW50IGZvciBlcnJvciByZXNp
bGllbmNlIGlmIHRoZSBuZXR3b3JrIGlzIHVubWFuYWdlZC4NCkluIHRoaXMgY2FzZSwgbXkgbWFp
biBxdWVzdGlvbiBpcyB3aGV0aGVyIHlvdSBtaW5kIHRvIGNvbnNpZGVyIE9UVCB2aWRlbyBhcyBh
IHVzZSBjYXNlIGZvciBORVRWQyBjb2RlYyBvciBub3Q/DQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2
IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs
aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh
bnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp
c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNl
dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5
OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv
bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6
IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi
O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou
TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6
MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn
aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv
cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh
cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm
XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi
Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94
bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg
dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDtUaGVyZSBpcyBhICpodWdl
KiBkaWZmZXJlbmNlIGZvciBhIGNhc3VhbCB1c2Vy4oCZcyBmb3JnaXZlbmVzcyBiZXR3ZWVuIHdo
ZW4gaGUgZG9lcyBhIGNoYW5uZWwgY2hhbmdlIHRpbWUgdnMuIGhlIHVzZXMgc2t5cGUsIHdlYmV4
IG9yIGFub3RoZXIgY29udmVyc2F0aW9uYWwgYXBwbGljYXRpb24uDQo8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDtNb3N0IHBlb3BsZSBkbyBub3Qgbm90aWNlIGFueXRo
aW5nIGlmIHRoZSBjaGFubmVsIGNoYW5nZSB0aW1lIGlzIDEwMCBtcyB2cyA5MDAgbXMgKGFueXRo
aW5nIGxlc3MgdGhhbiBhIHNlY29uZCBpcyBtb3JlIHRoYW4gYWNjZXB0YWJsZSB0byB1c2Vycyku
IFdoZXJlYXMgMTAwbXMgdnMgZXZlbiAzMDAgbXMgd291bGQgbWFrZSBhIGJpZyBkaWZmZXJlbmNl
IGluIGhvdw0KIG11Y2ggeW91IHdpbGwgZW5qb3kgeW91ciBza3lwZSB0YWxrLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB0aGF0IHRoZSB0b2xlcmFuY2UgZm9y
IGRlbGF5IGlzIG1vcmUgaW4gdGhlIGNhc2Ugb2YgY2hhbm5lbCBjaGFuZ2UgYnV0IGl0IGRvZXMg
bm90IG1lYW4gdGhhdCBhbnkgZGVsYXkgaXMgYWNjZXB0YWJsZS4gWWVzLCB0aGUgYXBwcm9wcmlh
dGUgY2hhbm5lbCBjaGFuZ2UgdGltZSBpcyBsZXNzIHRoYW4gMSBzZWMgYnV0IGZvciB2aWRlbyBv
biBkZW1hbmQsDQogNSwgMTUgc2VjIG9yIG1vcmUgYXJlIE9LLiBTb21lIHBlb3BsZSBhcmUgcmVh
ZHkgdG8gd2FpdCAzMCBtaW4gd2hpbGUgZG93bmxvYWRpbmcgYSBtb3ZpZSBiZWNhdXNlIG5vIHJl
YWwtdGltZSBpbnRlcmFjdGlvbiB3aXRoIHRoZSB2aWRlbyBjb250ZW50IGlzIHJlcXVpcmVkLiBB
bm90aGVyIHVzZS1jYXNlIHdpdGhvdXQgaW50ZXJhY3Rpb24gaXMgdXBsb2FkaW5nIHZpZGVvIHRv
IGEgdmlkZW8gaG9zdGluZyBzZXJ2ZXIuIEl0IGNhbiB0YWtlLCBmb3INCiBleGFtcGxlLCA1IG1p
biBhbmQgdGhpcyB0aW1lIGFjY2VwdGFibGUgYmVjYXVzZSBhbnkgcmVhbC10aW1lIGludGVyYWN0
aW9uIGlzIG5vdCBuZWVkZWQuIFlvdSBtZW50aW9uZWQgdGhhdCAxMDBtcyB2cyBldmVuIDMwMCBt
cyBtYWtlIGEgYmlnIGRpZmZlcmVuY2UgZm9yIGNvbnZlcnNhdGlvbmFsIGFwcGxpY2F0aW9ucyBi
dXQgZm9yIGdhbWUgc3RyZWFtaW5nLCB0aGlzIGxhdGVuY3kgY2FuIGJlIGV2ZW4gbW9yZSBjcnVj
aWFsIChCVFcsIHdoYXQNCiBpcyBtb3JlIGludGVyYWN0aXZlIHRoYW4gZ2FtZXMgb3ZlciB0aGUg
SW50ZXJuZXQ/IEJ1dCB5b3UgcHJvcG9zZSB0byByZW1vdmUgdGhpcyB1c2UgY2FzZSkuIE9mIGNv
dXJzZSwgYSBjb25jcmV0ZSB2YWx1ZSBkZXBlbmRzIG9uIHRoZSB0eXBlIG9mIGludGVyYWN0aW9u
LiBIb3dldmVyLCB0aGUgYm9yZGVybGluZSBiZXR3ZWVuIGxvdy1sYXRlbmN5IGFuZCBoaWdoLWxh
dGVuY3kgYXBwbGljYXRpb25zIGlzIGluIHRoZSBuZWNlc3NpdHkgb2YgaW50ZXJhY3Rpb24NCiB3
aXRoIHRoZSB2aWRlbyBjb250ZW50IChpdOKAmXMgbm90IGp1c3QgbXkgb3BpbmlvbjombmJzcDsg
PGEgaHJlZj0iaHR0cDovL3d3dy5jYXN0LWluYy5jb20vYmxvZy93aGl0ZS1wYXBlci11bmRlcnN0
YW5kaW5nLWFuZC1yZWR1Y2luZy1sYXRlbmN5LWluLXZpZGVvLWNvbXByZXNzaW9uLXN5c3RlbXMi
Pg0KaHR0cDovL3d3dy5jYXN0LWluYy5jb20vYmxvZy93aGl0ZS1wYXBlci11bmRlcnN0YW5kaW5n
LWFuZC1yZWR1Y2luZy1sYXRlbmN5LWluLXZpZGVvLWNvbXByZXNzaW9uLXN5c3RlbXM8L2E+KS48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDtUaGUg4oCcaW50ZXJhY3Rp
dmXigJ0gYXBwbGljYXRpb25zIG9uIHlvdXIgc2V0dG9wIG9yIGNvbm5lY3RlZCBUViBkbyBub3Qg
ZGVtYW5kIGEgbG93IGxhdGVuY3kgYXMgbXVjaCBhcyBza3lwZS1saWtlIGFwcHMgZG8uIE1vcmUg
dGhhbiBvZnRlbiwgdGhlIGxhZyBvbiBUVnMsIHNldHRvcHMgYXJlIGR1ZSB0byB0aGUgaGFyZHdh
cmUgb3IgdGhlIHNvZnR3YXJlLCBub3QNCiB2aWRlbyBlbmNvZGluZy9kZWNvZGluZyByZWxhdGVk
IGRlbGF5LiBTbyBldmVuIGlmIHlvdSBoYXZlIHRoZSBiZXN0IGNvZGVjLCBpdCB3b27igJl0IG1h
a2UgYSBiaWcgZGlmZmVyZW5jZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JZiBndWVzcyBpZiB5b3UgaGF2ZSB0
aGUgYmVzdCBjb2RlYyBidXQgdGhlIGRlLWppdHRlciBidWZmZXIgc2l6ZSBpcyBiaWcgb3IgSFcv
U1cgZG9lc27igJl0IHdvcmsgd2VsbCwgaXQgd29u4oCZdCBtYWtlIGEgYmlnIGRpZmZlcmVuY2Ug
YXMgd2VsbC4gT2J2aW91c2x5LCBsb3ctZGVsYXkgY29kZWMgZG9lcyBub3QgZ3VhcmFudGVlIGxv
dy1kZWxheSBzb2x1dGlvbi4gV2hhdA0KIHdlIGNvdWxkIChhbmQgcHJvYmFibHkgc2hvdWxkKSBk
byBpcyB0byBzcGVjaWZ5IHZhbHVlcyBvZiBkZWxheSB0aGF0IGNvdWxkIGJlIGludHJvZHVjZWQg
YnkgYSBjb2RlYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDtUcnVl
LiBUaGF0IGlzIHdoYXQgSVBUViBtZWFucy4gVGhlIHRlcm0geW91IGFyZSBsb29raW5nIGZvciBu
ZXR3b3JrcyB3aXRob3V0IFNQIFFvUyBpcyDigJxJUCAob3IgaW50ZXJuZXQpIHZpZGVv4oCdIG5v
dCBJUFRWLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Gcm9tIHRoZSBjb2RlYyBwb2ludCBvZiB2aWV3IHRoZSBv
bmx5IGRpZmZlcmVuY2UgYmV0d2VlbiDigJxJUFRW4oCdIGFuZCDigJxJUCB2aWRlb+KAnShPVFQs
IE9wZW5JUFRWLCBldGMuKSZuYnNwOyBpcyBtYW5hZ2VkIG9yIHVubWFuYWdlZCBuZXR3b3JrIChp
LmUuIGVycm9yIHJvYnVzdG5lc3MpLiBDb3JyZWN0PyBJZiBzbywgd2UgY2FuIGNvbnNpZGVyIHRo
ZXNlIHR3byBhcHBsaWNhdGlvbnMNCiBhcyBhIHNpbmdsZSB1c2UtY2FzZSB3aXRoIGEgcmVxdWly
ZW1lbnQgZm9yIGVycm9yIHJlc2lsaWVuY2UgaWYgdGhlIG5ldHdvcmsgaXMgdW5tYW5hZ2VkLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj
b2xvcjojMUY0OTdEIj5JbiB0aGlzIGNhc2UsIG15IG1haW4gcXVlc3Rpb24gaXMgd2hldGhlciB5
b3UgbWluZCB0byBjb25zaWRlciBPVFQgdmlkZW8gYXMgYSB1c2UgY2FzZSBmb3IgTkVUVkMgY29k
ZWMgb3Igbm90PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s
Pg0K

--_000_A95DB243D3936149BBFA3B43ED7107457052622Fszxema508mbschi_--


From nobody Wed Jul 22 04:35:01 2015
Return-Path: <abegen@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 ED7401ACE8C for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 04:34:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, 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 BY2PxkH0LHEr for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 04:34:58 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 638CD1A0195 for <video-codec@ietf.org>; Wed, 22 Jul 2015 04:34:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8696; q=dns/txt; s=iport; t=1437564898; x=1438774498; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=qHTAm0T7WrE921dw/G+TDCE+VGHi3SCwOU/zYreGaIE=; b=RbRv1CCEpkeLPhcfU4rKSqDOY3HUy0GDr1x/bOAYZ+ZQyK/rLBs8v0aW IOV243U6RPbZbNNRWhElosK+rAyY5vmQYWT7b1NweHyTmCCvRO0BqCWDZ giN/ivZipvp7ARngWYQLTiAnwXDAA9a0P+zp487A24vUGy1/3WQzOGdTM w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A3AwAIf69V/4gNJK1bgkhNVGkGgx24WwmHdgIcgS44FAEBAQEBAQGBCoQjAQEBBCNmAgEIEQMBAigDAgICMBQJCAEBBAESiC62GJY5AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tMhHUYgmgvgRQFlFcBjDGBQ5Nug2Emgg0cgVNvgUeBBAEBAQ
X-IronPort-AV: E=Sophos; i="5.15,523,1432598400"; d="scan'208,217"; a="12005814"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-9.cisco.com with ESMTP; 22 Jul 2015 11:34:57 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t6MBYvxQ029270 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 11:34:57 GMT
Received: from xmb-aln-x01.cisco.com ([169.254.2.64]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 06:34:57 -0500
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: Filippov Alexey <Alexey.Filippov@huawei.com>, "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: [video-codec] draft-filippov-netvc-requirements-01
Thread-Index: AdDEY+SAW0GCvpXJZECxIZTezzBngAAPFTeA///zrgCAACYXgA==
Date: Wed, 22 Jul 2015 11:34:56 +0000
Message-ID: <B155D001-D02B-43DB-8F59-D34A7614B3A3@cisco.com>
References: <A95DB243D3936149BBFA3B43ED71074570525F45@szxema508-mbs.china.huawei.com> <F9407E60-EA4F-4AA9-91A6-0303912D721B@cisco.com> <A95DB243D3936149BBFA3B43ED7107457052622F@szxema508-mbs.china.huawei.com>
In-Reply-To: <A95DB243D3936149BBFA3B43ED7107457052622F@szxema508-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.150701
x-originating-ip: [10.61.214.86]
Content-Type: multipart/alternative; boundary="_000_B155D001D02B43DB8F59D34A7614B3A3ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/wYSmXs9pgPXOLL0wuNV8q9eRsyQ>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Jul 2015 11:35:00 -0000

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

DQoNCkZyb206IEZpbGlwcG92IEFsZXhleQ0KRGF0ZTogV2VkbmVzZGF5LCBKdWx5IDIyLCAyMDE1
IGF0IDE6MTggUE0NClRvOiAiQWxpIEMuIEJlZ2VuIiwgInZpZGVvLWNvZGVjQGlldGYub3JnPG1h
aWx0bzp2aWRlby1jb2RlY0BpZXRmLm9yZz4iDQpTdWJqZWN0OiBSRTogW3ZpZGVvLWNvZGVjXSBk
cmFmdC1maWxpcHBvdi1uZXR2Yy1yZXF1aXJlbWVudHMtMDENCg0KRnJvbSB0aGUgY29kZWMgcG9p
bnQgb2YgdmlldyB0aGUgb25seSBkaWZmZXJlbmNlIGJldHdlZW4g4oCcSVBUVuKAnSBhbmQg4oCc
SVAgdmlkZW/igJ0oT1RULCBPcGVuSVBUViwgZXRjLikgIGlzIG1hbmFnZWQgb3IgdW5tYW5hZ2Vk
IG5ldHdvcmsgKGkuZS4gZXJyb3Igcm9idXN0bmVzcykuIENvcnJlY3Q/DQoNCk5vcGUuIEluIElQ
VFYsIHRoZSBiYW5kd2lkdGggaXMgcHJvdmlzaW9uZWQgc28geW91IGtub3cgeW91ciBwYWNrZXRz
IHdpbGwgbm90IHJlYWxseSBmYWNlIGEgbG9zcyBvciBsYXJnZSBkZWxheSB1bmxlc3Mgc29tZXRo
aW5nIHJlYWxseSBiYWQgaGFwcGVucy4gSW4gSVAgdmlkZW8sIHRoZXJlIGFyZSBubyBzdWNoIGd1
YXJhbnRlZXMsIGFueXRoaW5nIGNhbiBoYXBwZW4gdG8geW91ciBwYWNrZXRzLiBUaHVzLCBJUC9P
VFQgdmlkZW8gdXNlcyBtb3N0bHkgVENQICh3aXRoIEhUVFApLiBTdWNoIGFwcHMgaGF2ZSBlbnRp
cmVseSBkaWZmZXJlbnQgc2V0IG9mIGdvYWxzIHRvIG9wdGltaXplIChvciB0cmFkZSBvZmYpIGNv
bXBhcmVkIHRvIElQVFYgYXBwcy4NCg0KSWYgc28sIHdlIGNhbiBjb25zaWRlciB0aGVzZSB0d28g
YXBwbGljYXRpb25zIGFzIGEgc2luZ2xlIHVzZS1jYXNlIHdpdGggYSByZXF1aXJlbWVudCBmb3Ig
ZXJyb3IgcmVzaWxpZW5jZSBpZiB0aGUgbmV0d29yayBpcyB1bm1hbmFnZWQuDQoNCkluIG15IHZp
ZXcsIG5laXRoZXIgSVBUViBub3IgSVAvT1RUIHZpZGVvIHNob3VsZCBiZSBlcnJvciByZXNpbGll
bnQuIFRoZXkgc2hvdWxkIGJlIGVycm9yIGZyZWUsIHRoYXQgaXMgaXQuIEJ1dCB0byBtZSwgc2t5
cGUsIGNvbmZlcmVuY2luZywgcnRjd2ViIG11c3QgYmUgZXJyb3IgcmVzaWxpZW50LCBlc3BlY2lh
bGx5IHdoZW4gcnVubmluZyBvdmVyIG5vbi1Rb1MgbmV0d29ya3MuDQoNCkluIHRoaXMgY2FzZSwg
bXkgbWFpbiBxdWVzdGlvbiBpcyB3aGV0aGVyIHlvdSBtaW5kIHRvIGNvbnNpZGVyIE9UVCB2aWRl
byBhcyBhIHVzZSBjYXNlIGZvciBORVRWQyBjb2RlYyBvciBub3Q/DQoNCkFzIEkgc2FpZCwgaXQg
c2hvdWxkIG5vdCBiZSB0aGUgZm9jdXMgYXQgdGhlIG1vbWVudCwgbGF0ZXIgYSBkaWZmZXJlbnQg
cHJvZmlsZSBjYW4gYmUgZGV2ZWxvcGVkIGFzIG5lZWRlZC4NCg==

--_000_B155D001D02B43DB8F59D34A7614B3A3ciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <FB9A4A487D6194448139FCAB3CB38F7C@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7Ij4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUi
PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFu
IGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxp
YnJpOyBmb250LXNpemU6MTJwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVS
LUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1C
T1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVS
LVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJ
TkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bh
bj5GaWxpcHBvdiBBbGV4ZXk8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0
ZTogPC9zcGFuPldlZG5lc2RheSwgSnVseSAyMiwgMjAxNSBhdCAxOjE4IFBNPGJyPg0KPHNwYW4g
c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+JnF1b3Q7QWxpIEMuIEJlZ2VuJnF1
b3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86dmlkZW8tY29kZWNAaWV0Zi5vcmciPnZpZGVvLWNv
ZGVjQGlldGYub3JnPC9hPiZxdW90Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk
Ij5TdWJqZWN0OiA8L3NwYW4+UkU6IFt2aWRlby1jb2RlY10gZHJhZnQtZmlsaXBwb3YtbmV0dmMt
cmVxdWlyZW1lbnRzLTAxPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVv
dGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVIt
TEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBm
b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjog
cmdiKDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBm
b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDog
bm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw
eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0
bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0K
PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+RnJvbSB0aGUgY29kZWMgcG9p
bnQgb2YgdmlldyB0aGUgb25seSBkaWZmZXJlbmNlIGJldHdlZW4g4oCcSVBUVuKAnSBhbmQg4oCc
SVAgdmlkZW/igJ0oT1RULCBPcGVuSVBUViwgZXRjLikmbmJzcDsgaXMgbWFuYWdlZCBvciB1bm1h
bmFnZWQgbmV0d29yayAoaS5lLiBlcnJvciByb2J1c3RuZXNzKS4gQ29ycmVjdD88L3NwYW4+PC9w
Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Tm9wZS4g
SW4gSVBUViwgdGhlIGJhbmR3aWR0aCBpcyBwcm92aXNpb25lZCBzbyB5b3Uga25vdyB5b3VyIHBh
Y2tldHMgd2lsbCBub3QgcmVhbGx5IGZhY2UgYSBsb3NzIG9yIGxhcmdlIGRlbGF5IHVubGVzcyBz
b21ldGhpbmcgcmVhbGx5IGJhZCBoYXBwZW5zLiBJbiBJUCB2aWRlbywgdGhlcmUgYXJlIG5vIHN1
Y2ggZ3VhcmFudGVlcywgYW55dGhpbmcgY2FuIGhhcHBlbiB0byB5b3VyIHBhY2tldHMuIFRodXMs
IElQL09UVCB2aWRlbyB1c2VzDQogbW9zdGx5IFRDUCAod2l0aCBIVFRQKS4gU3VjaCBhcHBzIGhh
dmUgZW50aXJlbHkgZGlmZmVyZW50IHNldCBvZiBnb2FscyB0byBvcHRpbWl6ZSAob3IgdHJhZGUg
b2ZmKSBjb21wYXJlZCB0byBJUFRWIGFwcHMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNw
YW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9P
S19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBz
b2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBm
b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u
dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h
bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczog
YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt
OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog
MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxzcGFuIHN0eWxlPSJjb2xv
cjogcmdiKDMxLCA3MywgMTI1KTsiPklmIHNvLCB3ZSBjYW4gY29uc2lkZXIgdGhlc2UgdHdvIGFw
cGxpY2F0aW9ucyBhcyBhIHNpbmdsZSB1c2UtY2FzZSB3aXRoIGEgcmVxdWlyZW1lbnQgZm9yIGVy
cm9yIHJlc2lsaWVuY2UgaWYgdGhlIG5ldHdvcmsgaXMgdW5tYW5hZ2VkLjwvc3Bhbj48L3A+DQo8
L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JbiBteSB2aWV3
LCBuZWl0aGVyIElQVFYgbm9yIElQL09UVCB2aWRlbyBzaG91bGQgYmUgZXJyb3IgcmVzaWxpZW50
LiBUaGV5IHNob3VsZCBiZSBlcnJvciBmcmVlLCB0aGF0IGlzIGl0LiBCdXQgdG8gbWUsIHNreXBl
LCBjb25mZXJlbmNpbmcsIHJ0Y3dlYiBtdXN0IGJlIGVycm9yIHJlc2lsaWVudCwgZXNwZWNpYWxs
eSB3aGVuIHJ1bm5pbmcgb3ZlciBub24tUW9TIG5ldHdvcmtzLjwvZGl2Pg0KPGRpdj48YnI+DQo8
L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0i
TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAj
YjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6
ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMCwg
MCwgMCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2Vp
Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7
IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0
LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3Jk
LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8c3BhbiBz
dHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250
LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdi
KDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250
LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9y
bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg
dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg
d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPHNw
YW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+SW4gdGhpcyBjYXNlLCBteSBtYWlu
IHF1ZXN0aW9uIGlzIHdoZXRoZXIgeW91IG1pbmQgdG8gY29uc2lkZXIgT1RUIHZpZGVvIGFzIGEg
dXNlIGNhc2UgZm9yIE5FVFZDIGNvZGVjIG9yIG5vdD88L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3Rl
Pg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QXMgSSBzYWlkLCBpdCBzaG91bGQg
bm90IGJlIHRoZSBmb2N1cyBhdCB0aGUgbW9tZW50LCBsYXRlciBhIGRpZmZlcmVudCBwcm9maWxl
IGNhbiBiZSBkZXZlbG9wZWQgYXMgbmVlZGVkLjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_B155D001D02B43DB8F59D34A7614B3A3ciscocom_--


From nobody Wed Jul 22 05:39:10 2015
Return-Path: <Alexey.Filippov@huawei.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 CD08C1B32BE for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 05:39:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 T5miTkbAf7rt for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 05:39:06 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23CAC1B32D1 for <video-codec@ietf.org>; Wed, 22 Jul 2015 05:39:04 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZA79440; Wed, 22 Jul 2015 12:39:02 +0000 (GMT)
Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 22 Jul 2015 13:39:01 +0100
Received: from SZXEMA508-MBS.china.huawei.com ([169.254.8.36]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0158.001; Wed, 22 Jul 2015 20:38:59 +0800
From: Filippov Alexey <Alexey.Filippov@huawei.com>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>, "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: [video-codec] draft-filippov-netvc-requirements-01
Thread-Index: AQHQxGWSZM2Xvj5fIU26+3ZNKi5INZ3nVpZw//9/YACAAJdmUA==
Date: Wed, 22 Jul 2015 12:38:58 +0000
Message-ID: <A95DB243D3936149BBFA3B43ED7107457052650B@szxema508-mbs.china.huawei.com>
References: <A95DB243D3936149BBFA3B43ED71074570525F45@szxema508-mbs.china.huawei.com> <F9407E60-EA4F-4AA9-91A6-0303912D721B@cisco.com> <A95DB243D3936149BBFA3B43ED7107457052622F@szxema508-mbs.china.huawei.com> <B155D001-D02B-43DB-8F59-D34A7614B3A3@cisco.com>
In-Reply-To: <B155D001-D02B-43DB-8F59-D34A7614B3A3@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.65.251]
Content-Type: multipart/alternative; boundary="_000_A95DB243D3936149BBFA3B43ED7107457052650Bszxema508mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/MonqdL2gY5RvjoD2GGtuHEGTUVU>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Jul 2015 12:39:09 -0000

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

Pk5vcGUuIEluIElQVFYsIHRoZSBiYW5kd2lkdGggaXMgcHJvdmlzaW9uZWQgc28geW91IGtub3cg
eW91ciBwYWNrZXRzIHdpbGwgbm90IHJlYWxseSBmYWNlIGEgbG9zcyBvciBsYXJnZSBkZWxheSB1
bmxlc3Mgc29tZXRoaW5nIHJlYWxseSBiYWQgaGFwcGVucy4gSW4gSVAgdmlkZW8sIHRoZXJlIGFy
ZSBubyBzdWNoIGd1YXJhbnRlZXMsIGFueXRoaW5nIGNhbiBoYXBwZW4gdG8geW91ciBwYWNrZXRz
LiBUaHVzLCBJUC9PVFQgdmlkZW8gdXNlcyBtb3N0bHkgVENQICh3aXRoIEhUVFApLiBTdWNoIGFw
cHMgaGF2ZSBlbnRpcmVseSBkaWZmZXJlbnQgc2V0IG9mIGdvYWxzIHRvIG9wdGltaXplIChvciB0
cmFkZSBvZmYpIGNvbXBhcmVkIHRvIElQVFYgYXBwcy4NCkNvdWxkIHlvdSBwbGVhc2UgZ2l2ZSBz
ZXZlcmFsIGV4YW1wbGVzIG9mIGhvdyB0aGVzZSBkaWZmZXJlbmNlcyBjb3VsZCBhZmZlY3QgKmNv
ZGVjKiByZXF1aXJlbWVudHM/IFdoYXQgc3BlY2lmaWMgcmVxdWlyZW1lbnRzIGZvciBjb2RlYyBz
aG91bGQgYmUgc3RhdGVkIGZvciBPVFQgdmlkZW8gYXMgY29tcGFyZWQgdG8gSVBUVj8gSSBzZWUg
anVzdCB0d28gZGlmZmVyZW5jZXM6IGluIHJhdGUgY29udHJvbCAoaG93ZXZlciwgZGlmZmVyZW50
IHJhdGUgY29udHJvbCBtZWNoYW5pc21zIGNhbiBiZSBpbXBsZW1lbnRlZCBmb3IgdGhlIHNhbWUg
Y29kZWMpIGFuZCBlcnJvciByZXNpbGllbmNlLiBJTUhPLCB0aGUgZGlmZmVyZW5jZXMgYmV0d2Vl
biB0aGVzZSBhcHBzIGFyZSBtYWlubHkgaW4gc3RyZWFtaW5nIGJ1dCBub3QgaW4gY29kZWMuDQoN
Cg0KPkluIG15IHZpZXcsIG5laXRoZXIgSVBUViBub3IgSVAvT1RUIHZpZGVvIHNob3VsZCBiZSBl
cnJvciByZXNpbGllbnQuIFRoZXkgc2hvdWxkIGJlIGVycm9yIGZyZWUsIHRoYXQgaXMgaXQuIEJ1
dCB0byBtZSwgc2t5cGUsIGNvbmZlcmVuY2luZywgcnRjd2ViIG11c3QgYmUgZXJyb3IgcmVzaWxp
ZW50LCBlc3BlY2lhbGx5IHdoZW4gcnVubmluZyBvdmVyIG5vbi1Rb1MgbmV0d29ya3MuDQpTbywg
dGhlIG1haW4gZGlmZmVyZW5jZSBpcyB0aGF0IHBhY2tldHMgZG9u4oCZdCBmYWNlIGEgbG9zcyBv
ciBsYXJnZSBkZWxheS4gWWVzLCBtb3N0bHkgVENQIGlzIHVzZWQgZm9yIElQL09UVCBidXQgcmVz
ZW5kaW5nIHVuZGVsaXZlcmVkIHBhY2tldHMgaXMgbm90IGFsd2F5cyB0aGUgYmVzdCB3YXkgb2Yg
c29sdmluZyB0aGUgcHJvYmxlbSBvZiBwYWNrZXQgbG9zcyBhbmQsIGVzcGVjaWFsbHksIG9mIGxh
cmdlIGRlbGF5LiBJZiBsb3cgZGVsYXkgaXMgbmVlZGVkLCBvdGhlciBtZWNoYW5pc21zIGNhbiB3
b3JrIGJldHRlci4gVGhlc2UgYWx0ZXJuYXRpdmUgbWVjaGFuaXNtcyBjYW4gYmUgaW1wbGVtZW50
ZWQgb24gdHJhbnNwb3J0IGxldmVsIChlLmcuLCBGRUMpIG9yIG9uIGNvZGVjIGxldmVsIChlLmcu
LCByZWR1bmRhbnQgc2xpY2VzKS4gU28sIEkgdGhpbmsgZXJyb3IgcmVzaWxpZW5jZSB0b29scyBp
bXBsZW1lbnRlZCBvbiBjb2RlYyBsZXZlbCBzaG91bGQgYmUgY29tcGxlbWVudGFyeSB0byB0aGUg
ZXJyb3IgcHJvdGVjdGlvbiBtZWNoYW5pc21zIGltcGxlbWVudGVkIG9uIHRyYW5zcG9ydCBsZXZl
bC4gSXNu4oCZdCBpdD8NCg0KDQo+PkluIHRoaXMgY2FzZSwgbXkgbWFpbiBxdWVzdGlvbiBpcyB3
aGV0aGVyIHlvdSBtaW5kIHRvIGNvbnNpZGVyIE9UVCB2aWRlbyBhcyBhIHVzZSBjYXNlIGZvciBO
RVRWQyBjb2RlYyBvciBub3Q/DQo+QXMgSSBzYWlkLCBpdCBzaG91bGQgbm90IGJlIHRoZSBmb2N1
cyBhdCB0aGUgbW9tZW50LCBsYXRlciBhIGRpZmZlcmVudCBwcm9maWxlIGNhbiBiZSBkZXZlbG9w
ZWQgYXMgbmVlZGVkLg0KVGhlbiwgaXQgd291bGQgYmUgaGFyZCB0byBleHBsYWluIHdoeSBPcHVz
IGlzIHVzZWQgYnkgWW91VHViZSwgYW5kIE5FVFZDIGNvZGVjIGlzIGN1cnJlbnRseSBub3QgZXZl
biB0YXJnZXRlZCBhdCBpdC4NCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2
IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw
YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K
cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246
dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFy
IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4w
cHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHls
ZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hh
cg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToi
VGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6
ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7
c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp
di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm
IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9
IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv
OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx
IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg
bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y
ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6Ymxh
Y2siPk5vcGUuIEluIElQVFYsIHRoZSBiYW5kd2lkdGggaXMgcHJvdmlzaW9uZWQgc28geW91IGtu
b3cgeW91ciBwYWNrZXRzIHdpbGwgbm90IHJlYWxseSBmYWNlIGEgbG9zcyBvcg0KIGxhcmdlIGRl
bGF5IHVubGVzcyBzb21ldGhpbmcgcmVhbGx5IGJhZCBoYXBwZW5zLiBJbiBJUCB2aWRlbywgdGhl
cmUgYXJlIG5vIHN1Y2ggZ3VhcmFudGVlcywgYW55dGhpbmcgY2FuIGhhcHBlbiB0byB5b3VyIHBh
Y2tldHMuIFRodXMsIElQL09UVCB2aWRlbyB1c2VzIG1vc3RseSBUQ1AgKHdpdGggSFRUUCkuIFN1
Y2ggYXBwcyBoYXZlIGVudGlyZWx5IGRpZmZlcmVudCBzZXQgb2YgZ29hbHMgdG8gb3B0aW1pemUg
KG9yIHRyYWRlIG9mZikgY29tcGFyZWQNCiB0byBJUFRWIGFwcHMuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPkNvdWxkIHlvdSBwbGVhc2UgZ2l2ZSBzZXZlcmFsIGV4YW1wbGVzIG9mIGhv
dyB0aGVzZSBkaWZmZXJlbmNlcyBjb3VsZCBhZmZlY3QgKjxiPmNvZGVjPC9iPiogcmVxdWlyZW1l
bnRzPyBXaGF0IHNwZWNpZmljIHJlcXVpcmVtZW50cyBmb3IgY29kZWMgc2hvdWxkIGJlIHN0YXRl
ZA0KIGZvciBPVFQgdmlkZW8gYXMgY29tcGFyZWQgdG8gSVBUVj8gSSBzZWUganVzdCB0d28gZGlm
ZmVyZW5jZXM6IGluIHJhdGUgY29udHJvbCAoaG93ZXZlciwgZGlmZmVyZW50IHJhdGUgY29udHJv
bCBtZWNoYW5pc21zIGNhbiBiZSBpbXBsZW1lbnRlZCBmb3IgdGhlIHNhbWUgY29kZWMpIGFuZCBl
cnJvciByZXNpbGllbmNlLiBJTUhPLCB0aGUgZGlmZmVyZW5jZXMgYmV0d2VlbiB0aGVzZSBhcHBz
IGFyZSBtYWlubHkgaW4gc3RyZWFtaW5nIGJ1dCBub3QNCiBpbiBjb2RlYy48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSIgc3R5bGU9ImZv
bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJV
IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFj
ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFG
NDk3RCI+Jmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls
eTpDb25zb2xhcztjb2xvcjpibGFjayI+SW4gbXkgdmlldywgbmVpdGhlciBJUFRWIG5vciBJUC9P
VFQgdmlkZW8gc2hvdWxkIGJlIGVycm9yIHJlc2lsaWVudC4gVGhleSBzaG91bGQgYmUgZXJyb3Ig
ZnJlZSwgdGhhdA0KIGlzIGl0LiBCdXQgdG8gbWUsIHNreXBlLCBjb25mZXJlbmNpbmcsIHJ0Y3dl
YiBtdXN0IGJlIGVycm9yIHJlc2lsaWVudCwgZXNwZWNpYWxseSB3aGVuIHJ1bm5pbmcgb3ZlciBu
b24tUW9TIG5ldHdvcmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbywgdGhlIG1h
aW4gZGlmZmVyZW5jZSBpcyB0aGF0IHBhY2tldHMgZG9u4oCZdCBmYWNlIGEgbG9zcyBvciBsYXJn
ZSBkZWxheS4gWWVzLCBtb3N0bHkgVENQIGlzIHVzZWQgZm9yIElQL09UVCBidXQgcmVzZW5kaW5n
IHVuZGVsaXZlcmVkIHBhY2tldHMgaXMgbm90IGFsd2F5cw0KIHRoZSBiZXN0IHdheSBvZiBzb2x2
aW5nIHRoZSBwcm9ibGVtIG9mIHBhY2tldCBsb3NzIGFuZCwgZXNwZWNpYWxseSwgb2YgbGFyZ2Ug
ZGVsYXkuIElmIGxvdyBkZWxheSBpcyBuZWVkZWQsIG90aGVyIG1lY2hhbmlzbXMgY2FuIHdvcmsg
YmV0dGVyLiBUaGVzZSBhbHRlcm5hdGl2ZSBtZWNoYW5pc21zIGNhbiBiZSBpbXBsZW1lbnRlZCBv
biB0cmFuc3BvcnQgbGV2ZWwgKGUuZy4sIEZFQykgb3Igb24gY29kZWMgbGV2ZWwgKGUuZy4sIHJl
ZHVuZGFudA0KIHNsaWNlcykuIFNvLCBJIHRoaW5rIGVycm9yIHJlc2lsaWVuY2UgdG9vbHMgaW1w
bGVtZW50ZWQgb24gY29kZWMgbGV2ZWwgc2hvdWxkIGJlIGNvbXBsZW1lbnRhcnkgdG8gdGhlIGVy
cm9yIHByb3RlY3Rpb24gbWVjaGFuaXNtcyBpbXBsZW1lbnRlZCBvbiB0cmFuc3BvcnQgbGV2ZWwu
IElzbuKAmXQgaXQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iUlUiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJSVSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJvcnBoYW5zOiBhdXRv
O3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6
IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj4mZ3Q7Jmd0O0luIHRoaXMgY2FzZSwgbXkgbWFpbiBxdWVzdGlvbiBpcyB3aGV0
aGVyIHlvdSBtaW5kIHRvIGNvbnNpZGVyIE9UVCB2aWRlbyBhcyBhIHVzZSBjYXNlIGZvciBORVRW
QyBjb2RlYyBvciBub3Q/PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi
bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3
RCI+Jmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpD
b25zb2xhcztjb2xvcjpibGFjayI+QXMgSSBzYWlkLCBpdCBzaG91bGQgbm90IGJlIHRoZSBmb2N1
cyBhdCB0aGUgbW9tZW50LCBsYXRlciBhIGRpZmZlcmVudCBwcm9maWxlIGNhbiBiZSBkZXZlbG9w
ZWQgYXMNCiBuZWVkZWQuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt
ZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj5UaGVuLCBpdCB3b3VsZCBiZSBoYXJkIHRvIGV4cGxhaW4gd2h5IE9wdXMgaXMgdXNlZCBi
eSBZb3VUdWJlLCBhbmQgTkVUVkMgY29kZWMgaXMgY3VycmVudGx5IG5vdCBldmVuIHRhcmdldGVk
IGF0IGl0LiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwv
aHRtbD4NCg==

--_000_A95DB243D3936149BBFA3B43ED7107457052650Bszxema508mbschi_--


From nobody Wed Jul 22 05:45: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 3BC811A1B7C for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 05:45:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 1ZuyCkMC_vgF for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 05:45:03 -0700 (PDT)
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 243851B32FA for <video-codec@ietf.org>; Wed, 22 Jul 2015 05:44:40 -0700 (PDT)
Received: by iecri3 with SMTP id ri3so71380711iec.2 for <video-codec@ietf.org>; Wed, 22 Jul 2015 05:44:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=pKxII8izHTetKX3oUQEME0j0OrCuqvp2kTy6JALwas4=; b=geknuQYvipC8o1ja3JF7W7O/GsmNu9/qVAoWSm07HizTjCBS5vgRYtYGElBBsKdY2m PNHdK7wPYmvHMUY40zzojKWvyAtzZaDQ5S1DHJ2w3UqZlZdoymo712bQ0Yvwbej9jVLs A4bZwI++psUdaeh6t3ArSuwwHtvFyTMWxHPZIQhSlXmYrbck4blC+r+8/52uBy/vIbON ePjSWeopLVw98U/jPsLVhp6vbZFBgi/byUKEu79DhEICK+f52oSOiZWkmU2sItkiABeN 1qw6TCxCxO77edfj7C3DgCE+fQsfKcrZvNIlOPIQDqtEtbuFf0/CHlAA7Zh4Vn6vo8zr FcNQ==
MIME-Version: 1.0
X-Received: by 10.50.171.228 with SMTP id ax4mr34072977igc.32.1437569079526; Wed, 22 Jul 2015 05:44:39 -0700 (PDT)
Sender: metajack@gmail.com
Received: by 10.79.119.22 with HTTP; Wed, 22 Jul 2015 05:44:39 -0700 (PDT)
In-Reply-To: <A95DB243D3936149BBFA3B43ED7107457052650B@szxema508-mbs.china.huawei.com>
References: <A95DB243D3936149BBFA3B43ED71074570525F45@szxema508-mbs.china.huawei.com> <F9407E60-EA4F-4AA9-91A6-0303912D721B@cisco.com> <A95DB243D3936149BBFA3B43ED7107457052622F@szxema508-mbs.china.huawei.com> <B155D001-D02B-43DB-8F59-D34A7614B3A3@cisco.com> <A95DB243D3936149BBFA3B43ED7107457052650B@szxema508-mbs.china.huawei.com>
Date: Wed, 22 Jul 2015 06:44:39 -0600
X-Google-Sender-Auth: PSzCI2wa3o1VXULaZoudzWkCkuU
Message-ID: <CAP7VpsVwBmc1NZnHq6McAiQqhP6aKEOhUvz6ityB-8abRtqtoA@mail.gmail.com>
From: Jack Moffitt <jack@metajack.im>
To: Filippov Alexey <Alexey.Filippov@huawei.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/7428yGvC_Pv0XyxDzLLbDQROF_I>
Cc: "video-codec@ietf.org" <video-codec@ietf.org>, "Ali C. Begen \(abegen\)" <abegen@cisco.com>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Jul 2015 12:45:04 -0000

> Then, it would be hard to explain why Opus is used by YouTube, and NETVC
> codec is currently not even targeted at it.

If you are basing this assessment on the requirements draft, then note
that the requirements draft is a work in progress and is not complete.
Streaming use cases should be added there, and I'm quite surprised I
managed to leave it out of the first draft.

jack.


From nobody Wed Jul 22 06:01:40 2015
Return-Path: <Alexey.Filippov@huawei.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 17E471B3332 for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 06:01:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 e8dNY9260D2C for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 06:01:38 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 862E61B3331 for <video-codec@ietf.org>; Wed, 22 Jul 2015 06:01:37 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVL63423; Wed, 22 Jul 2015 13:01:36 +0000 (GMT)
Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 22 Jul 2015 14:01:35 +0100
Received: from SZXEMA508-MBS.china.huawei.com ([169.254.8.36]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Wed, 22 Jul 2015 21:01:32 +0800
From: Filippov Alexey <Alexey.Filippov@huawei.com>
To: Jack Moffitt <jack@metajack.im>
Thread-Topic: [video-codec] draft-filippov-netvc-requirements-01
Thread-Index: AQHQxGWSZM2Xvj5fIU26+3ZNKi5INZ3nVpZw//9/YACAAJdmUP//fBSAgACHbwA=
Date: Wed, 22 Jul 2015 13:01:32 +0000
Message-ID: <A95DB243D3936149BBFA3B43ED71074570526575@szxema508-mbs.china.huawei.com>
References: <A95DB243D3936149BBFA3B43ED71074570525F45@szxema508-mbs.china.huawei.com> <F9407E60-EA4F-4AA9-91A6-0303912D721B@cisco.com> <A95DB243D3936149BBFA3B43ED7107457052622F@szxema508-mbs.china.huawei.com> <B155D001-D02B-43DB-8F59-D34A7614B3A3@cisco.com> <A95DB243D3936149BBFA3B43ED7107457052650B@szxema508-mbs.china.huawei.com> <CAP7VpsVwBmc1NZnHq6McAiQqhP6aKEOhUvz6ityB-8abRtqtoA@mail.gmail.com>
In-Reply-To: <CAP7VpsVwBmc1NZnHq6McAiQqhP6aKEOhUvz6ityB-8abRtqtoA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.65.251]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/nZBf9IVTB8JHXtYRojfGKUsodeg>
Cc: "video-codec@ietf.org" <video-codec@ietf.org>, "Ali C. Begen \(abegen\)" <abegen@cisco.com>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Jul 2015 13:01:39 -0000

PklmIHlvdSBhcmUgYmFzaW5nIHRoaXMgYXNzZXNzbWVudCBvbiB0aGUgcmVxdWlyZW1lbnRzIGRy
YWZ0LCB0aGVuIG5vdGUgdGhhdCB0aGUgcmVxdWlyZW1lbnRzIGRyYWZ0IGlzIGEgd29yayBpbiBw
cm9ncmVzcyBhbmQgaXMgbm90IGNvbXBsZXRlLg0KPlN0cmVhbWluZyB1c2UgY2FzZXMgc2hvdWxk
IGJlIGFkZGVkIHRoZXJlLCBhbmQgSSdtIHF1aXRlIHN1cnByaXNlZCBJIG1hbmFnZWQgdG8gbGVh
dmUgaXQgb3V0IG9mIHRoZSBmaXJzdCBkcmFmdC4NCkFncmVlZA0KDQotLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KRnJvbTogbWV0YWphY2tAZ21haWwuY29tIFttYWlsdG86bWV0YWphY2tAZ21h
aWwuY29tXSBPbiBCZWhhbGYgT2YgSmFjayBNb2ZmaXR0DQpTZW50OiBXZWRuZXNkYXksIEp1bHkg
MjIsIDIwMTUgMzo0NSBQTQ0KVG86IEZpbGlwcG92IEFsZXhleQ0KQ2M6IEFsaSBDLiBCZWdlbiAo
YWJlZ2VuKTsgdmlkZW8tY29kZWNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdmlkZW8tY29kZWNd
IGRyYWZ0LWZpbGlwcG92LW5ldHZjLXJlcXVpcmVtZW50cy0wMQ0KDQo+IFRoZW4sIGl0IHdvdWxk
IGJlIGhhcmQgdG8gZXhwbGFpbiB3aHkgT3B1cyBpcyB1c2VkIGJ5IFlvdVR1YmUsIGFuZCANCj4g
TkVUVkMgY29kZWMgaXMgY3VycmVudGx5IG5vdCBldmVuIHRhcmdldGVkIGF0IGl0Lg0KDQpJZiB5
b3UgYXJlIGJhc2luZyB0aGlzIGFzc2Vzc21lbnQgb24gdGhlIHJlcXVpcmVtZW50cyBkcmFmdCwg
dGhlbiBub3RlIHRoYXQgdGhlIHJlcXVpcmVtZW50cyBkcmFmdCBpcyBhIHdvcmsgaW4gcHJvZ3Jl
c3MgYW5kIGlzIG5vdCBjb21wbGV0ZS4NClN0cmVhbWluZyB1c2UgY2FzZXMgc2hvdWxkIGJlIGFk
ZGVkIHRoZXJlLCBhbmQgSSdtIHF1aXRlIHN1cnByaXNlZCBJIG1hbmFnZWQgdG8gbGVhdmUgaXQg
b3V0IG9mIHRoZSBmaXJzdCBkcmFmdC4NCg0KamFjay4NCg==


From nobody Wed Jul 22 06:10:14 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 1E2971A03C7 for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 06:10:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, 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 elKv05MsOsJn for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 06:10:11 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8416B1B3365 for <video-codec@ietf.org>; Wed, 22 Jul 2015 06:09:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8258; q=dns/txt; s=iport; t=1437570587; x=1438780187; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1NtWy8SS1Qj404aflviDJp3U8X4Q1NkLebGXFh6Ss9g=; b=OuGKKHbZnSLBRjSeBi40pvojRvGc6R+feWhXREN6A6i7POsCetZuTf1e uZsJJTYp8hzb36CqLaZPjJxwID3Zvp3lqmQKMNXnG/j3sCaT3kJR2DSPO IBZEnn5Fb41s0+KdUanXmEdkupMyT2g7JF+4IJA6R7YN27/tA8HEf3RQR U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AEBQAila9V/49dJa1bDoI6TVRpBr1rAQmGAQKBTTwQAQEBAQEBAYEKhCQBAQQBAQFrCxACAQg/BycLFBECBAENBYguDcxwAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSKSoEChC1VBAeEKwWUVwGMMZkSJoM+Pm+BBEOBBAEBAQ
X-IronPort-AV: E=Sophos; i="5.15,523,1432598400"; d="scan'208,217"; a="17673803"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP; 22 Jul 2015 13:09:46 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t6MD9kNT023253 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 13:09:46 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.112]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 08:09:46 -0500
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: "keithw@mit.edu" <keithw@mit.edu>, Thomas Daede <tdaede@mozilla.com>
Thread-Topic: [video-codec] Low-latency rate control constraints
Thread-Index: AQHQxH+t8mQPx+IbxkCPtAwd8vEu9Q==
Date: Wed, 22 Jul 2015 13:09:45 +0000
Message-ID: <D1D503BF.5222C%mzanaty@cisco.com>
References: <55AE28F6.6070100@mozilla.com> <CAMzhQmN17crzSPQSzy3jzz+8gfu8tZr8mFyCOSmvSX1pheppAg@mail.gmail.com>
In-Reply-To: <CAMzhQmN17crzSPQSzy3jzz+8gfu8tZr8mFyCOSmvSX1pheppAg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.3.150624
x-originating-ip: [64.100.32.216]
Content-Type: multipart/alternative; boundary="_000_D1D503BF5222Cmzanatyciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/qEe07dC_SWMG8-M-aliCxjy4xf8>
Cc: "video-codec@ietf.org" <video-codec@ietf.org>
Subject: Re: [video-codec] Low-latency rate control constraints
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Jul 2015 13:10:13 -0000

--_000_D1D503BF5222Cmzanatyciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I agree encoder latency should be specified directly in low latency testing=
. IMO, this has nothing to do with bitrates or rate control strategies. It =
is simply constraining the encoder to zero structural delay when encoding e=
ach frame. That is, frame in, frame out, no reordering or lookahead.

Rate control constraints may be necessary in some testing to reflect transp=
ort channel constraints. But this should not be conflated with low latency =
as in zero structural delay.

Mo (as individual)

On 7/22/15, 4:40 AM, video-codec on behalf of Keith Winstein <video-codec-b=
ounces@ietf.org<mailto:video-codec-bounces@ietf.org> on behalf of keithw@mi=
t.edu<mailto:keithw@mit.edu>> wrote:

Hello Thomas,

It seems like constraining the bitrate variation by enforcing a limited rec=
eiver-side VBV buffer is kind of an indirect way to get at what you really =
care about. Most receivers can probably buffer at least >5 megabytes (so >5=
 seconds of video) with no problem. If the document wants to specify a mode=
l for low-latency video, I think the constraint might be better expressed i=
n terms of latency directly.

Here would be my proposal for an idealized model for what video conferencin=
g would require from the video coder:

(a) The source video arrives at 30 fps, and each frame is given an "encode =
time" of n/30 seconds.
(b) After being encoded, the coded frames are appended to a sender-side FIF=
O.
(c) The sender-side FIFO is drained (and delivered to the receiver) at a pa=
rticular link rate given in bits per second.
(d) At the receiver, each frame is given a "display time" of the earliest m=
oment it can be shown to the user given when its coded representation finis=
hes being delivered, and any rules of the format about frame reordering (i.=
e. the presentation timestamp of MPEG). The receiver doesn't attempt isochr=
onous presentation of the frames; it just shows each frame at the earliest =
possible moment.

For the first 8 seconds, the link rate "(c)" is 4 megabits/sec, and the cod=
er is informed of this. At t=3D8 seconds, the link rate "(c)" instantaneous=
ly changes to 500 kilobits/sec. The coder learns of this change at t=3D8.25=
 seconds.

The figure of merit is a combination of (1) visual fidelity (e.g. PSNR, SSI=
M, etc.) of the coded frames relative to the source frames, and (2) the max=
imum difference between the "encode time" and "display time" of any frame, =
taken over all the frames in the video.

Best regards,
Keith

On Tue, Jul 21, 2015 at 4:11 AM, Thomas Daede <tdaede@mozilla.com<mailto:td=
aede@mozilla.com>> wrote:
At the Monday NETVC session, it was suggested that CBR mode with a fixed
buffer size was not a very good representation of what rate control for
video conferencing would do.

Are there suggestions of a better model? Keep in mind that this is only
for relatively short (~15s) clips.

Another option is just to not specify CBR bounds, so that this test
would be like the high latency test but with lookahead and 2 pass
constraints.

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


--_000_D1D503BF5222Cmzanatyciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <F733E2086658624C9764FC9BC199371B@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; color: rgb(0, 0, 0); font-size: 12px; font-fami=
ly: Arial, sans-serif;">
<div>I agree encoder latency should be specified directly in low latency te=
sting. IMO, this has nothing to do with bitrates or rate control strategies=
. It is simply constraining the encoder to zero structural delay when encod=
ing each frame. That is, frame in,
 frame out, no reordering or lookahead.</div>
<div><br>
</div>
<div>Rate control constraints may be necessary in some testing to reflect t=
ransport channel constraints. But this should not be conflated with low lat=
ency as in zero structural delay.</div>
<div><br>
</div>
<div>Mo (as individual)</div>
<div><br>
</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div>
<div>On 7/22/15, 4:40 AM, video-codec on behalf of Keith Winstein &lt;<a hr=
ef=3D"mailto:video-codec-bounces@ietf.org">video-codec-bounces@ietf.org</a>=
 on behalf of
<a href=3D"mailto:keithw@mit.edu">keithw@mit.edu</a>&gt; wrote:</div>
</div>
<div><br>
</div>
<div>
<div>
<div dir=3D"ltr">
<div>
<div>Hello Thomas,</div>
<div><br>
</div>
<div>It seems like constraining the bitrate variation by enforcing a limite=
d receiver-side VBV buffer is kind of an indirect way to get at what you re=
ally care about. Most receivers can probably buffer at least &gt;5 megabyte=
s (so &gt;5 seconds of video) with no
 problem. If the document wants to specify a model for low-latency video, I=
 think the constraint might be better expressed in terms of latency directl=
y.</div>
<div><br>
</div>
<div>Here would be my proposal for an idealized model for what video confer=
encing would require from the video coder:</div>
</div>
<div><br>
</div>
<div>(a) The source video arrives at 30 fps, and each frame is given an &qu=
ot;encode time&quot; of n/30 seconds.</div>
<div>(b) After being encoded, the coded frames are appended to a sender-sid=
e FIFO.</div>
<div>(c) The sender-side FIFO is drained (and delivered to the receiver) at=
 a particular link rate given in bits per second.</div>
<div>(d) At the receiver, each frame is given a &quot;display time&quot; of=
 the earliest moment it can be shown to the user given when its coded repre=
sentation finishes being delivered, and any rules of the format about frame=
 reordering (i.e. the presentation timestamp
 of MPEG). The receiver doesn't attempt isochronous presentation of the fra=
mes; it just shows each frame at the earliest possible moment.</div>
<div><br>
</div>
<div>For the first 8 seconds, the link rate &quot;(c)&quot; is 4 megabits/s=
ec, and the coder is informed of this. At t=3D8 seconds, the link rate &quo=
t;(c)&quot; instantaneously changes to 500 kilobits/sec. The coder learns o=
f this change at t=3D8.25 seconds.</div>
<div><br>
</div>
<div>The figure of merit is a combination of (1) visual fidelity (e.g. PSNR=
, SSIM, etc.) of the coded frames relative to the source frames, and (2) th=
e maximum difference between the &quot;encode time&quot; and &quot;display =
time&quot; of any frame, taken over all the frames in
 the video.</div>
<div><br>
</div>
<div>Best regards,</div>
<div>Keith</div>
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On Tue, Jul 21, 2015 at 4:11 AM, Thomas Daede <s=
pan 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:1p=
x #ccc solid;padding-left:1ex">
At the Monday NETVC session, it was suggested that CBR mode with a fixed<br=
>
buffer size was not a very good representation of what rate control for<br>
video conferencing would do.<br>
<br>
Are there suggestions of a better model? Keep in mind that this is only<br>
for relatively short (~15s) clips.<br>
<br>
Another option is just to not specify CBR bounds, so that this test<br>
would be like the high latency test but with lookahead and 2 pass<br>
constraints.<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" rel=3D"norefe=
rrer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/video-codec</=
a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</span>
</body>
</html>

--_000_D1D503BF5222Cmzanatyciscocom_--


From nobody Wed Jul 22 09:43:45 2015
Return-Path: <arilfuld@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 003A81B2AFD for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 09:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, 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 pcQ2K9gxAJRF for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 09:43:41 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 709BE1A9069 for <video-codec@ietf.org>; Wed, 22 Jul 2015 09:43:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18199; q=dns/txt; s=iport; t=1437583421; x=1438793021; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=L9Ks22fBm85jxDZpDepEDKsgdqsVQk/Mm59lhKLzzis=; b=SjEJcCrI/RBqNmLucdgLEJHTk+5txINHHjWfLRlIFSGEh6Yd9PGnbBtI ZQG82FgoBgtsG4fZQy2cPEo/8XKrsuc8vPngZhkDvYhcK75/Nv7ZohIJk fi5ma6fLfVb22Ezpy3mN9xg+u181j2a7dNS1t5TNbjvrrWxBWXtN7n9RZ c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AGBQD9xq9V/4ENJK1bDoI6TVRpBr1rAQmCQ4M+AoFNPBABAQEBAQEBgQqEIwEBAQQBAQEqQQsQAgEIEQQBAQsdBycLFAkIAgQBDQUIiCYNzWEBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIpKgQKELSgtBAYBgxeBFAWUVwGlQyaDPj5vgQRDgQQBAQE
X-IronPort-AV: E=Sophos;i="5.15,523,1432598400";  d="scan'208,217";a="171191388"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP; 22 Jul 2015 16:43:40 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t6MGhe4s032111 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 16:43:40 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.83]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 11:43:40 -0500
From: "Arild Fuldseth (arilfuld)" <arilfuld@cisco.com>
To: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>, "keithw@mit.edu" <keithw@mit.edu>, Thomas Daede <tdaede@mozilla.com>
Thread-Topic: [video-codec] Low-latency rate control constraints
Thread-Index: AQHQw6YPAZhjhHAQnkyrMPX28EjCcp3ngKCAgABLQYD//+ZAsA==
Date: Wed, 22 Jul 2015 16:43:39 +0000
Message-ID: <D93780CEB41CE1419C1A7542E3096BC210FF1973@xmb-aln-x08.cisco.com>
References: <55AE28F6.6070100@mozilla.com> <CAMzhQmN17crzSPQSzy3jzz+8gfu8tZr8mFyCOSmvSX1pheppAg@mail.gmail.com> <D1D503BF.5222C%mzanaty@cisco.com>
In-Reply-To: <D1D503BF.5222C%mzanaty@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.207.192]
Content-Type: multipart/alternative; boundary="_000_D93780CEB41CE1419C1A7542E3096BC210FF1973xmbalnx08ciscoc_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/Wv1lipCkws-kPIanauUvfNII5_A>
Cc: "video-codec@ietf.org" <video-codec@ietf.org>
Subject: Re: [video-codec] Low-latency rate control constraints
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Jul 2015 16:43:44 -0000

--_000_D93780CEB41CE1419C1A7542E3096BC210FF1973xmbalnx08ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

All,

My concern is that mandating CBR and/or allowing for 2-pass encoding with i=
nput-dependent GOP/QP structures would encourage people to spend a lot of e=
ffort on non-normative encoding techniques. Also, it would be more difficul=
t to determine whether or not any differences is due to normative- or non-n=
ormative techniques.

I would recommend that netvc candidate encoders should at least support the=
 same fixed (input-independent) GOP structure as JCT-VC test conditions, an=
d that this should be the primary mode of testing both for low-delay  and h=
igh-delay.

This has the additional advantage is that it would be possible to do an app=
le-to-apple comparison with HM reference software.

Regards,

Arild

From: video-codec [mailto:video-codec-bounces@ietf.org] On Behalf Of Mo Zan=
aty (mzanaty)
Sent: 22. juli 2015 15:10
To: keithw@mit.edu; Thomas Daede
Cc: video-codec@ietf.org
Subject: Re: [video-codec] Low-latency rate control constraints

I agree encoder latency should be specified directly in low latency testing=
. IMO, this has nothing to do with bitrates or rate control strategies. It =
is simply constraining the encoder to zero structural delay when encoding e=
ach frame. That is, frame in, frame out, no reordering or lookahead.

Rate control constraints may be necessary in some testing to reflect transp=
ort channel constraints. But this should not be conflated with low latency =
as in zero structural delay.

Mo (as individual)

On 7/22/15, 4:40 AM, video-codec on behalf of Keith Winstein <video-codec-b=
ounces@ietf.org<mailto:video-codec-bounces@ietf.org> on behalf of keithw@mi=
t.edu<mailto:keithw@mit.edu>> wrote:

Hello Thomas,

It seems like constraining the bitrate variation by enforcing a limited rec=
eiver-side VBV buffer is kind of an indirect way to get at what you really =
care about. Most receivers can probably buffer at least >5 megabytes (so >5=
 seconds of video) with no problem. If the document wants to specify a mode=
l for low-latency video, I think the constraint might be better expressed i=
n terms of latency directly.

Here would be my proposal for an idealized model for what video conferencin=
g would require from the video coder:

(a) The source video arrives at 30 fps, and each frame is given an "encode =
time" of n/30 seconds.
(b) After being encoded, the coded frames are appended to a sender-side FIF=
O.
(c) The sender-side FIFO is drained (and delivered to the receiver) at a pa=
rticular link rate given in bits per second.
(d) At the receiver, each frame is given a "display time" of the earliest m=
oment it can be shown to the user given when its coded representation finis=
hes being delivered, and any rules of the format about frame reordering (i.=
e. the presentation timestamp of MPEG). The receiver doesn't attempt isochr=
onous presentation of the frames; it just shows each frame at the earliest =
possible moment.

For the first 8 seconds, the link rate "(c)" is 4 megabits/sec, and the cod=
er is informed of this. At t=3D8 seconds, the link rate "(c)" instantaneous=
ly changes to 500 kilobits/sec. The coder learns of this change at t=3D8.25=
 seconds.

The figure of merit is a combination of (1) visual fidelity (e.g. PSNR, SSI=
M, etc.) of the coded frames relative to the source frames, and (2) the max=
imum difference between the "encode time" and "display time" of any frame, =
taken over all the frames in the video.

Best regards,
Keith

On Tue, Jul 21, 2015 at 4:11 AM, Thomas Daede <tdaede@mozilla.com<mailto:td=
aede@mozilla.com>> wrote:
At the Monday NETVC session, it was suggested that CBR mode with a fixed
buffer size was not a very good representation of what rate control for
video conferencing would do.

Are there suggestions of a better model? Keep in mind that this is only
for relatively short (~15s) clips.

Another option is just to not specify CBR bounds, so that this test
would be like the high latency test but with lookahead and 2 pass
constraints.

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


--_000_D93780CEB41CE1419C1A7542E3096BC210FF1973xmbalnx08ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<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;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
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]-->
</head>
<body lang=3D"NO-BOK" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">All,<o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">My concern=
 is that mandating CBR and/or allowing for 2-pass encoding with input-depen=
dent GOP/QP structures would encourage people to spend a lot
 of effort on non-normative encoding techniques. Also, it would be more dif=
ficult to determine whether or not any differences is due to normative- or =
non-normative techniques.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">I would re=
commend that netvc candidate encoders should at least support the same fixe=
d (input-independent) GOP structure as JCT-VC test conditions,
 and that this should be the primary mode of testing both for low-delay&nbs=
p; and high-delay.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">This has t=
he additional advantage is that it would be possible to do an apple-to-appl=
e comparison with HM reference software.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Regards,<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Arild<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;fo=
nt-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span =
lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&qu=
ot;sans-serif&quot;"> video-codec [mailto:video-codec-bounces@ietf.org]
<b>On Behalf Of </b>Mo Zanaty (mzanaty)<br>
<b>Sent:</b> 22. juli 2015 15:10<br>
<b>To:</b> keithw@mit.edu; Thomas Daede<br>
<b>Cc:</b> video-codec@ietf.org<br>
<b>Subject:</b> Re: [video-codec] Low-latency rate control constraints<o:p>=
</o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">I agree encoder latency should=
 be specified directly in low latency testing. IMO, this has nothing to do =
with bitrates or rate control strategies. It is simply constraining
 the encoder to zero structural delay when encoding each frame. That is, fr=
ame in, frame out, no reordering or lookahead.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">Rate control constraints may b=
e necessary in some testing to reflect transport channel constraints. But t=
his should not be conflated with low latency as in zero
 structural delay.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">Mo (as individual)<o:p></o:p><=
/span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">On 7/22/15, 4:40 AM, video-cod=
ec on behalf of Keith Winstein &lt;<a href=3D"mailto:video-codec-bounces@ie=
tf.org">video-codec-bounces@ietf.org</a> on behalf of
<a href=3D"mailto:keithw@mit.edu">keithw@mit.edu</a>&gt; wrote:<o:p></o:p><=
/span></p>
</div>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<div>
<div>
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">Hello Thomas,<o:p></o:p></span=
></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">It seems like constraining the=
 bitrate variation by enforcing a limited receiver-side VBV buffer is kind =
of an indirect way to get at what you really care about.
 Most receivers can probably buffer at least &gt;5 megabytes (so &gt;5 seco=
nds of video) with no problem. If the document wants to specify a model for=
 low-latency video, I think the constraint might be better expressed in ter=
ms of latency directly.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">Here would be my proposal for =
an idealized model for what video conferencing would require from the video=
 coder:<o:p></o:p></span></p>
</div>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">(a) The source video arrives a=
t 30 fps, and each frame is given an &quot;encode time&quot; of n/30 second=
s.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">(b) After being encoded, the c=
oded frames are appended to a sender-side FIFO.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">(c) The sender-side FIFO is dr=
ained (and delivered to the receiver) at a particular link rate given in bi=
ts per second.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">(d) At the receiver, each fram=
e is given a &quot;display time&quot; of the earliest moment it can be show=
n to the user given when its coded representation finishes being delivered,
 and any rules of the format about frame reordering (i.e. the presentation =
timestamp of MPEG). The receiver doesn't attempt isochronous presentation o=
f the frames; it just shows each frame at the earliest possible moment.<o:p=
></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">For the first 8 seconds, the l=
ink rate &quot;(c)&quot; is 4 megabits/sec, and the coder is informed of th=
is. At t=3D8 seconds, the link rate &quot;(c)&quot; instantaneously changes=
 to
 500 kilobits/sec. The coder learns of this change at t=3D8.25 seconds.<o:p=
></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">The figure of merit is a combi=
nation of (1) visual fidelity (e.g. PSNR, SSIM, etc.) of the coded frames r=
elative to the source frames, and (2) the maximum difference
 between the &quot;encode time&quot; and &quot;display time&quot; of any fr=
ame, taken over all the frames in the video.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">Best regards,<o:p></o:p></span=
></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">Keith<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">On Tue, Jul 21, 2015 at 4:11 A=
M, Thomas Daede &lt;<a href=3D"mailto:tdaede@mozilla.com" target=3D"_blank"=
>tdaede@mozilla.com</a>&gt; wrote:<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">At the Monday NETVC session, i=
t was suggested that CBR mode with a fixed<br>
buffer size was not a very good representation of what rate control for<br>
video conferencing would do.<br>
<br>
Are there suggestions of a better model? Keep in mind that this is only<br>
for relatively short (~15s) clips.<br>
<br>
Another option is just to not specify CBR bounds, so that this test<br>
would be like the high latency test but with lookahead and 2 pass<br>
constraints.<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><o:p></o:p></span=
></p>
</div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_D93780CEB41CE1419C1A7542E3096BC210FF1973xmbalnx08ciscoc_--


From nobody Wed Jul 22 20:25:51 2015
Return-Path: <jonathan@vidyo.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 7A5391B2F3F for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 15:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.267
X-Spam-Level: 
X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 MpQAX3cVgB6p for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 15:17:20 -0700 (PDT)
Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (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 4F3C71B2F3D for <video-codec@ietf.org>; Wed, 22 Jul 2015 15:17:20 -0700 (PDT)
Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t6MMGhsS027804 for <video-codec@ietf.org>; Wed, 22 Jul 2015 18:17:19 -0400
Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1vndj4bycj-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <video-codec@ietf.org>; Wed, 22 Jul 2015 18:17:19 -0400
Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 17:17:18 -0500
From: Jonathan Lennox <jonathan@vidyo.com>
To: "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: Temporal characteristics of screensharing
Thread-Index: AQHQxMwrj9fBZKu+G0u9VmDq0b5apA==
Date: Wed, 22 Jul 2015 22:17:17 +0000
Message-ID: <4482BFF6-9714-4439-897A-5E76DB490D21@vidyo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.129.15.250]
Content-Type: text/plain; charset="utf-8"
Content-ID: <B370DC133F11FC42837FD11AD38762EE@vidyo.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33,  0.0.0000 definitions=2015-07-22_07:2015-07-22,2015-07-22,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507220321
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/ctGKQ9ws86cdBiVZZi6K8kIXCiU>
X-Mailman-Approved-At: Wed, 22 Jul 2015 20:25:50 -0700
Subject: [video-codec] Temporal characteristics of screensharing
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Jul 2015 22:17:21 -0000

SGksIGFsbCDigJQNCg0KQXMgcmVxdWVzdGVkLCBJ4oCZbSBwb3N0aW5nIHRvIHRoZSBsaXN0IG15
IGNvbW1lbnQgYXQgdGhlIG1pYyB0b2RheSBhYm91dCB0aGUgdGVtcG9yYWwgY2hhcmFjdGVyaXN0
aWNzIG9mIHNjcmVlbnNoYXJpbmcuDQoNClRoZSBjaGFyYWN0ZXJpc3RpYyBJIHdhcyBkZXNjcmli
aW5nIGlzIG5vdCB1bml2ZXJzYWwgdG8gZXZlcnl0aGluZyB0aGF04oCZcyBkZXNjcmliZWQgYXMg
4oCcc2NyZWVuc2hhcmluZyzigJ0gYnV0IGl04oCZcyBub3RhYmxlIGluIHRoZSBjb21tb24gdXNl
IGNhc2Ugb2YgcHJlc2VudGF0aW9uIHNoYXJpbmcgYW5kIHRoZSBsaWtlLg0KDQpUaGUgY2hhcmFj
dGVyaXN0aWMgSeKAmW0gdGhpbmtpbmcgb2YgaXMgdGhhdCB0aGUgdmlkZW8gc3RheXMgc3RhdGlj
IG9yIG5lYXJseSBzdGF0aWMgZm9yIGxvbmcgYnV0IHVucHJlZGljdGFibGUgcGVyaW9kcyBvZiB0
aW1lIChzaG93aW5nIHRoZSBzbGlkZSksIGFuZCB0aGVuIG1hbnkgcGFydHMgb2YgdGhlIGltYWdl
IGNoYW5nZSBhbGwgYXQgb25jZSB3aXRoIGxpdHRsZSBvciBubyBjb21tb25hbGl0eSB3aXRoIHRo
ZSBwcmV2aW91cyBpbWFnZSAoY2hhbmdpbmcgdGhlIHNsaWRlKS4gQnV0IHRoZXJlIG1heSBhbHNv
IGJlIHBlcmlvZHMgb2YgdGltZSB3aXRoIG1vcmUgdHJhZGl0aW9uYWwgdmlkZW8tbGlrZSBiZWhh
dmlvciAoYW5pbWF0aW9ucyBhbmQgdGhlIGxpa2UpLg==


From nobody Thu Jul 23 15:23: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 44FCB1B2A16 for <video-codec@ietfa.amsl.com>; Thu, 23 Jul 2015 15:23:27 -0700 (PDT)
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 W157GEFtlufo for <video-codec@ietfa.amsl.com>; Thu, 23 Jul 2015 15:23:23 -0700 (PDT)
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (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 A6D471A1A1D for <video-codec@ietf.org>; Thu, 23 Jul 2015 15:23:23 -0700 (PDT)
Received: by wibxm9 with SMTP id xm9so3896503wib.0 for <video-codec@ietf.org>; Thu, 23 Jul 2015 15:23:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=qoDTqUKNo/Tuh/06qoiUIdORBYjBDsP79TpG015mzPg=; b=CHqCphNEStmMRCZJxviq2N2Ih1+SHkJXF3p8F9IvbbfGbq2gqROBsuOgMW/0lB+lps ClIo0miZdu8KvhPD67+oN9U7Kr812+5uSrdz4k9HfODgjcOoNzhZJg0aFAvLId/9mYpb 40llsurmnnm6s99j/qXj6vmi3Y8QxQDyOs4u/LBz6Z5SqeevrAR6QtVny7ozdmOXIZ6y zj2FcA6kh3aUvqhZLpJ6H3kKHaxRzJOHZxwqGW/bKECcuRfSHaSJwfCRPPeb+4xgPV4U 7NFHMe7Ojyn4vyB3UZ9zdYToGG5MNespISQegSL5wv3I0HoOA0DPCT8QUG6lcFLO3A/8 XjWw==
X-Gm-Message-State: ALoCoQlbz5nUKbZta0DOjQPWmOAKHpqXb0/pQxsPxu3buZb3dXWc9PdCEIRXVOISp3vSk+K1tgDr
X-Received: by 10.180.20.48 with SMTP id k16mr926323wie.56.1437690202276; Thu, 23 Jul 2015 15:23:22 -0700 (PDT)
Received: from [192.168.10.237] (static-84-42-170-138.net.upcbroadband.cz. [84.42.170.138]) by smtp.gmail.com with ESMTPSA id h9sm9528344wjx.20.2015.07.23.15.23.21 for <video-codec@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jul 2015 15:23:21 -0700 (PDT)
To: video-codec@ietf.org
References: <4482BFF6-9714-4439-897A-5E76DB490D21@vidyo.com>
From: Thomas Daede <tdaede@mozilla.com>
Message-ID: <55B16959.6020405@mozilla.com>
Date: Fri, 24 Jul 2015 00:23:21 +0200
User-Agent: http://a.pomf.se/cszdno.opus
MIME-Version: 1.0
In-Reply-To: <4482BFF6-9714-4439-897A-5E76DB490D21@vidyo.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/eWMUfsNQ4AIVjGT1f3bX8FjSwIs>
Subject: Re: [video-codec] Temporal characteristics of screensharing
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: <https://mailarchive.ietf.org/arch/browse/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, 23 Jul 2015 22:23:27 -0000

OK. From my understanding, it should be very easy to get high
performance from this sort of content in a constant-quality mode. The
tricky part is doing this with CBR rate control constraints.

Do the CBR bounds specified in the presentation make sense (300ms bucket
allowed for deviations)? If so, I think that test case is sufficient.

On 07/23/2015 12:17 AM, Jonathan Lennox wrote:
> Hi, all —
> 
> As requested, I’m posting to the list my comment at the mic today about the temporal characteristics of screensharing.
> 
> The characteristic I was describing is not universal to everything that’s described as “screensharing,” but it’s notable in the common use case of presentation sharing and the like.
> 
> The characteristic I’m thinking of is that the video stays static or nearly static for long but unpredictable periods of time (showing the slide), and then many parts of the image change all at once with little or no commonality with the previous image (changing the slide). But there may also be periods of time with more traditional video-like behavior (animations and the like).
> _______________________________________________
> video-codec mailing list
> video-codec@ietf.org
> https://www.ietf.org/mailman/listinfo/video-codec
> 


From nobody Fri Jul 24 04:02:34 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 2CFB81A8F38 for <video-codec@ietfa.amsl.com>; Fri, 24 Jul 2015 04:02:33 -0700 (PDT)
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 3LsREGyMMYfH for <video-codec@ietfa.amsl.com>; Fri, 24 Jul 2015 04:02:28 -0700 (PDT)
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (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 7A8F91A8BBE for <video-codec@ietf.org>; Fri, 24 Jul 2015 04:02:28 -0700 (PDT)
Received: by wibud3 with SMTP id ud3so60597358wib.1 for <video-codec@ietf.org>; Fri, 24 Jul 2015 04:02:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=0Q+mrqT3+tyinMUVIbRii8vc2T9CXGruM4jbhQoalDs=; b=aThOb+eW7PH3C9paMao72ICm4W/8I3TPQ4XBcnaXO+ndQfex5sHXgWwRJ/pW7E30ki qbVg0rjdeTIdGmp53Wgl2wOAPiB2bIv2xUUZjJ29tvrGp/fBhCk9SxGuGu68OPkEL1UH F0hYG6wzP2irrVjgMtFPrzeAGjvjF944uXtm+1PxfqCy5hJTJR5V09VF3amoweGAyen0 nvqI2IF+2R2JHDUhy9iSvQhpnMtzEld/aA+nu+yDWLkORjSiHag6NuKj0aZ0Qh3U5Z/K 95qCSxT4utS59SHSa+mT2EKcrCWjJj8BjYJQsprPftXeP6Lfib0gT9udN6+lrrEcVx4V JXNA==
X-Gm-Message-State: ALoCoQk3BgC1Ei08kh0ikdQWY60jZsc1SdVV9TPgIOrVH06EmWEpJDF/NbSsZaGnERyD0NFftskE
X-Received: by 10.194.142.209 with SMTP id ry17mr27374140wjb.5.1437735747076;  Fri, 24 Jul 2015 04:02:27 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:176:7e7a:91ff:fe9e:8126? ([2001:67c:370:176:7e7a:91ff:fe9e:8126]) by smtp.gmail.com with ESMTPSA id c11sm2990597wib.1.2015.07.24.04.02.25 for <video-codec@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jul 2015 04:02:26 -0700 (PDT)
To: "video-codec@ietf.org" <video-codec@ietf.org>
From: Thomas Daede <tdaede@mozilla.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <55B21B41.6080408@mozilla.com>
Date: Fri, 24 Jul 2015 13:02:25 +0200
User-Agent: http://a.pomf.se/cszdno.opus
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/zaD8LzeDqnKGbFUIN7M_ulB4Pvs>
Subject: [video-codec] Thor on Jenkins
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 24 Jul 2015 11:02:33 -0000

I have added Thor projects to our Jenkins instance:

https://mf4.xiph.org/jenkins/

The builds include a 64-bit Windows build, compiled with mingw64.

Building Thor with Clang, or on ARM with GCC is currently broken. Fixing
them would be an easy starter project for anyone interested in contributing.


From nobody Fri Jul 24 09:30:32 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 0C4EB1ACED3 for <video-codec@ietfa.amsl.com>; Fri, 24 Jul 2015 09:30:31 -0700 (PDT)
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 P-tLD88S0ZDj for <video-codec@ietfa.amsl.com>; Fri, 24 Jul 2015 09:30:27 -0700 (PDT)
Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) (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 CE8AF1A9092 for <video-codec@ietf.org>; Fri, 24 Jul 2015 09:30:26 -0700 (PDT)
Received: by pdrg1 with SMTP id g1so15967442pdr.2 for <video-codec@ietf.org>; Fri, 24 Jul 2015 09:30:26 -0700 (PDT)
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=/d75+juo0mvNtyWMtQ0Z4W+PaVoQ8zzXMA9yC41CPp4=; b=lU2RMOuZCBg9hm9BRNBsG/Q9uwPVt3vC4+89hbudZCdshrSUzfB0hPd6vcG04uteP9 z+nS3HdIw3MJ3bM+rpHjURCQJbyvhGhCFoloI+OyPc75nhHKBSdCwM/eXO6LGe0s0Odj YoEEBXiyej5WV/krqHQHCT0xiH16P8iSq81ZSFcEZeDN43eeZxwJdfirToad6MYXXpgY 8f354DqzM1Bid/+j1tdl8fPSGdaWIeSm57ysRBaLzk1Nkb6sElAautSW6XJt8nCOTpnY +0HAu2qitdKZnt7RN1APgp7tzy/M+hhEErJLFSgfy8TfZrjDqJ7OTHHsGtvSdRRLN2NP wQgA==
X-Gm-Message-State: ALoCoQkf9MoBn9Cnl9AZiy4MpdQtXstXmqT7lqDUia6CsEW/oVIadk+hg952sLM+fzXgRcCIEhMA
MIME-Version: 1.0
X-Received: by 10.67.5.2 with SMTP id ci2mr32432668pad.97.1437755426255; Fri, 24 Jul 2015 09:30:26 -0700 (PDT)
Received: by 10.70.27.4 with HTTP; Fri, 24 Jul 2015 09:30:26 -0700 (PDT)
In-Reply-To: <55B21B41.6080408@mozilla.com>
References: <55B21B41.6080408@mozilla.com>
Date: Fri, 24 Jul 2015 09:30:26 -0700
Message-ID: <CABSTHf2PjWgrbUupWCMqvb6D0VO32vcFa7E9AGBRCFJBaROj8Q@mail.gmail.com>
From: Yushin Cho <ycho@mozilla.com>
To: Thomas Daede <tdaede@mozilla.com>
Content-Type: multipart/alternative; boundary=047d7b15fdd174d4a6051ba18533
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/J0gMwR824CiCW7eGM6KF1xlfduE>
Cc: "video-codec@ietf.org" <video-codec@ietf.org>
Subject: Re: [video-codec] Thor on Jenkins
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 24 Jul 2015 16:30:31 -0000

--047d7b15fdd174d4a6051ba18533
Content-Type: text/plain; charset=UTF-8

Thomas, thanks for the nice work!

-yushin

On Fri, Jul 24, 2015 at 4:02 AM, Thomas Daede <tdaede@mozilla.com> wrote:

> I have added Thor projects to our Jenkins instance:
>
> https://mf4.xiph.org/jenkins/
>
> The builds include a 64-bit Windows build, compiled with mingw64.
>
> Building Thor with Clang, or on ARM with GCC is currently broken. Fixing
> them would be an easy starter project for anyone interested in
> contributing.
>
> _______________________________________________
> video-codec mailing list
> video-codec@ietf.org
> https://www.ietf.org/mailman/listinfo/video-codec
>



-- 
Thanks!
Yushin

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

<div dir=3D"ltr"><div>Thomas, thanks for the nice work!<br><br></div>-yushi=
n<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri=
, Jul 24, 2015 at 4:02 AM, Thomas Daede <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto: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;bo=
rder-left:1px #ccc solid;padding-left:1ex">I have added Thor projects to ou=
r Jenkins instance:<br>
<br>
<a href=3D"https://mf4.xiph.org/jenkins/" rel=3D"noreferrer" target=3D"_bla=
nk">https://mf4.xiph.org/jenkins/</a><br>
<br>
The builds include a 64-bit Windows build, compiled with mingw64.<br>
<br>
Building Thor with Clang, or on ARM with GCC is currently broken. Fixing<br=
>
them would be an easy starter project for anyone interested in contributing=
.<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" rel=3D"norefe=
rrer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/video-codec</=
a><br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>Thanks!<br></div>Yushin=
<br></div></div></div></div>
</div>

--047d7b15fdd174d4a6051ba18533--


From nobody Fri Jul 24 10:01:12 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 11E3B1A00A7 for <video-codec@ietfa.amsl.com>; Fri, 24 Jul 2015 10:01:11 -0700 (PDT)
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 r_ksjCXznioa for <video-codec@ietfa.amsl.com>; Fri, 24 Jul 2015 10:01:06 -0700 (PDT)
Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) (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 512901A008A for <video-codec@ietf.org>; Fri, 24 Jul 2015 10:00:57 -0700 (PDT)
Received: by pabkd10 with SMTP id kd10so17109649pab.2 for <video-codec@ietf.org>; Fri, 24 Jul 2015 10:00:56 -0700 (PDT)
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=ociAbEPHXC2UYz9whyxIaFANljycJre7XidKFogDcwI=; b=CH8Lkmx+HGfwSYfDj7RmjIMnLeKG1LeoqlowC/+InvZv0KpXlU0RlXInSijckW5caV ktRUw1/u5mnFn/Krn1g1ALAO4Neh3+/KPMSp532wYtiFlp6Kbwool6uHzPqI9wBdQEph u9NxH5aapy7O4klSgBPpjAXCoCgau9m81WImU73jlWuSTs84Y1Q7E7mNriuNoV9J0LQ6 4JoPzbddWo6miRtzk2hdK3Nq7IbuVIgNY/+bspLJdX25W/KJ14CYTJlibViU2uAKwigV NlIHwAmVcAr9uHfBMopVuEsQUAJL3Fmcb74M3v48dlOmBd1OaHXVZ3bLvCbBVDN9d5Dn KBtA==
X-Gm-Message-State: ALoCoQnDoqYUNr9JavBSxz61mdJ74FfibGIEEpNz577/zIcL8VyWJjBNPqU1RyR/Eo8lSLrpyeK/
MIME-Version: 1.0
X-Received: by 10.66.65.205 with SMTP id z13mr33135372pas.65.1437757256805; Fri, 24 Jul 2015 10:00:56 -0700 (PDT)
Received: by 10.70.27.4 with HTTP; Fri, 24 Jul 2015 10:00:56 -0700 (PDT)
In-Reply-To: <D93780CEB41CE1419C1A7542E3096BC210FF1973@xmb-aln-x08.cisco.com>
References: <55AE28F6.6070100@mozilla.com> <CAMzhQmN17crzSPQSzy3jzz+8gfu8tZr8mFyCOSmvSX1pheppAg@mail.gmail.com> <D1D503BF.5222C%mzanaty@cisco.com> <D93780CEB41CE1419C1A7542E3096BC210FF1973@xmb-aln-x08.cisco.com>
Date: Fri, 24 Jul 2015 10:00:56 -0700
Message-ID: <CABSTHf0EyEbTOay_NUNSXd+EVfFizafeYBpQ_DOCxaZYWnXU2Q@mail.gmail.com>
From: Yushin Cho <ycho@mozilla.com>
To: "Arild Fuldseth (arilfuld)" <arilfuld@cisco.com>
Content-Type: multipart/alternative; boundary=001a11362f3a90d547051ba1f226
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/LovHiFgJA5HeykgesegNWhm3rI8>
Cc: "video-codec@ietf.org" <video-codec@ietf.org>, "keithw@mit.edu" <keithw@mit.edu>, Thomas Daede <tdaede@mozilla.com>, "Mo Zanaty \(mzanaty\)" <mzanaty@cisco.com>
Subject: Re: [video-codec] Low-latency rate control constraints
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 24 Jul 2015 17:01:11 -0000

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

Fully agree on Arild's point.

A Video codec w/o rate control would be useless as someone mentioned,
but it will be very hard to evaluate the codec's true coding performance if
different rate controllers are used.
If our test includes CBR mode, I expect that a block level rate control
will be required (probably tuned for subjective quality),
which has dependency on the codec, then a evaluation would hardly avoid the
dependency on the particular rate control algorithm.

-yushin

On Wed, Jul 22, 2015 at 9:43 AM, Arild Fuldseth (arilfuld) <
arilfuld@cisco.com> wrote:

>  All,
>
>
>
> My concern is that mandating CBR and/or allowing for 2-pass encoding with
> input-dependent GOP/QP structures would encourage people to spend a lot of
> effort on non-normative encoding techniques. Also, it would be more
> difficult to determine whether or not any differences is due to normative-
> or non-normative techniques.
>
>
>
> I would recommend that netvc candidate encoders should at least support
> the same fixed (input-independent) GOP structure as JCT-VC test conditions,
> and that this should be the primary mode of testing both for low-delay  and
> high-delay.
>
>
>
> This has the additional advantage is that it would be possible to do an
> apple-to-apple comparison with HM reference software.
>
>
>
> Regards,
>
>
>
> Arild
>
>
>
> *From:* video-codec [mailto:video-codec-bounces@ietf.org] *On Behalf Of *Mo
> Zanaty (mzanaty)
> *Sent:* 22. juli 2015 15:10
> *To:* keithw@mit.edu; Thomas Daede
> *Cc:* video-codec@ietf.org
> *Subject:* Re: [video-codec] Low-latency rate control constraints
>
>
>
> I agree encoder latency should be specified directly in low latency
> testing. IMO, this has nothing to do with bitrates or rate control
> strategies. It is simply constraining the encoder to zero structural delay
> when encoding each frame. That is, frame in, frame out, no reordering or
> lookahead.
>
>
>
> Rate control constraints may be necessary in some testing to reflect
> transport channel constraints. But this should not be conflated with low
> latency as in zero structural delay.
>
>
>
> Mo (as individual)
>
>
>
> On 7/22/15, 4:40 AM, video-codec on behalf of Keith Winstein <
> video-codec-bounces@ietf.org on behalf of keithw@mit.edu> wrote:
>
>
>
> Hello Thomas,
>
>
>
> It seems like constraining the bitrate variation by enforcing a limited
> receiver-side VBV buffer is kind of an indirect way to get at what you
> really care about. Most receivers can probably buffer at least >5 megabytes
> (so >5 seconds of video) with no problem. If the document wants to specify
> a model for low-latency video, I think the constraint might be better
> expressed in terms of latency directly.
>
>
>
> Here would be my proposal for an idealized model for what video
> conferencing would require from the video coder:
>
>
>
> (a) The source video arrives at 30 fps, and each frame is given an "encode
> time" of n/30 seconds.
>
> (b) After being encoded, the coded frames are appended to a sender-side
> FIFO.
>
> (c) The sender-side FIFO is drained (and delivered to the receiver) at a
> particular link rate given in bits per second.
>
> (d) At the receiver, each frame is given a "display time" of the earliest
> moment it can be shown to the user given when its coded representation
> finishes being delivered, and any rules of the format about frame
> reordering (i.e. the presentation timestamp of MPEG). The receiver doesn't
> attempt isochronous presentation of the frames; it just shows each frame at
> the earliest possible moment.
>
>
>
> For the first 8 seconds, the link rate "(c)" is 4 megabits/sec, and the
> coder is informed of this. At t=8 seconds, the link rate "(c)"
> instantaneously changes to 500 kilobits/sec. The coder learns of this
> change at t=8.25 seconds.
>
>
>
> The figure of merit is a combination of (1) visual fidelity (e.g. PSNR,
> SSIM, etc.) of the coded frames relative to the source frames, and (2) the
> maximum difference between the "encode time" and "display time" of any
> frame, taken over all the frames in the video.
>
>
>
> Best regards,
>
> Keith
>
>
>
> On Tue, Jul 21, 2015 at 4:11 AM, Thomas Daede <tdaede@mozilla.com> wrote:
>
> At the Monday NETVC session, it was suggested that CBR mode with a fixed
> buffer size was not a very good representation of what rate control for
> video conferencing would do.
>
> Are there suggestions of a better model? Keep in mind that this is only
> for relatively short (~15s) clips.
>
> Another option is just to not specify CBR bounds, so that this test
> would be like the high latency test but with lookahead and 2 pass
> constraints.
>
> _______________________________________________
> 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

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

<div dir=3D"ltr"><div><div>Fully agree on Arild&#39;s point.<br><br></div>A=
 Video codec w/o rate control would be useless as someone mentioned,<br>but=
 it will be very hard to evaluate the codec&#39;s true coding performance i=
f different rate controllers are used.<br></div><div>If our test includes C=
BR mode, I expect that a block level rate control will be required (probabl=
y tuned for subjective quality), <br>which has dependency on the codec, the=
n a evaluation would hardly avoid the dependency on the particular rate con=
trol algorithm.<br></div><div></div><div><br></div>-yushin<br></div><div cl=
ass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Jul 22, 2015 at =
9:43 AM, Arild Fuldseth (arilfuld) <span dir=3D"ltr">&lt;<a href=3D"mailto:=
arilfuld@cisco.com" target=3D"_blank">arilfuld@cisco.com</a>&gt;</span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">





<div link=3D"blue" vlink=3D"purple" lang=3D"NO-BOK">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US">All,<u></u=
><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US"><u></u>=C2=
=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US">My concern=
 is that mandating CBR and/or allowing for 2-pass encoding with input-depen=
dent GOP/QP structures would encourage people to spend a lot
 of effort on non-normative encoding techniques. Also, it would be more dif=
ficult to determine whether or not any differences is due to normative- or =
non-normative techniques.<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US"><u></u>=C2=
=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US">I would re=
commend that netvc candidate encoders should at least support the same fixe=
d (input-independent) GOP structure as JCT-VC test conditions,
 and that this should be the primary mode of testing both for low-delay=C2=
=A0 and high-delay.<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US"><u></u>=C2=
=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US">This has t=
he additional advantage is that it would be possible to do an apple-to-appl=
e comparison with HM reference software.<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US"><u></u>=C2=
=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US">Regards,<u=
></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US"><u></u>=C2=
=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US">Arild<u></=
u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US"><u></u>=C2=
=A0<u></u></span></p>
<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;" lang=3D"EN-US">From:</span></b><span =
style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&q=
uot;" lang=3D"EN-US"> video-codec [mailto:<a href=3D"mailto:video-codec-bou=
nces@ietf.org" target=3D"_blank">video-codec-bounces@ietf.org</a>]
<b>On Behalf Of </b>Mo Zanaty (mzanaty)<br>
<b>Sent:</b> 22. juli 2015 15:10<br>
<b>To:</b> <a href=3D"mailto:keithw@mit.edu" target=3D"_blank">keithw@mit.e=
du</a>; Thomas Daede<br>
<b>Cc:</b> <a href=3D"mailto:video-codec@ietf.org" target=3D"_blank">video-=
codec@ietf.org</a><br>
<b>Subject:</b> Re: [video-codec] Low-latency rate control constraints<u></=
u><u></u></span></p>
</div>
</div><div><div class=3D"h5">
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">I agree encoder latency should=
 be specified directly in low latency testing. IMO, this has nothing to do =
with bitrates or rate control strategies. It is simply constraining
 the encoder to zero structural delay when encoding each frame. That is, fr=
ame in, frame out, no reordering or lookahead.<u></u><u></u></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black"><u></u>=C2=A0<u></u></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">Rate control constraints may b=
e necessary in some testing to reflect transport channel constraints. But t=
his should not be conflated with low latency as in zero
 structural delay.<u></u><u></u></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black"><u></u>=C2=A0<u></u></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">Mo (as individual)<u></u><u></=
u></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black"><u></u>=C2=A0<u></u></span></p=
>
</div>
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">On 7/22/15, 4:40 AM, video-cod=
ec on behalf of Keith Winstein &lt;<a href=3D"mailto:video-codec-bounces@ie=
tf.org" target=3D"_blank">video-codec-bounces@ietf.org</a> on behalf of
<a href=3D"mailto:keithw@mit.edu" target=3D"_blank">keithw@mit.edu</a>&gt; =
wrote:<u></u><u></u></span></p>
</div>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black"><u></u>=C2=A0<u></u></span></p=
>
</div>
<div>
<div>
<div>
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">Hello Thomas,<u></u><u></u></s=
pan></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black"><u></u>=C2=A0<u></u></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">It seems like constraining the=
 bitrate variation by enforcing a limited receiver-side VBV buffer is kind =
of an indirect way to get at what you really care about.
 Most receivers can probably buffer at least &gt;5 megabytes (so &gt;5 seco=
nds of video) with no problem. If the document wants to specify a model for=
 low-latency video, I think the constraint might be better expressed in ter=
ms of latency directly.<u></u><u></u></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black"><u></u>=C2=A0<u></u></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">Here would be my proposal for =
an idealized model for what video conferencing would require from the video=
 coder:<u></u><u></u></span></p>
</div>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black"><u></u>=C2=A0<u></u></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">(a) The source video arrives a=
t 30 fps, and each frame is given an &quot;encode time&quot; of n/30 second=
s.<u></u><u></u></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">(b) After being encoded, the c=
oded frames are appended to a sender-side FIFO.<u></u><u></u></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">(c) The sender-side FIFO is dr=
ained (and delivered to the receiver) at a particular link rate given in bi=
ts per second.<u></u><u></u></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">(d) At the receiver, each fram=
e is given a &quot;display time&quot; of the earliest moment it can be show=
n to the user given when its coded representation finishes being delivered,
 and any rules of the format about frame reordering (i.e. the presentation =
timestamp of MPEG). The receiver doesn&#39;t attempt isochronous presentati=
on of the frames; it just shows each frame at the earliest possible moment.=
<u></u><u></u></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black"><u></u>=C2=A0<u></u></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">For the first 8 seconds, the l=
ink rate &quot;(c)&quot; is 4 megabits/sec, and the coder is informed of th=
is. At t=3D8 seconds, the link rate &quot;(c)&quot; instantaneously changes=
 to
 500 kilobits/sec. The coder learns of this change at t=3D8.25 seconds.<u><=
/u><u></u></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black"><u></u>=C2=A0<u></u></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">The figure of merit is a combi=
nation of (1) visual fidelity (e.g. PSNR, SSIM, etc.) of the coded frames r=
elative to the source frames, and (2) the maximum difference
 between the &quot;encode time&quot; and &quot;display time&quot; of any fr=
ame, taken over all the frames in the video.<u></u><u></u></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black"><u></u>=C2=A0<u></u></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">Best regards,<u></u><u></u></s=
pan></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">Keith<u></u><u></u></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black"><u></u>=C2=A0<u></u></span></p=
>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">On Tue, Jul 21, 2015 at 4:11 A=
M, Thomas Daede &lt;<a href=3D"mailto:tdaede@mozilla.com" target=3D"_blank"=
>tdaede@mozilla.com</a>&gt; wrote:<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black">At the Monday NETVC session, i=
t was suggested that CBR mode with a fixed<br>
buffer size was not a very good representation of what rate control for<br>
video conferencing would do.<br>
<br>
Are there suggestions of a better model? Keep in mind that this is only<br>
for relatively short (~15s) clips.<br>
<br>
Another option is just to not specify CBR bounds, so that this test<br>
would be like the high latency test but with lookahead and 2 pass<br>
constraints.<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><u></u><u></u></s=
pan></p>
</div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:black"><u></u>=C2=A0<u></u></span></p=
>
</div>
</div>
</div>
</div>
</div></div></div>
</div>

<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" rel=3D"norefe=
rrer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/video-codec</=
a><br>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail=
_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>Thanks!<br></div>Yu=
shin<br></div></div></div></div>
</div>

--001a11362f3a90d547051ba1f226--


From le.businessman@gmail.com  Fri Jul 24 12:34:44 2015
Return-Path: <le.businessman@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 9CCC11A8994 for <video-codec@ietfa.amsl.com>; Fri, 24 Jul 2015 12:34:44 -0700 (PDT)
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, FREEMAIL_FROM=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 zpAJknlMD2GZ for <video-codec@ietfa.amsl.com>; Fri, 24 Jul 2015 12:34:40 -0700 (PDT)
Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (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 729DE1A212D for <video-codec@ietf.org>; Fri, 24 Jul 2015 12:34:40 -0700 (PDT)
Received: by iehx8 with SMTP id x8so25798895ieh.3 for <video-codec@ietf.org>; Fri, 24 Jul 2015 12:34:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L57kwzVpxWXgshpk5/DSRFjSPWywSsxRhkeOgRNATEQ=; b=YszQLz0+M8rx00W+5kiZoFW+3NRg7dVQdxl8bTYCWDFT5SRas46wAwvRVgk+yDcwyP PLUApxoUD6eudgvtWQDkCl2/+YY3kZlNlanEq2W06l90vTTJ3Hh5CWD5EfcPhQPtiotJ ie9tKp/yrYDYmdJ3EJugjfeomYvbpcvuAR+RMUs8ntEjaH1rcTvciNNG2HjdTSH9bTlM FQA8avWkyVvUWDAocH0W1gf15qkg+fd3Shc2QqTJ4hQHQi2s3pLGxlBPFLps0UgRXuAE dy3Hq76wwbgnuUjl7/eInyPquO5klT8fMM7Qg76qcOWtcE4oxng6FmYaJxCTmRGhoFn0 JTjg==
X-Received: by 10.50.143.37 with SMTP id sb5mr9520118igb.13.1437766479813; Fri, 24 Jul 2015 12:34:39 -0700 (PDT)
Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com. [209.85.213.172]) by smtp.gmail.com with ESMTPSA id g3sm2158565igi.10.2015.07.24.12.34.39 for <video-codec@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jul 2015 12:34:39 -0700 (PDT)
Received: by igbpg9 with SMTP id pg9so43872756igb.0 for <video-codec@ietf.org>; Fri, 24 Jul 2015 12:34:39 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.18.10 with SMTP id a10mr27182516ioj.98.1437766479396; Fri, 24 Jul 2015 12:34:39 -0700 (PDT)
Received: by 10.36.248.6 with HTTP; Fri, 24 Jul 2015 12:34:39 -0700 (PDT)
In-Reply-To: <55B21B41.6080408@mozilla.com>
References: <55B21B41.6080408@mozilla.com>
Date: Fri, 24 Jul 2015 15:34:39 -0400
Message-ID: <CAN8HRDkRErFvDf--BSVQkLcazPd3yaQcKSGqanVEHfs71nBipA@mail.gmail.com>
From: Tristan Matthews <tmatth@videolan.org>
To: Thomas Daede <tdaede@mozilla.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/6wduqYIxgq0ACvB-sB07P5qssqI>
Cc: "video-codec@ietf.org" <video-codec@ietf.org>
Subject: Re: [video-codec] Thor on Jenkins
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 24 Jul 2015 19:37:33 -0000

On Fri, Jul 24, 2015 at 7:02 AM, Thomas Daede <tdaede@mozilla.com> wrote:
>
> I have added Thor projects to our Jenkins instance:
>
> https://mf4.xiph.org/jenkins/
>
> The builds include a 64-bit Windows build, compiled with mingw64.
>
> Building Thor with Clang, or on ARM with GCC is currently broken. Fixing
> them would be an easy starter project for anyone interested in contributing.
>

Thanks Thomas, I created these tickets for interested parties:

ARM - https://github.com/cisco/thor/issues/5
clang - https://github.com/cisco/thor/issues/6

Best,
Tristan


From nobody Sun Jul 26 11:18:50 2015
Return-Path: <sergio.garcia.murillo@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 80D541ACD19 for <video-codec@ietfa.amsl.com>; Sun, 26 Jul 2015 11:18:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level: 
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 q1TUfZ6ZUBjX for <video-codec@ietfa.amsl.com>; Sun, 26 Jul 2015 11:18:48 -0700 (PDT)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (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 26D871A1B6B for <video-codec@ietf.org>; Sun, 26 Jul 2015 11:18:48 -0700 (PDT)
Received: by igbpg9 with SMTP id pg9so52198240igb.0 for <video-codec@ietf.org>; Sun, 26 Jul 2015 11:18:47 -0700 (PDT)
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 :cc:content-type; bh=jCF3NGTLK7iKbmr1wHkjgZ7Yhbilh9Y3MrSgP6APyiA=; b=rqXGHilOkAqSW3k++uXXJDeeF3nuf+Srcvl38ME8suyZhW+uvBQHfKgrNBvcKMb2lc aNquRmUc6kjHDXzcx6hhhdxhaKVF8QzjYYtJmukgbumTWCyADoTglQOABCfGls3exhin RzKM7CZatcTC4gWmKgBBZvm0Ox0T/tT/KpVsdGlGfb737Al3dxh8N/g+LXoT0fCRQDMx 5+Ee8w12EkIGjMs25QUQYSMbRFlJA4f5Ceej4LYPkuglziEcpV+2nYiEeO5aB1CPul8Z KTgopqh/cxpKAW0hQKBu758j66Qj4lHmoPaFQ04v5MhmO6SbvJaDbQkfz9DnoeoV3Ome omhg==
MIME-Version: 1.0
X-Received: by 10.107.128.147 with SMTP id k19mr41625921ioi.133.1437934727571;  Sun, 26 Jul 2015 11:18:47 -0700 (PDT)
Received: by 10.107.168.195 with HTTP; Sun, 26 Jul 2015 11:18:47 -0700 (PDT)
Received: by 10.107.168.195 with HTTP; Sun, 26 Jul 2015 11:18:47 -0700 (PDT)
In-Reply-To: <D1D503BF.5222C%mzanaty@cisco.com>
References: <55AE28F6.6070100@mozilla.com> <CAMzhQmN17crzSPQSzy3jzz+8gfu8tZr8mFyCOSmvSX1pheppAg@mail.gmail.com> <D1D503BF.5222C%mzanaty@cisco.com>
Date: Sun, 26 Jul 2015 20:18:47 +0200
Message-ID: <CA+ag07a-uuoEE-FcunTgpKM-SS-47Y2Fux=iuR_BB4gJPo10aQ@mail.gmail.com>
From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
To: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
Content-Type: multipart/alternative; boundary=001a113fc336a5aed8051bcb44dd
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/WKhaD5T0IYB7UZl9KiI3e8UrkJA>
Cc: Thomas Daede <tdaede@mozilla.com>, "keithw@mit.edu" <keithw@mit.edu>, video-codec@ietf.org
Subject: Re: [video-codec] Low-latency rate control constraints
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 26 Jul 2015 18:18:50 -0000

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

+1

Anything different than zero latency is useless for video conferencing.
Obviously no second pass neither, and rate control should be instantly
applied.

>From my practical experience with non-video conferencing encoders I
typically have to set vbv buffers size to exactly one frame based on
current bitrate in order to get a real time behavior.

I would think twice about CBR on a power frame basis, as it could be
helpful for bandwidth estimation algorithms, although redundant/recovery
info may be a better usage of the extra bitrate.

Best regards
Sergio

El 22/7/2015 15:10, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com> escribi=C3=B3=
:

>  I agree encoder latency should be specified directly in low latency
> testing. IMO, this has nothing to do with bitrates or rate control
> strategies. It is simply constraining the encoder to zero structural dela=
y
> when encoding each frame. That is, frame in, frame out, no reordering or
> lookahead.
>
>  Rate control constraints may be necessary in some testing to reflect
> transport channel constraints. But this should not be conflated with low
> latency as in zero structural delay.
>
>  Mo (as individual)
>
>   On 7/22/15, 4:40 AM, video-codec on behalf of Keith Winstein <
> video-codec-bounces@ietf.org on behalf of keithw@mit.edu> wrote:
>
>    Hello Thomas,
>
>  It seems like constraining the bitrate variation by enforcing a limited
> receiver-side VBV buffer is kind of an indirect way to get at what you
> really care about. Most receivers can probably buffer at least >5 megabyt=
es
> (so >5 seconds of video) with no problem. If the document wants to specif=
y
> a model for low-latency video, I think the constraint might be better
> expressed in terms of latency directly.
>
>  Here would be my proposal for an idealized model for what video
> conferencing would require from the video coder:
>
>  (a) The source video arrives at 30 fps, and each frame is given an
> "encode time" of n/30 seconds.
> (b) After being encoded, the coded frames are appended to a sender-side
> FIFO.
> (c) The sender-side FIFO is drained (and delivered to the receiver) at a
> particular link rate given in bits per second.
> (d) At the receiver, each frame is given a "display time" of the earliest
> moment it can be shown to the user given when its coded representation
> finishes being delivered, and any rules of the format about frame
> reordering (i.e. the presentation timestamp of MPEG). The receiver doesn'=
t
> attempt isochronous presentation of the frames; it just shows each frame =
at
> the earliest possible moment.
>
>  For the first 8 seconds, the link rate "(c)" is 4 megabits/sec, and the
> coder is informed of this. At t=3D8 seconds, the link rate "(c)"
> instantaneously changes to 500 kilobits/sec. The coder learns of this
> change at t=3D8.25 seconds.
>
>  The figure of merit is a combination of (1) visual fidelity (e.g. PSNR,
> SSIM, etc.) of the coded frames relative to the source frames, and (2) th=
e
> maximum difference between the "encode time" and "display time" of any
> frame, taken over all the frames in the video.
>
>  Best regards,
> Keith
>
> On Tue, Jul 21, 2015 at 4:11 AM, Thomas Daede <tdaede@mozilla.com> wrote:
>
>> At the Monday NETVC session, it was suggested that CBR mode with a fixed
>> buffer size was not a very good representation of what rate control for
>> video conferencing would do.
>>
>> Are there suggestions of a better model? Keep in mind that this is only
>> for relatively short (~15s) clips.
>>
>> Another option is just to not specify CBR bounds, so that this test
>> would be like the high latency test but with lookahead and 2 pass
>> constraints.
>>
>> _______________________________________________
>> 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
>
>

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

<p dir=3D"ltr">+1</p>
<p dir=3D"ltr">Anything different than zero latency is useless for video co=
nferencing. Obviously no second pass neither, and rate control should be in=
stantly applied.</p>
<p dir=3D"ltr">From my practical experience with non-video conferencing enc=
oders I typically have to set vbv buffers size to exactly one frame based o=
n current bitrate in order to get a real time behavior.</p>
<p dir=3D"ltr">I would think twice about CBR on a power frame basis, as it =
could be helpful for bandwidth estimation algorithms, although redundant/re=
covery info may be a better usage of the extra bitrate.</p>
<p dir=3D"ltr">Best regards<br>
<font color=3D"#888888">Sergio</font><br><br></p>
<div class=3D"gmail_quote">El 22/7/2015 15:10, &quot;Mo Zanaty (mzanaty)&qu=
ot; &lt;<a href=3D"mailto:mzanaty@cisco.com">mzanaty@cisco.com</a>&gt; escr=
ibi=C3=B3:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style=3D"word-wrap:break-word;color:rgb(0,0,0);font-size:12px;font-fam=
ily:Arial,sans-serif">
<div>I agree encoder latency should be specified directly in low latency te=
sting. IMO, this has nothing to do with bitrates or rate control strategies=
. It is simply constraining the encoder to zero structural delay when encod=
ing each frame. That is, frame in,
 frame out, no reordering or lookahead.</div>
<div><br>
</div>
<div>Rate control constraints may be necessary in some testing to reflect t=
ransport channel constraints. But this should not be conflated with low lat=
ency as in zero structural delay.</div>
<div><br>
</div>
<div>Mo (as individual)</div>
<div><br>
</div>
<span>
<div>
<div>On 7/22/15, 4:40 AM, video-codec on behalf of Keith Winstein &lt;<a hr=
ef=3D"mailto:video-codec-bounces@ietf.org" target=3D"_blank">video-codec-bo=
unces@ietf.org</a> on behalf of
<a href=3D"mailto:keithw@mit.edu" target=3D"_blank">keithw@mit.edu</a>&gt; =
wrote:</div>
</div>
<div><br>
</div>
<div>
<div>
<div dir=3D"ltr">
<div>
<div>Hello Thomas,</div>
<div><br>
</div>
<div>It seems like constraining the bitrate variation by enforcing a limite=
d receiver-side VBV buffer is kind of an indirect way to get at what you re=
ally care about. Most receivers can probably buffer at least &gt;5 megabyte=
s (so &gt;5 seconds of video) with no
 problem. If the document wants to specify a model for low-latency video, I=
 think the constraint might be better expressed in terms of latency directl=
y.</div>
<div><br>
</div>
<div>Here would be my proposal for an idealized model for what video confer=
encing would require from the video coder:</div>
</div>
<div><br>
</div>
<div>(a) The source video arrives at 30 fps, and each frame is given an &qu=
ot;encode time&quot; of n/30 seconds.</div>
<div>(b) After being encoded, the coded frames are appended to a sender-sid=
e FIFO.</div>
<div>(c) The sender-side FIFO is drained (and delivered to the receiver) at=
 a particular link rate given in bits per second.</div>
<div>(d) At the receiver, each frame is given a &quot;display time&quot; of=
 the earliest moment it can be shown to the user given when its coded repre=
sentation finishes being delivered, and any rules of the format about frame=
 reordering (i.e. the presentation timestamp
 of MPEG). The receiver doesn&#39;t attempt isochronous presentation of the=
 frames; it just shows each frame at the earliest possible moment.</div>
<div><br>
</div>
<div>For the first 8 seconds, the link rate &quot;(c)&quot; is 4 megabits/s=
ec, and the coder is informed of this. At t=3D8 seconds, the link rate &quo=
t;(c)&quot; instantaneously changes to 500 kilobits/sec. The coder learns o=
f this change at t=3D8.25 seconds.</div>
<div><br>
</div>
<div>The figure of merit is a combination of (1) visual fidelity (e.g. PSNR=
, SSIM, etc.) of the coded frames relative to the source frames, and (2) th=
e maximum difference between the &quot;encode time&quot; and &quot;display =
time&quot; of any frame, taken over all the frames in
 the video.</div>
<div><br>
</div>
<div>Best regards,</div>
<div>Keith</div>
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On Tue, Jul 21, 2015 at 4:11 AM, Thomas Daede <s=
pan 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:1p=
x #ccc solid;padding-left:1ex">
At the Monday NETVC session, it was suggested that CBR mode with a fixed<br=
>
buffer size was not a very good representation of what rate control for<br>
video conferencing would do.<br>
<br>
Are there suggestions of a better model? Keep in mind that this is only<br>
for relatively short (~15s) clips.<br>
<br>
Another option is just to not specify CBR bounds, so that this test<br>
would be like the high latency test but with lookahead and 2 pass<br>
constraints.<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" rel=3D"norefe=
rrer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/video-codec</=
a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</span>
</div>

<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" rel=3D"norefe=
rrer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/video-codec</=
a><br>
<br></blockquote></div>

--001a113fc336a5aed8051bcb44dd--

