From nobody Thu Jan 14 13:55:58 2016 Return-Path: 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 3DBF21B2B12 for ; Thu, 14 Jan 2016 13:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 e4QJF_tacPFv for ; Thu, 14 Jan 2016 13:55:56 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2A7C71B2AF5 for ; Thu, 14 Jan 2016 13:55:56 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u0ELtt51063447 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 14 Jan 2016 15:55:55 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "video-codec@ietf.org" From: Adam Roach Message-ID: <5698196A.7000202@nostrum.com> Date: Thu, 14 Jan 2016 15:55:54 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [video-codec] Call for review comments: draft-ietf-netvc-requirements X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 21:55:57 -0000 NETVCers: In Yokohama, we adopted draft-ietf-netvc-requirements as a working group item. The current document has taken into account most of the comments from that meeting. Please take a few moments to read over the current document, looking in particular for requirements that you think may be missing: https://tools.ietf.org/html/draft-ietf-netvc-requirements-00 Thanks! /a From nobody Thu Jan 14 15:03:49 2016 Return-Path: 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 7F8D91A0250 for ; Thu, 14 Jan 2016 15:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 RQlHQ_DgNpzs for ; Thu, 14 Jan 2016 15:03:38 -0800 (PST) Received: from mail-gw1-out.broadcom.com (mail-gw1-out.broadcom.com [216.31.210.62]) by ietfa.amsl.com (Postfix) with ESMTP id 1134D1A0248 for ; Thu, 14 Jan 2016 15:03:37 -0800 (PST) X-IronPort-AV: E=Sophos; i="5.22,296,1449561600"; d="scan'208,217"; a="85656836" Received: from irvexchcas08.broadcom.com (HELO IRVEXCHCAS08.corp.ad.broadcom.com) ([10.9.208.57]) by mail-gw1-out.broadcom.com with ESMTP; 14 Jan 2016 17:43:21 -0800 Received: from IRVEXCHMB15.corp.ad.broadcom.com ([fe80::3c14:d213:d2c9:b75a]) by IRVEXCHCAS08.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Thu, 14 Jan 2016 15:03:35 -0800 From: Minhua Zhou To: Adam Roach , "video-codec@ietf.org" Thread-Topic: [video-codec] Call for review comments: draft-ietf-netvc-requirements Thread-Index: AQHRTxZhtrYkyRjIDUGiTWqI89F4hZ77ljZQ Date: Thu, 14 Jan 2016 23:03:34 +0000 Message-ID: References: <5698196A.7000202@nostrum.com> In-Reply-To: <5698196A.7000202@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.9.208.64] Content-Type: multipart/alternative; boundary="_000_DEA1A92DC8A59E4988D228B2DBD752D6CDA2DCIRVEXCHMB15corpad_" MIME-Version: 1.0 Archived-At: Subject: Re: [video-codec] Call for review comments: draft-ietf-netvc-requirements X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 23:03:45 -0000 --_000_DEA1A92DC8A59E4988D228B2DBD752D6CDA2DCIRVEXCHMB15corpad_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I have few quick comments 1) Table 6. It seems that the parameters there only constrain the maximum pixel rate, w= hich is not sufficient for containing decoder implementation cost. We need = to have additional parameters to restrict decoder on/off chip memory footpr= int and entropy decoding throughput. At least the following parameters are = missing: * Maximum horizontal picture size =3D> impacts line buffer size * Memory size for buffering bitstream and decoded reference picture= s =3D> impacts off-chip memory size * Maximum bit-rate and minimum compression ratio =3D> impacts entro= py decoding throughput requirement for real-time decoding 2) Section 3.1 if YUV 4:4:4 is a basic requirement, there should be no problem for a same = codec to support RGB 4:4:4 color sample format. Therefore, YUV/RGB 4:4:4 sh= ould be put in a same place (either in section 3.1 or in 3.2) 3) HDR (high dynamic range) should belong to section 3.1. 4) WCG (Wide Color Gamut) support is missing, e.g. color space BT.2020= , DCI-P3, BT.709 and OETF (ST.2084, HLG, BT.1886) 5) Section 4.1 since H.265 is taken as reference codec for compression efficiency comparis= on, why not taking JCTVC approach to do subjective quality evaluation, i.e= . using 4 fixed QPs (could be sequence dependent to match the target bit-ra= tes) and computing BD-rate difference at the end? Regards, Minhua -----Original Message----- From: video-codec [mailto:video-codec-bounces@ietf.org] On Behalf Of Adam R= oach Sent: Thursday, January 14, 2016 1:56 PM To: video-codec@ietf.org Subject: [video-codec] Call for review comments: draft-ietf-netvc-requireme= nts NETVCers: In Yokohama, we adopted draft-ietf-netvc-requirements as a working group it= em. The current document has taken into account most of the comments from t= hat meeting. Please take a few moments to read over the current document, looking in par= ticular for requirements that you think may be missing: https://tools.ietf.org/html/draft-ietf-netvc-requirements-00 Thanks! /a _______________________________________________ video-codec mailing list video-codec@ietf.org https://www.ietf.org/mailman/listinfo/video-codec --_000_DEA1A92DC8A59E4988D228B2DBD752D6CDA2DCIRVEXCHMB15corpad_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

I have few quick comments

 

1)      Table 6.

It seems that the para= meters there only constrain the maximum pixel rate, which is not sufficient= for containing decoder implementation cost. We need to have additional par= ameters to restrict decoder on/off chip memory footprint and entropy decoding throughput. At least the following p= arameters are missing:

·         Maximum horizontal picture size  =3D>= ; impacts line buffer size

·         Memory size for buffering bitstream and deco= ded reference pictures  =3D> impacts off-chip memory size

·         Maximum bit-rate and minimum compression rat= io =3D> impacts entropy decoding throughput requirement for real-time de= coding

 

2)      Section 3.1

if YUV 4:4:4 is a basi= c requirement, there should be no problem for a same codec to support RGB 4= :4:4 color sample format. Therefore, YUV/RGB 4:4:4 should be put in a same = place (either in section 3.1 or in  3.2)

 

3)      HDR (high dynamic range) should belong to section 3= .1.

 

4)      WCG (Wide Color Gamut) support is missing, e.g. col= or space BT.2020, DCI-P3, BT.709 and OETF (ST.2084, HLG, BT.1886)

 

5)      Section 4.1

since H.265 is taken a= s reference codec for compression efficiency comparison,  why not taki= ng JCTVC approach to do subjective quality evaluation, i.e. using 4 fixed Q= Ps (could be sequence dependent to match the target bit-rates) and computing BD-rate difference at the end?

 

Regards,

 

Minhua

 

 

-----Original Message-----
From: video-codec [mailto:video-codec-bounces@ietf.org] On Behalf Of Adam R= oach
Sent: Thursday, January 14, 2016 1:56 PM
To: video-codec@ietf.org
Subject: [video-codec] Call for review comments: draft-ietf-netvc-requireme= nts

 

NETVCers:

 

In Yokohama, we adopted draft-ietf-netvc-requirem= ents as a working group item. The current document has taken into account m= ost of the comments from that meeting.

 

Please take a few moments to read over the curren= t document, looking in particular for requirements that you think may be mi= ssing:

https://tools.ietf.org/html/draft-ietf-netvc-requirements-00<= o:p>

 

Thanks!

 

/a

 

_______________________________________________

video-codec mailing list

video-codec@ietf.org

https://= www.ietf.org/mailman/listinfo/video-codec

--_000_DEA1A92DC8A59E4988D228B2DBD752D6CDA2DCIRVEXCHMB15corpad_-- From nobody Fri Jan 15 06:45:41 2016 Return-Path: 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 CF4E61ACE41 for ; Fri, 15 Jan 2016 06:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 NealBAJcbHiH for ; Fri, 15 Jan 2016 06:45:37 -0800 (PST) Received: from mail-ny.cbs.com (mail-ny.cbs.com [170.20.0.120]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A4121ACE39 for ; Fri, 15 Jan 2016 06:45:36 -0800 (PST) Received: from unknown (HELO ED1PWISTMSXHC04.cbs.ad.cbs.net) ([10.149.32.83]) by smtprelay.cbs.com with ESMTP; 15 Jan 2016 09:45:35 -0500 Received: from ED1PWISTMSXMB06.cbs.ad.cbs.net ([169.254.12.25]) by ED1PWISTMSXHC04.cbs.ad.cbs.net ([10.149.32.83]) with mapi id 14.03.0248.002; Fri, 15 Jan 2016 09:45:35 -0500 From: "Coppa, Greg" To: Minhua Zhou , Adam Roach , "video-codec@ietf.org" Thread-Topic: [video-codec] Call for review comments: draft-ietf-netvc-requirements Thread-Index: AQHRTx/uk8oJV+cm+EyCooCWX72tEJ78o/3j Date: Fri, 15 Jan 2016 14:45:35 +0000 Message-ID: <3569E2579E6AF14AAD30C8E74C9F9F887860681F@ED1PWISTMSXMB06.cbs.ad.cbs.net> References: <5698196A.7000202@nostrum.com>, In-Reply-To: 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_3569E2579E6AF14AAD30C8E74C9F9F887860681FED1PWISTMSXMB06_" MIME-Version: 1.0 Archived-At: Subject: Re: [video-codec] Call for review comments: draft-ietf-netvc-requirements X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 14:45:40 -0000 --_000_3569E2579E6AF14AAD30C8E74C9F9F887860681FED1PWISTMSXMB06_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All - A comment regarding frame rate - I note that all frame rates in this docume= nt are integer. I suggest that fractional frame rates be added particularly= the more popular ones. CBS is a provider of many hours of content to the syndication market (OTT/V= OD, US and International) I note that we are often required (contractually)= to deliver this content in its native frame rate. The native frame rate o= f most of this content (e.g Star Trek, Frasier, etc.) is 23.976 fps. greg ________________________________ From: video-codec [video-codec-bounces@ietf.org] on behalf of Minhua Zhou [= minhua@broadcom.com] Sent: Thursday, January 14, 2016 6:03 PM To: Adam Roach; video-codec@ietf.org Subject: Re: [video-codec] Call for review comments: draft-ietf-netvc-requi= rements Dear all, I have few quick comments 1) Table 6. It seems that the parameters there only constrain the maximum pixel rate, w= hich is not sufficient for containing decoder implementation cost. We need = to have additional parameters to restrict decoder on/off chip memory footpr= int and entropy decoding throughput. At least the following parameters are = missing: =B7 Maximum horizontal picture size =3D> impacts line buffer size =B7 Memory size for buffering bitstream and decoded reference pictu= res =3D> impacts off-chip memory size =B7 Maximum bit-rate and minimum compression ratio =3D> impacts ent= ropy decoding throughput requirement for real-time decoding 2) Section 3.1 if YUV 4:4:4 is a basic requirement, there should be no problem for a same = codec to support RGB 4:4:4 color sample format. Therefore, YUV/RGB 4:4:4 sh= ould be put in a same place (either in section 3.1 or in 3.2) 3) HDR (high dynamic range) should belong to section 3.1. 4) WCG (Wide Color Gamut) support is missing, e.g. color space BT.2020= , DCI-P3, BT.709 and OETF (ST.2084, HLG, BT.1886) 5) Section 4.1 since H.265 is taken as reference codec for compression efficiency comparis= on, why not taking JCTVC approach to do subjective quality evaluation, i.e= . using 4 fixed QPs (could be sequence dependent to match the target bit-ra= tes) and computing BD-rate difference at the end? Regards, Minhua -----Original Message----- From: video-codec [mailto:video-codec-bounces@ietf.org] On Behalf Of Adam R= oach Sent: Thursday, January 14, 2016 1:56 PM To: video-codec@ietf.org Subject: [video-codec] Call for review comments: draft-ietf-netvc-requireme= nts NETVCers: In Yokohama, we adopted draft-ietf-netvc-requirements as a working group it= em. The current document has taken into account most of the comments from t= hat meeting. Please take a few moments to read over the current document, looking in par= ticular for requirements that you think may be missing: https://tools.ietf.org/html/draft-ietf-netvc-requirements-00 Thanks! /a _______________________________________________ video-codec mailing list video-codec@ietf.org https://www.ietf.org/mailman/listinfo/video-codec --_000_3569E2579E6AF14AAD30C8E74C9F9F887860681FED1PWISTMSXMB06_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear All - 

A comment regarding frame rate - I note that all frame rates in this d= ocument are integer. I suggest that fractional frame rates be added particu= larly the more popular ones. 

CBS is a provider of many hours of content to the syndication market (= OTT/VOD, US and International) I note that we are often required (contractu= ally) to deliver this content in its native frame rate.  The native fr= ame rate of most of this content (e.g Star Trek, Frasier, etc.) is 23.976 fps.

greg

From: video-codec [video-codec-bounces@ietf= .org] on behalf of Minhua Zhou [minhua@broadcom.com]
Sent: Thursday, January 14, 2016 6:03 PM
To: Adam Roach; video-codec@ietf.org
Subject: Re: [video-codec] Call for review comments: draft-ietf-netv= c-requirements

Dear all,

 

I have few quick comments

 

1)&nb= sp;     Table 6.

It seems that the para= meters there only constrain the maximum pixel rate, which is not sufficient= for containing decoder implementation cost. We need to have additional par= ameters to restrict decoder on/off chip memory footprint and entropy decoding throughput. At least the following p= arameters are missing:

= =B7      &nbs= p;  Maximum horizontal picture size  =3D> impacts = line buffer size

= =B7      &nbs= p;  Memory size for buffering bitstream and decoded refere= nce pictures  =3D> impacts off-chip memory size

= =B7      &nbs= p;  Maximum bit-rate and minimum compression ratio =3D>= impacts entropy decoding throughput requirement for real-time decoding

 

2)&nb= sp;     Section 3.1

if YUV 4:4:4 is a basi= c requirement, there should be no problem for a same codec to support RGB 4= :4:4 color sample format. Therefore, YUV/RGB 4:4:4 should be put in a same = place (either in section 3.1 or in  3.2)

 

3)&nb= sp;     HDR (high dynamic range) should belong to section 3.1.

 

4)&nb= sp;     WCG (Wide Color Gamut) support is missing, e.g. color space B= T.2020, DCI-P3, BT.709 and OETF (ST.2084, HLG, BT.1886)

 

5)&nb= sp;     Section 4.1

since H.265 is taken a= s reference codec for compression efficiency comparison,  why not taki= ng JCTVC approach to do subjective quality evaluation, i.e. using 4 fixed Q= Ps (could be sequence dependent to match the target bit-rates) and computing BD-rate difference at the end?

 

Regards,

 

Minhua

 

 

-----Original Message-----
From: video-codec [mailto:video-codec-bounces@ietf.org] On Behalf Of Adam R= oach
Sent: Thursday, January 14, 2016 1:56 PM
To: video-codec@ietf.org
Subject: [video-codec] Call for review comments: draft-ietf-netvc-requireme= nts

 

NETVCers:

 

In Yokohama, we adopted draft-ietf-netvc-requirem= ents as a working group item. The current document has taken into account m= ost of the comments from that meeting.

 

Please take a few moments to read over the curren= t document, looking in particular for requirements that you think may be mi= ssing:

https://tools.ietf.org/html/draft-ietf-netvc-requirem= ents-00

 

Thanks!

 

/a

 

_______________________________________________

video-codec mailing list

video-codec= @ietf.org

https://www.ietf.org/mailman/listinfo/video-codec

--_000_3569E2579E6AF14AAD30C8E74C9F9F887860681FED1PWISTMSXMB06_-- From nobody Fri Jan 15 07:13:31 2016 Return-Path: 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 785691B2F17 for ; Fri, 15 Jan 2016 07:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 0A444puN-ZPK for ; Fri, 15 Jan 2016 07:13:27 -0800 (PST) Received: from espn4.mailsec3.batblue.net (espn4.mailsec3.batblue.net [74.123.203.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42AA81B2ECE for ; Fri, 15 Jan 2016 07:13:27 -0800 (PST) Received: from EXHUBP383C01V.corp.espn.pvt ([192.234.2.236]) by espn4.mailsec3.batblue.net (8.13.8/8.13.8) with ESMTP id u0FFDM3H026800; Fri, 15 Jan 2016 10:13:22 -0500 Received: from EXMDAGP11C01VC6.corp.espn.pvt ([169.254.6.61]) by EXHUBP383C01V.corp.espn.pvt ([10.75.64.227]) with mapi id 14.03.0210.002; Fri, 15 Jan 2016 10:13:22 -0500 From: "Krupiczka, Andrew" To: "Coppa, Greg" , Minhua Zhou , "Adam Roach" , "video-codec@ietf.org" Thread-Topic: [video-codec] Call for review comments: draft-ietf-netvc-requirements Thread-Index: AQHRTx/WNsOgizXaa0WzYsP7UAFt6p78/FqA//+x32A= Date: Fri, 15 Jan 2016 15:13:21 +0000 Message-ID: <7E78635F75F78C41ADC5ADAAD65831932BA6DB72@EXMDAGP11C01VC6.corp.espn.pvt> References: <5698196A.7000202@nostrum.com>, <3569E2579E6AF14AAD30C8E74C9F9F887860681F@ED1PWISTMSXMB06.cbs.ad.cbs.net> In-Reply-To: <3569E2579E6AF14AAD30C8E74C9F9F887860681F@ED1PWISTMSXMB06.cbs.ad.cbs.net> 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: multipart/alternative; boundary="_000_7E78635F75F78C41ADC5ADAAD65831932BA6DB72EXMDAGP11C01VC6_" MIME-Version: 1.0 Archived-At: Subject: Re: [video-codec] Call for review comments: draft-ietf-netvc-requirements X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 15:13:29 -0000 --_000_7E78635F75F78C41ADC5ADAAD65831932BA6DB72EXMDAGP11C01VC6_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good morning, Yes, concurring with Greg to include support for fractional frame rates. As for ESPN our current default frame-rate is 59.94fps and also using 29.97= fps for the OTT. Kind regards, Andrew Krupiczka From: video-codec [mailto:video-codec-bounces@ietf.org] On Behalf Of Coppa,= Greg Sent: Friday, January 15, 2016 9:46 AM To: Minhua Zhou; Adam Roach; video-codec@ietf.org Subject: Re: [video-codec] Call for review comments: draft-ietf-netvc-requi= rements Dear All - A comment regarding frame rate - I note that all frame rates in this docume= nt are integer. I suggest that fractional frame rates be added particularly= the more popular ones. CBS is a provider of many hours of content to the syndication market (OTT/V= OD, US and International) I note that we are often required (contractually)= to deliver this content in its native frame rate. The native frame rate o= f most of this content (e.g Star Trek, Frasier, etc.) is 23.976 fps. greg ________________________________ From: video-codec [video-codec-bounces@ietf.org] on behalf of Minhua Zhou [= minhua@broadcom.com] Sent: Thursday, January 14, 2016 6:03 PM To: Adam Roach; video-codec@ietf.org Subject: Re: [video-codec] Call for review comments: draft-ietf-netvc-requi= rements Dear all, I have few quick comments 1) Table 6. It seems that the parameters there only constrain the maximum pixel rate, w= hich is not sufficient for containing decoder implementation cost. We need = to have additional parameters to restrict decoder on/off chip memory footpr= int and entropy decoding throughput. At least the following parameters are = missing: * Maximum horizontal picture size =3D> impacts line buffer size * Memory size for buffering bitstream and decoded reference picture= s =3D> impacts off-chip memory size * Maximum bit-rate and minimum compression ratio =3D> impacts entro= py decoding throughput requirement for real-time decoding 2) Section 3.1 if YUV 4:4:4 is a basic requirement, there should be no problem for a same = codec to support RGB 4:4:4 color sample format. Therefore, YUV/RGB 4:4:4 sh= ould be put in a same place (either in section 3.1 or in 3.2) 3) HDR (high dynamic range) should belong to section 3.1. 4) WCG (Wide Color Gamut) support is missing, e.g. color space BT.2020= , DCI-P3, BT.709 and OETF (ST.2084, HLG, BT.1886) 5) Section 4.1 since H.265 is taken as reference codec for compression efficiency comparis= on, why not taking JCTVC approach to do subjective quality evaluation, i.e= . using 4 fixed QPs (could be sequence dependent to match the target bit-ra= tes) and computing BD-rate difference at the end? Regards, Minhua -----Original Message----- From: video-codec [mailto:video-codec-bounces@ietf.org] On Behalf Of Adam R= oach Sent: Thursday, January 14, 2016 1:56 PM To: video-codec@ietf.org Subject: [video-codec] Call for review comments: draft-ietf-netvc-requireme= nts NETVCers: In Yokohama, we adopted draft-ietf-netvc-requirements as a working group it= em. The current document has taken into account most of the comments from t= hat meeting. Please take a few moments to read over the current document, looking in par= ticular for requirements that you think may be missing: https://tools.ietf.org/html/draft-ietf-netvc-requirements-00 Thanks! /a _______________________________________________ video-codec mailing list video-codec@ietf.org https://www.ietf.org/mailman/listinfo/video-codec --_000_7E78635F75F78C41ADC5ADAAD65831932BA6DB72EXMDAGP11C01VC6_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Good morning,

 

Yes, concurring with G= reg to include support for fractional frame rates.

As for ESPN our curren= t default frame-rate is 59.94fps and also using 29.97fps for the OTT.<= /o:p>

Kind regards,

 

Andrew Krupiczka<= /o:p>

 

From: video-co= dec [mailto:video-codec-bounces@ietf.org] On Behalf Of Coppa, Greg
Sent: Friday, January 15, 2016 9:46 AM
To: Minhua Zhou; Adam Roach; video-codec@ietf.org
Subject: Re: [video-codec] Call for review comments: draft-ietf-netv= c-requirements

 

Dear All - 

 

A comment regarding frame ra= te - I note that all frame rates in this document are integer. I suggest th= at fractional frame rates be added particularly the more popular ones. 

 

CBS is a provider of many ho= urs of content to the syndication market (OTT/VOD, US and International) I = note that we are often required (contractually) to deliver this content in its native frame rate.  The native frame rate of most= of this content (e.g Star Trek, Frasier, etc.) is 23.976 fps.

 

greg

 

From: video-codec [video-codec-bou= nces@ietf.org] on behalf of Minhua Zhou [minhua@broadcom.com]
Sent: Thursday, January 14, 2016 6:03 PM
To: Adam Roach; video-codec@= ietf.org
Subject: Re: [video-codec] Call for review comments: draft-ietf-netv= c-requirements

Dear all,<= /span>

 

I have few quick comm= ents

 

1)  &n= bsp;   Table 6.

It seems that the parameters there only constrain the maximum pixel r= ate, which is not sufficient for containing decoder implementation cost. We= need to have additional parameters to restrict decoder on/off chip memory footprint and entropy decoding through= put. At least the following parameters are missing:

<= span style=3D"font-family:Symbol;color:black">·         Maximum horizontal picture size  = =3D> impacts line buffer size

<= span style=3D"font-family:Symbol;color:black">·         Memory size for buffering bitstream and = decoded reference pictures  =3D> impacts off-chip memory size

<= span style=3D"font-family:Symbol;color:black">·         Maximum bit-rate and minimum compression= ratio =3D> impacts entropy decoding throughput requirement for real-tim= e decoding

 

2)  &n= bsp;   Section 3.1

if YUV 4:4:4 is a basic requirement, there should be no problem for a= same codec to support RGB 4:4:4 color sample format. Therefore, YUV/RGB 4:= 4:4 should be put in a same place (either in section 3.1 or in  3.2)

 

3)  &n= bsp;   HDR (high dynamic range) should belong t= o section 3.1.

 

4)  &n= bsp;   WCG (Wide Color Gamut) support is missin= g, e.g. color space BT.2020, DCI-P3, BT.709 and OETF (ST.2084, HLG, BT.1886= )

 

5)  &n= bsp;   Section 4.1

since H.265 is taken as reference codec for compression efficiency co= mparison,  why not taking JCTVC approach to do subjective quality eval= uation, i.e. using 4 fixed QPs (could be sequence dependent to match the target bit-rates) and computing BD-rate difference = at the end?

 

Regards,

 

Minhua

 

 

-----Original Message= -----
From: video-codec [mailto:v= ideo-codec-bounces@ietf.org] On Behalf Of Adam Roach
Sent: Thursday, January 14, 2016 1:56 PM
To: video-codec@ietf.org
Subject: [video-codec] Call for review comments: draft-ietf-netvc-requireme= nts

 

NETVCers:<= /span>

 

In Yokohama, we adopt= ed draft-ietf-netvc-requirements as a working group item. The current docum= ent has taken into account most of the comments from that meeting.

 

Please take a few mom= ents to read over the current document, looking in particular for requireme= nts that you think may be missing:

https://tools.ietf.org/htm= l/draft-ietf-netvc-requirements-00

 

Thanks!

 

/a<= /p>

 

_____________________= __________________________

video-codec mailing l= ist

video-codec@ietf.org

https://www.ietf.org/mailman/listinfo= /video-codec

--_000_7E78635F75F78C41ADC5ADAAD65831932BA6DB72EXMDAGP11C01VC6_-- From nobody Wed Jan 27 01:30:17 2016 Return-Path: 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 3CB021B378A for ; Wed, 27 Jan 2016 01:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 G92GbOAkDca2 for ; Wed, 27 Jan 2016 01:30:14 -0800 (PST) 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 154661B3789 for ; Wed, 27 Jan 2016 01:30:12 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDN02266; Wed, 27 Jan 2016 09:30:10 +0000 (GMT) Received: from LHREML701-CAH.china.huawei.com (10.201.5.93) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 27 Jan 2016 09:30:09 +0000 Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 27 Jan 2016 09:30:09 +0000 Received: from SZXEMA508-MBS.china.huawei.com ([169.254.8.64]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Wed, 27 Jan 2016 17:29:48 +0800 From: Filippov Alexey To: "video-codec@ietf.org" , "Andrew.Krupiczka@espn.com" , "gmcoppa@cbs.com" Thread-Topic: Re: Re: [video-codec] Call for review comments: draft-ietf-netvc-requirements Thread-Index: AdFY5UJ5MdM2y98GT4KF4+R1fOIiyA== Date: Wed, 27 Jan 2016 09:29:48 +0000 Message-ID: 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_A95DB243D3936149BBFA3B43ED710745705D1D53szxema508mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.56A88E23.003A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.64, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1a7265074ecee3f43a0ec6e4181a491a Archived-At: Cc: "minhua@broadcom.com" , Adam Roach , Jose Alvarez , Zhoujiantong Subject: Re: [video-codec] Call for review comments: draft-ietf-netvc-requirements X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 09:30:16 -0000 --_000_A95DB243D3936149BBFA3B43ED710745705D1D53szxema508mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Mr. Coppa, dear Mr. Krupiczka, Thank you for your valuable comments! Is my understanding correct that you = want to keep fractional frame-rates just for IPTV/OTT/VoD applications? Cou= ld you please specify a set of such fractional frame-rates that you would l= ike to include into draft-ietf-netvc-requirements? Thank you in advance! -- Best regards, Alexey Filippov --_000_A95DB243D3936149BBFA3B43ED710745705D1D53szxema508mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Mr. Coppa, dear Mr. Krupiczka,

 

Thank you for your valuable comments! Is my understa= nding correct that you want to keep fractional frame-rates just for IPTV/OT= T/VoD applications? Could you please specify a set of such fractional frame= -rates that you would like to include into draft-ietf-netvc-requirements?

 

Thank you in advance!

 

--

Best regards,

Alexey Filippov

--_000_A95DB243D3936149BBFA3B43ED710745705D1D53szxema508mbschi_-- From nobody Wed Jan 27 05:33:14 2016 Return-Path: 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 D46BB1B2DBD for ; Wed, 27 Jan 2016 05:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 dQNkAIMYnATn for ; Wed, 27 Jan 2016 05:33:08 -0800 (PST) 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 535A01B2DBA for ; Wed, 27 Jan 2016 05:33:07 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDN33714; Wed, 27 Jan 2016 13:33:04 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 27 Jan 2016 13:33:01 +0000 Received: from SZXEMA508-MBS.china.huawei.com ([169.254.8.64]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Wed, 27 Jan 2016 21:32:51 +0800 From: Filippov Alexey To: "video-codec@ietf.org" , "minhua@broadcom.com" Thread-Topic: Re: Re: [video-codec] Call for review comments: draft-ietf-netvc-requirements Thread-Index: AdFZBzZZtFf7Lms8SReflFRR19aVMQ== Date: Wed, 27 Jan 2016 13:32:50 +0000 Message-ID: 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_A95DB243D3936149BBFA3B43ED710745705D1F6Bszxema508mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.56A8C710.010D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.64, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1a7265074ecee3f43a0ec6e4181a491a Archived-At: Cc: Adam Roach , Jose Alvarez , Zhoujiantong Subject: Re: [video-codec] Call for review comments: draft-ietf-netvc-requirements X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 13:33:13 -0000 --_000_A95DB243D3936149BBFA3B43ED710745705D1F6Bszxema508mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Mr. Zhou, Thank you so much for your analysis of draft-ietf-netvc-requirements and yo= ur valuable comments! I'd like to put my 2 cents in: 1) Table 6. It seems that the parameters there only constrain the maximum pixel rate, w= hich is not sufficient for containing decoder implementation cost. We need = to have additional parameters to restrict decoder on/off chip memory footpr= int and entropy decoding throughput. At least the following parameters are = missing: * Maximum horizontal picture size =3D> impacts line buffer size * Memory size for buffering bitstream and decoded reference picture= s =3D> impacts off-chip memory size * Maximum bit-rate and minimum compression ratio =3D> impacts entro= py decoding throughput requirement for real-time decoding [AF]: Yes, I fully agree that it should be included into table 6. However, = it's hard to do it right now as we currently don't have the detailed inform= ation on final codec architecture (e.g., we can't say how many pictures sho= uld be kept in the buffer) and its compression performance (maximum bit-rat= e and minimum compression ratios will evidently depend on the codec's actua= l compression performance). I guess we should keep this comment in mind and= add the mentioned information into table 6 when available. In other words,= I guess profiles and levels can be more clearly defined when the final cod= ec architecture is better defined. 2) Section 3.1 if YUV 4:4:4 is a basic requirement, there should be no problem for a same = codec to support RGB 4:4:4 color sample format. Therefore, YUV/RGB 4:4:4 sh= ould be put in a same place (either in section 3.1 or in 3.2) [AF]: Yes, there should be no problem for a same codec to support RGB 4:4:4= color sample format like it is done in the HEVC RExt profile. But direct c= oding of RGB source material can adversely affect the coding gain in compar= ison with YUV case. So, RGB 4:4:4 support was considered as an optional re= quirement. 3) HDR (high dynamic range) should belong to section 3.1. 4) WCG (Wide Color Gamut) support is missing, e.g. color space BT.2020= , DCI-P3, BT.709 and OETF (ST.2084, HLG, BT.1886) [AF]: In my opinion, these two comments are a very good point. I guess they= should be discussed together with levels and profiles to avoid encumbered = implementations. 5) Section 4.1 since H.265 is taken as reference codec for compression efficiency comparis= on, why not taking JCTVC approach to do subjective quality evaluation, i.e= . using 4 fixed QPs (could be sequence dependent to match the target bit-ra= tes) and computing BD-rate difference at the end? [AF]: You probably meant objective (not subjective) quality evaluation. Now= , it is proposed to evaluate objective performance in 3 ranges (for low, mi= ddle and high bit-rates). In the current version of the draft, the ranges a= re non-overlapped and each of them include 4 bit-rates that should be speci= fied in the test draft. Hence, the simulation should be performed for 12 bi= t-rates. Is the high amount of calculations your concern? If so, it is poss= ible to keep 3 ranges but they can be overlapped as it was done in draft-fi= lippov-netvc-requirements-01 (page 10). Anyway, I guess it's reasonable to = separately evaluate the coding gain for low, middle and high bit-rates to k= now in what bit-rate range a codec as a whole or its separate coding tools = are more efficient. In addition, I'd like to emphasize that both Daala and Thor have different = QP ranges and we cannot simply map Daala's QP range into Thor's QP range an= d vice versa as this mapping is content dependent as you mentioned in your = comment. I performed such experiments and tried to carry out such a mapping= for Daala and HEVC but this attempt failed because the correspondence betw= een Daala and HEVC QPs differs for different sequences. I assume that a sim= ilar situation will be observed if we compare Daala and Thor. If your conce= rn is that different codecs will use different rate-control mechanisms that= can impact the overall performance of candidate codecs, I agree that only = QP adjustment (but not rate-control) should be used to match the target bit= -rates. -- Best regards, Alexey Filippov --_000_A95DB243D3936149BBFA3B43ED710745705D1F6Bszxema508mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Mr. Zhou,

 

Thank you so much for your analysis of draft-ietf-ne= tvc-requirements and your valuable comments!

I’d like to put my 2 cents in:

 

1)      Table 6.

It seems that the para= meters there only constrain the maximum pixel rate, which is not sufficient= for containing decoder implementation cost. We need to have additional par= ameters to restrict decoder on/off chip memory footprint and entropy decoding throughput. At least the following p= arameters are missing:

·         Maximum horizontal picture size  =3D>= ; impacts line buffer size

·         Memory size for buffering bitstream and deco= ded reference pictures  =3D> impacts off-chip memory size

·         Maximum bit-rate and minimum compression rat= io =3D> impacts entropy decoding throughput requirement for real-time de= coding

 

[AF]: Yes, I fully agree that it should be included = into table 6. However, it’s hard to do it right now as we currently d= on’t have the detailed information on final codec architecture (e.g.,= we can’t say how many pictures should be kept in the buffer) and its compression performance (maximum bit-rate and minim= um compression ratios will evidently depend on the codec’s actual com= pression performance). I guess we should keep this comment in mind and add = the mentioned information into table 6 when available. In other words, I guess profiles and levels can be more cl= early defined when the final codec architecture is better defined.

 

2)      Section 3.1

if YUV 4:4:4 is a basi= c requirement, there should be no problem for a same codec to support RGB 4= :4:4 color sample format. Therefore, YUV/RGB 4:4:4 should be put in a same = place (either in section 3.1 or in  3.2)

 

[AF]: Yes, there should be no problem for a same cod= ec to support RGB 4:4:4 color sample format like it is done in the HEVC REx= t profile. But direct coding of RGB source material can adversely affect th= e coding gain in comparison with YUV case. So, RGB 4:4:4  support was considered as an optional requiremen= t.

 

3)      HDR (high dynamic range) should belong to section 3= .1.

4)      WCG (Wide Color Gamut) support is missing, e.g. col= or space BT.2020, DCI-P3, BT.709 and OETF (ST.2084, HLG, BT.1886)

 

[AF]: In my opinion, these two comments are a very g= ood point. I guess they should be discussed together with levels and profil= es to avoid encumbered implementations.

 

5)      Section 4.1

since H.265 is taken as reference codec for c= ompression efficiency comparison,  why not taking JCTVC approach to do= subjective quality evaluation, i.e. using 4 fixed QPs (could be sequence d= ependent to match the target bit-rates) and computing BD-rate difference at the end?

 

[AF]: You probably meant objective (not subjective) = quality evaluation. Now, it is proposed to evaluate objective performance i= n 3 ranges (for low, middle and high bit-rates). In the current version of = the draft, the ranges are non-overlapped and each of them include 4 bit-rates that should be specified in the test = draft. Hence, the simulation should be performed for 12 bit-rates. Is the h= igh amount of calculations your concern? If so, it is possible to keep 3 ra= nges but they can be overlapped as it was done in draft-filippov-netvc-requirements-01 (page 10). Anyway, = I guess it’s reasonable to separately evaluate the coding gain for lo= w, middle and high bit-rates to know in what bit-rate range a codec as a wh= ole or its separate coding tools are more efficient.

In addition, I’d like to emphasize that both D= aala and Thor have different QP ranges and we cannot simply map Daala’= ;s QP range into Thor’s QP range and vice versa as this mapping is co= ntent dependent as you mentioned in your comment. I performed such experiments and tried to carry out such a mapping for Daala= and HEVC but this attempt failed because the correspondence between Daala = and HEVC QPs differs for different sequences. I assume that a similar situa= tion will be observed if we compare Daala and Thor. If your concern is that different codecs will use differen= t rate-control mechanisms that can impact the overall performance of candid= ate codecs, I agree that only QP adjustment (but not rate-control) should b= e used to match the target bit-rates.

 

--

Best regards,

Alexey Filippov

--_000_A95DB243D3936149BBFA3B43ED710745705D1F6Bszxema508mbschi_-- From nobody Wed Jan 27 07:25:17 2016 Return-Path: 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 BBB381B3845 for ; Wed, 27 Jan 2016 07:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 kHqnzfcn3-zL for ; Wed, 27 Jan 2016 07:25:14 -0800 (PST) Received: from espn2.mailsec1.batblue.net (espn2.mailsec1.batblue.net [74.123.200.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BE4C1B383C for ; Wed, 27 Jan 2016 07:25:13 -0800 (PST) Received: from EXHUBP383C01V.corp.espn.pvt ([192.234.2.236]) by espn2.mailsec1.batblue.net (8.13.8/8.13.8) with ESMTP id u0RFOrna017898; Wed, 27 Jan 2016 10:24:54 -0500 Received: from EXMDAGP11C01VC6.corp.espn.pvt ([169.254.6.61]) by EXHUBP383C01V.corp.espn.pvt ([10.75.64.227]) with mapi id 14.03.0210.002; Wed, 27 Jan 2016 10:24:53 -0500 From: "Krupiczka, Andrew" To: Filippov Alexey , "video-codec@ietf.org" , "gmcoppa@cbs.com" Thread-Topic: Re: [video-codec] Call for review comments: draft-ietf-netvc-requirements Thread-Index: AdFY5UJ5MdM2y98GT4KF4+R1fOIiyAALw5mg Date: Wed, 27 Jan 2016 15:24:53 +0000 Message-ID: <7E78635F75F78C41ADC5ADAAD65831932BA6F693@EXMDAGP11C01VC6.corp.espn.pvt> References: In-Reply-To: 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: multipart/alternative; boundary="_000_7E78635F75F78C41ADC5ADAAD65831932BA6F693EXMDAGP11C01VC6_" MIME-Version: 1.0 Archived-At: Cc: "minhua@broadcom.com" , Adam Roach , Jose Alvarez , Zhoujiantong Subject: Re: [video-codec] Call for review comments: draft-ietf-netvc-requirements X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 15:25:16 -0000 --_000_7E78635F75F78C41ADC5ADAAD65831932BA6F693EXMDAGP11C01VC6_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Alexey, >From our current (but also mid-term future perspective) referring to the Ta= ble 2 in BT.2020-2 (see https://www.itu.int/rec/R-REC-BT.2020-2-201510-I/en= ) would be more than sufficient. Certainly due to associated complexity, for now we may want to limit the fr= ame rates requirement above 60fps to be only supported let's say for up to = 1080p resolution, since we're already listing: | 2160p (4K),3840x2160 | 24, 25, 30, 48, 50, 60 | RA | and the codec levels in the Table 6 already much higher than that? Alternatively, any frame-rate higher than 60fps could be placed into the se= ction 3.2.1 as an optional requirement. Best regards, Andrew From: Filippov Alexey [mailto:Alexey.Filippov@huawei.com] Sent: Wednesday, January 27, 2016 4:30 AM To: video-codec@ietf.org; Krupiczka, Andrew; gmcoppa@cbs.com Cc: minhua@broadcom.com; Adam Roach; Zhoujiantong; Jose Alvarez Subject: Re: Re: [video-codec] Call for review comments: draft-ietf-netvc-r= equirements Dear Mr. Coppa, dear Mr. Krupiczka, Thank you for your valuable comments! Is my understanding correct that you = want to keep fractional frame-rates just for IPTV/OTT/VoD applications? Cou= ld you please specify a set of such fractional frame-rates that you would l= ike to include into draft-ietf-netvc-requirements? Thank you in advance! -- Best regards, Alexey Filippov --_000_7E78635F75F78C41ADC5ADAAD65831932BA6F693EXMDAGP11C01VC6_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Dear Alexey,

 

From our current (but = also mid-term future perspective) referring to the Table 2 in BT.2020-2 (se= e https://www= .itu.int/rec/R-REC-BT.2020-2-201510-I/en ) would be more than sufficien= t.

Certainly due to assoc= iated complexity, for now we may want to limit the frame rates requirement = above 60fps to be only supported let’s say for up to 1080p resolution= , since we’re already listing:

 

| 2160p (4K),3840x2160 |  24, 25, 30, 48, 50, 60 |&nb= sp;      RA       |<= o:p>

 

and the codec levels i= n the Table 6 already much higher than that?

 

Alternatively, any fra= me-rate higher than 60fps could be placed into the section 3.2.1 as an opti= onal requirement.

 

Best regards,

 

Andrew

 

 

From: Filippov= Alexey [mailto:Alexey.Filippov@huawei.com]
Sent: Wednesday, January 27, 2016 4:30 AM
To: video-codec@ietf.org; Krupiczka, Andrew; gmcoppa@cbs.com
Cc: minhua@broadcom.com; Adam Roach; Zhoujiantong; Jose Alvarez
Subject: Re: Re: [video-codec] Call for review comments: draft-ietf-= netvc-requirements

 

Dear Mr. Coppa, dear Mr. Krupiczka,

 

Thank you for your valuable comments! Is my understa= nding correct that you want to keep fractional frame-rates just for IPTV/OT= T/VoD applications? Could you please specify a set of such fractional frame= -rates that you would like to include into draft-ietf-netvc-requirements?

 

Thank you in advance!

 

--

Best regards,

Alexey Filippov

--_000_7E78635F75F78C41ADC5ADAAD65831932BA6F693EXMDAGP11C01VC6_-- From nobody Thu Jan 28 09:31:55 2016 Return-Path: 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 41BD71A8AF4 for ; Thu, 28 Jan 2016 09:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 VizYcg6Vgids for ; Thu, 28 Jan 2016 09:31:51 -0800 (PST) Received: from mail-ny.cbs.com (mail-ny.cbs.com [170.20.0.120]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3D7D1A8AEC for ; Thu, 28 Jan 2016 09:31:50 -0800 (PST) Received: from unknown (HELO ED1PWISTMSXHC03.cbs.ad.cbs.net) ([10.149.32.82]) by smtprelay.cbs.com with ESMTP; 28 Jan 2016 12:31:07 -0500 Received: from ED1PWISTMSXMB06.cbs.ad.cbs.net ([169.254.12.109]) by ED1PWISTMSXHC03.cbs.ad.cbs.net ([10.149.32.82]) with mapi id 14.03.0248.002; Thu, 28 Jan 2016 12:31:07 -0500 From: "Coppa, Greg" To: "Krupiczka, Andrew" , Filippov Alexey , "video-codec@ietf.org" Thread-Topic: [video-codec] Call for review comments: draft-ietf-netvc-requirements Thread-Index: AQHRWfGqMdM2y98GT4KF4+R1fOIiyA== Date: Thu, 28 Jan 2016 17:31:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-originating-ip: [170.20.72.85] Content-Type: multipart/alternative; boundary="_000_D2CFB788297CAgmcoppacbscom_" MIME-Version: 1.0 Archived-At: Cc: "minhua@broadcom.com" , Adam Roach , Jose Alvarez , Zhoujiantong Subject: Re: [video-codec] Call for review comments: draft-ietf-netvc-requirements X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 17:31:53 -0000 --_000_D2CFB788297CAgmcoppacbscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear Alexey - I agree with Andrew that the frame rates referenced in BT.2020 Table 2 are = representative of the fractional frame rates in use and should be included = into the draft-ietf-netvc-requirements. Best regards, greg From: "Krupiczka, Andrew" > Date: Wednesday, January 27, 2016 10:24 AM To: Filippov Alexey >, "video-codec@ietf.org" >, greg coppa > Cc: "minhua@broadcom.com" >, Adam Roach >, Zhoujiantong >, Jose Alvarez > Subject: RE: Re: [video-codec] Call for review comments: draft-ietf-netvc-r= equirements Dear Alexey, >From our current (but also mid-term future perspective) referring to the Ta= ble 2 in BT.2020-2 (see https://www.itu.int/rec/R-REC-BT.2020-2-201510-I/en= ) would be more than sufficient. Certainly due to associated complexity, for now we may want to limit the fr= ame rates requirement above 60fps to be only supported let=92s say for up t= o 1080p resolution, since we=92re already listing: | 2160p (4K),3840x2160 | 24, 25, 30, 48, 50, 60 | RA | and the codec levels in the Table 6 already much higher than that? Alternatively, any frame-rate higher than 60fps could be placed into the se= ction 3.2.1 as an optional requirement. Best regards, Andrew From: Filippov Alexey [mailto:Alexey.Filippov@huawei.com] Sent: Wednesday, January 27, 2016 4:30 AM To: video-codec@ietf.org; Krupiczka, Andrew; g= mcoppa@cbs.com Cc: minhua@broadcom.com; Adam Roach; Zhoujianto= ng; Jose Alvarez Subject: Re: Re: [video-codec] Call for review comments: draft-ietf-netvc-r= equirements Dear Mr. Coppa, dear Mr. Krupiczka, Thank you for your valuable comments! Is my understanding correct that you = want to keep fractional frame-rates just for IPTV/OTT/VoD applications? Cou= ld you please specify a set of such fractional frame-rates that you would l= ike to include into draft-ietf-netvc-requirements? Thank you in advance! -- Best regards, Alexey Filippov --_000_D2CFB788297CAgmcoppacbscom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Dear Alexey -

I agree w= ith Andrew that the frame rates referenced in BT.2020 Table 2 are represent= ative of the fractional frame rates in use and should be included into= the draft-ietf-netvc-requirements.

Best rega= rds,

greg




From: "Krupiczka, Andrew"= <Andrew.Krupiczka@espn.com= >
Date: Wednesday, January 27, 2016 1= 0:24 AM
To: Filippov Alexey <Alexey.Filippov@huawei.com>, &quo= t;video-codec@ietf.org" &l= t;video-codec@ietf.org>, greg coppa <gmcoppa@cbs.com><= br> Cc: "minhua@broadcom.com" <minhua@broadcom.com>, Adam Roach <adam@nostrum.com>, Zhoujiantong <zhoujiantong@huawei.com>, Jose Alvarez <jose.r= oberto.alvarez@huawei.com>
Subject: RE: Re: [video-codec] Call= for review comments: draft-ietf-netvc-requirements

 

Dear Alexey,

 

From our current (but = also mid-term future perspective) referring to the Table 2 in BT.2020-2 (se= e https://www= .itu.int/rec/R-REC-BT.2020-2-201510-I/en ) would be more than sufficien= t.

Certainly due to assoc= iated complexity, for now we may want to limit the frame rates requirement = above 60fps to be only supported let=92s say for up to 1080p resolution, si= nce we=92re already listing:

 

| 2160p (4K),3840x2160 |  24, 25, 30, 48, 50, 60 | &nbs= p;     RA       |

 

and the codec levels i= n the Table 6 already much higher than that?

 

Alternatively, any fra= me-rate higher than 60fps could be placed into the section 3.2.1 as an opti= onal requirement.

 

Best regards,

 

Andrew

 

 

From: Filippov Alexey [mailto:Alexey.Filippov@huawei.com]
Sent: Wednesday, January 27, 2016 4:30 AM
To: video-codec@ietf.org= ; Krupiczka, Andrew; gmcoppa@cbs.com
Cc: minhua@broadcom.com; = Adam Roach; Zhoujiantong; Jose Alvarez
Subject: Re: Re: [video-codec] Call for review comments: draft-ietf-= netvc-requirements

 

Dear Mr. Coppa, dear Mr. Krupiczka,

 

Thank you for your valuable comments! Is my understa= nding correct that you want to keep fractional frame-rates just for IPTV/OT= T/VoD applications? Could you please specify a set of such fractional frame= -rates that you would like to include into draft-ietf-netvc-requirements?

 

Thank you in advance!

 

--

Best regards,

Alexey Filippov

 --_000_D2CFB788297CAgmcoppacbscom_-- From nobody Thu Jan 28 13:47:42 2016 Return-Path: X-Original-To: video-codec@ietf.org Delivered-To: video-codec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B80771A90C4; Thu, 28 Jan 2016 13:47:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160128214734.25981.30008.idtracker@ietfa.amsl.com> Date: Thu, 28 Jan 2016 13:47:34 -0800 Archived-At: Cc: netvc-chairs@ietf.org, video-codec@ietf.org, aroach@mozilla.com, alissa@cooperw.in Subject: [video-codec] netvc - New Meeting Session Request for IETF 95 X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 21:47:34 -0000 A new meeting session request has just been submitted by Adam Roach, a Chair of the netvc working group. --------------------------------------------------------- Working Group Name: Internet Video Codec Area Name: Applications and Real-Time Area Session Requester: Adam Roach Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 92 Conflicts to Avoid: First Priority: codec rtcweb dispatch sipcore mmusic perc cellar Second Priority: avtcore payload avtext raiarea xrblock clue Special Requests: Please make one of the new 1080p projectors available for this session. Thanks! --------------------------------------------------------- From nobody Thu Jan 28 13:50:31 2016 Return-Path: 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 DC1461A90C4 for ; Thu, 28 Jan 2016 13:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 56Ae3HcucwwS for ; Thu, 28 Jan 2016 13:50:26 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 494551A90DB for ; Thu, 28 Jan 2016 13:50:26 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id l66so29999546wml.0 for ; Thu, 28 Jan 2016 13:50:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mobcrush-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ThNoPahMt9l13xNpRQoVKc+FxAUkPC0a0GeBr1bp6bA=; b=cNHzvUg8CZWipDW73HUG7masrJfdQusGFe9OlXogF3s/ApfnHzUdtCKv5gF5K3f8fQ s2vzYnpgb0zPC8Jl67bQr3IBxe20i0GVeFJFsArgvJfbnlvPhuZgxmjNWCZJhLyuCjcP 7LZ4a5Riepcl5Uy6qSlA5WO1sikTFkQhHJ2Wy1kM1gRHlOL56DlaVuE/VgEXtZyAmymP GoB9at178k+Cawg31xNQUt/ofr2cy5SbjpuiLZm/nFCW9VgCXWfF8/N0a80oZH7CSUzT b3OPyD2RDKR7y8yy4gtupVq4UCh94U5LEveo2GjFom3nj08vPHJywT+3z/OVrng7z5JK XrwA== 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=ThNoPahMt9l13xNpRQoVKc+FxAUkPC0a0GeBr1bp6bA=; b=aeUAJ45eck0dGdF09ejnoPsRjxpTPPq9Ff2wExVWepUY5snTbv6+7PiZW7PoUHFMry UqWgL/vH/gQYHkXe7cOwToISgEx+BBcx7o/6DmRXCGjKrSFzE+klO6Gh4t0CF+BZ1Kvj U3rMCfdqy/oQakawX7/gksm58t+15MIdFRAKfhe0T5LB6XyfM7slUPY8y+1QnRAPpLem 1KZKgolJkHLxIqHwCX8o3TKH+y2e8SdXkpGhk+DXqtJhWV1OLOYFHddxeKB9BgSF9syS K2LXraJOfEaNvU7QcfVYfETO4jrBcrwRjrCI8PvxzMI2Cxz6pG/pD1vqE2W+6ZoSiYfa 4IYQ== X-Gm-Message-State: AG10YOSVWQpA7VQ1i6ioYaVru9CBxv1LT02Auy0AdaF2Lj4Il4hjXoelcVCcGbMcGldYryKr1FcRBn28Xhfl0A== MIME-Version: 1.0 X-Received: by 10.194.11.1 with SMTP id m1mr5344554wjb.125.1454017824807; Thu, 28 Jan 2016 13:50:24 -0800 (PST) Received: by 10.27.158.15 with HTTP; Thu, 28 Jan 2016 13:50:24 -0800 (PST) In-Reply-To: <7E78635F75F78C41ADC5ADAAD65831932BA6DB72@EXMDAGP11C01VC6.corp.espn.pvt> References: <5698196A.7000202@nostrum.com> <3569E2579E6AF14AAD30C8E74C9F9F887860681F@ED1PWISTMSXMB06.cbs.ad.cbs.net> <7E78635F75F78C41ADC5ADAAD65831932BA6DB72@EXMDAGP11C01VC6.corp.espn.pvt> Date: Thu, 28 Jan 2016 13:50:24 -0800 Message-ID: From: James Hurley To: "Krupiczka, Andrew" Content-Type: multipart/alternative; boundary=047d7b5d51faf1f9e4052a6be755 Archived-At: Cc: "video-codec@ietf.org" , Minhua Zhou , Adam Roach , "Coppa, Greg" Subject: Re: [video-codec] Call for review comments: draft-ietf-netvc-requirements X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 21:50:29 -0000 --047d7b5d51faf1f9e4052a6be755 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi One more comment on frame rates in the draft, I would like to see frame rates that are not fixed (or perhaps not specified at all). With H.264, for example, the frame rate / pts / dts / duration left up to the container format. Taking a quick look at the draft it seems like variable frame rates are not addressed but if they will be then disregard this note. James On Fri, Jan 15, 2016 at 7:13 AM, Krupiczka, Andrew < Andrew.Krupiczka@espn.com> wrote: > > > Good morning, > > > > Yes, concurring with Greg to include support for fractional frame rates. > > As for ESPN our current default frame-rate is 59.94fps and also using > 29.97fps for the OTT. > > Kind regards, > > > > Andrew Krupiczka > > > > *From:* video-codec [mailto:video-codec-bounces@ietf.org] *On Behalf Of *= Coppa, > Greg > *Sent:* Friday, January 15, 2016 9:46 AM > *To:* Minhua Zhou; Adam Roach; video-codec@ietf.org > > *Subject:* Re: [video-codec] Call for review comments: > draft-ietf-netvc-requirements > > > > Dear All - > > > > A comment regarding frame rate - I note that all frame rates in this > document are integer. I suggest that fractional frame rates be added > particularly the more popular ones. > > > > CBS is a provider of many hours of content to the syndication market > (OTT/VOD, US and International) I note that we are often required > (contractually) to deliver this content in its native frame rate. The > native frame rate of most of this content (e.g Star Trek, Frasier, etc.) = is > 23.976 fps. > > > > greg > > > ------------------------------ > > *From:* video-codec [video-codec-bounces@ietf.org] on behalf of Minhua > Zhou [minhua@broadcom.com] > *Sent:* Thursday, January 14, 2016 6:03 PM > *To:* Adam Roach; video-codec@ietf.org > *Subject:* Re: [video-codec] Call for review comments: > draft-ietf-netvc-requirements > > Dear all, > > > > I have few quick comments > > > > 1) Table 6. > > It seems that the parameters there only constrain the maximum pixel rate, > which is not sufficient for containing decoder implementation cost. We ne= ed > to have additional parameters to restrict decoder on/off chip memory > footprint and entropy decoding throughput. At least the following > parameters are missing: > > =C2=B7 Maximum horizontal picture size =3D> impacts line buffer = size > > =C2=B7 Memory size for buffering bitstream and decoded reference > pictures =3D> impacts off-chip memory size > > =C2=B7 Maximum bit-rate and minimum compression ratio =3D> impact= s > entropy decoding throughput requirement for real-time decoding > > > > 2) Section 3.1 > > if YUV 4:4:4 is a basic requirement, there should be no problem for a sam= e > codec to support RGB 4:4:4 color sample format. Therefore, YUV/RGB 4:4:4 > should be put in a same place (either in section 3.1 or in 3.2) > > > > 3) HDR (high dynamic range) should belong to section 3.1. > > > > 4) WCG (Wide Color Gamut) support is missing, e.g. color space > BT.2020, DCI-P3, BT.709 and OETF (ST.2084, HLG, BT.1886) > > > > 5) Section 4.1 > > since H.265 is taken as reference codec for compression efficiency > comparison, why not taking JCTVC approach to do subjective quality > evaluation, i.e. using 4 fixed QPs (could be sequence dependent to match > the target bit-rates) and computing BD-rate difference at the end? > > > > Regards, > > > > Minhua > > > > > > -----Original Message----- > From: video-codec [mailto:video-codec-bounces@ietf.org > ] On Behalf Of Adam Roach > Sent: Thursday, January 14, 2016 1:56 PM > To: video-codec@ietf.org > Subject: [video-codec] Call for review comments: > draft-ietf-netvc-requirements > > > > NETVCers: > > > > In Yokohama, we adopted draft-ietf-netvc-requirements as a working group > item. The current document has taken into account most of the comments fr= om > that meeting. > > > > Please take a few moments to read over the current document, looking in > particular for requirements that you think may be missing: > > https://tools.ietf.org/html/draft-ietf-netvc-requirements-00 > > > > Thanks! > > > > /a > > > > _______________________________________________ > > 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 > > --047d7b5d51faf1f9e4052a6be755 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

One more comment on frame rates in t= he draft, I would like to see frame rates that are not fixed (or perhaps no= t specified at all).=C2=A0 With H.264, for example, the frame rate / pts / = dts / duration left up to the container format.=C2=A0 Taking a quick look a= t the draft it seems like variable frame rates are not addressed but if the= y will be then disregard this note.

James

On Fri, Jan 15, 2016= at 7:13 AM, Krupiczka, Andrew <Andrew.Krupiczka@espn.com><= /span> wrote:

=C2=A0

Good morning,

=C2=A0

Yes, concurring with G= reg to include support for fractional frame rates.

As for ESPN our curren= t default frame-rate is 59.94fps and also using 29.97fps for the OTT.

Kind regards,

=C2=A0

Andrew Krupiczka

=C2=A0

From: video-co= dec [mailto:video-codec-bounces@ietf.org] On Behalf Of Coppa, Greg
Sent: Friday, January 15, 2016 9:46 AM
To: Minhua Zhou; Adam Roach; video-codec@ietf.org


Subject: Re: [video-codec] Call for review comments: draft-ietf-netv= c-requirements

=C2=A0

Dear All -=C2=A0

=C2=A0<= /p>

A comment regarding frame ra= te - I note that all frame rates in this document are integer. I suggest th= at fractional frame rates be added particularly the more popular ones.=C2=A0

=C2=A0<= /p>

CBS is a provider of many ho= urs of content to the syndication market (OTT/VOD, US and International) I = note that we are often required (contractually) to deliver this content in its native frame rate.=C2=A0 The native frame rate of most= of this content (e.g Star Trek, Frasier, etc.) is 23.976 fps.

=C2=A0<= /p>

greg

=C2=A0<= /p>

From: video-codec [video-codec-bounces@ietf= .org] on behalf of Minhua Zhou [minhua@broadcom.com]
Sent: Thursday, January 14, 2016 6:03 PM
To: Adam Roach; video-codec@ietf.org
Subject: Re: [video-codec] Call for review comments: draft-ietf-netv= c-requirements

Dear all,

=C2=A0

I have few quick comments

=C2=A0

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Table 6.

It seems that the= parameters there only constrain the maximum pixel rate, which is not suffi= cient for containing decoder implementation cost. We need to have additiona= l parameters to restrict decoder on/off chip memory footprint and entropy decoding through= put. At least the following parameters are missing:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Maximum horizontal picture size=C2=A0 = =3D> impacts line buffer size

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Memory size for buffering bitstream and = decoded reference pictures =C2=A0=3D> impacts off-chip memory size

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Maximum bit-rate and minimum compression= ratio =3D> impacts entropy decoding throughput requirement for real-tim= e decoding

=C2=A0

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 3.1

if YUV 4:4:4 is a= basic requirement, there should be no problem for a same codec to support = RGB 4:4:4 color sample format. Therefore, YUV/RGB 4:4:4 should be put in a = same place (either in section 3.1 or in =C2=A03.2)

=C2=A0<= /u>

3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 HDR (high dynamic range) should belong t= o section 3.1.

=C2=A0<= /u>

4)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 WCG (Wide Color Gamut) support is missin= g, e.g. color space BT.2020, DCI-P3, BT.709 and OETF (ST.2084, HLG, BT.1886= )

=C2=A0<= /u>

5)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 4.1

since H.265 is ta= ken as reference codec for compression efficiency comparison, =C2=A0why not= taking JCTVC approach to do subjective quality evaluation, i.e. using 4 fi= xed QPs (could be sequence dependent to match the target bit-rates) and computing BD-rate difference = at the end?

=C2=A0<= /u>

Regards,

=C2=A0

Minhua

=C2=A0

=C2=A0

-----Original Message-----
From: video-codec [mailto:video-codec-bounces@ietf.org] On Behalf Of Adam Roac= h
Sent: Thursday, January 14, 2016 1:56 PM
To: video-codec@i= etf.org
Subject: [video-codec] Call for review comments: draft-ietf-netvc-requireme= nts

=C2=A0

NETVCers:

=C2=A0

In Yokohama, we adopted draft-ietf-netvc-req= uirements as a working group item. The current document has taken into acco= unt most of the comments from that meeting.

=C2=A0

Please take a few moments to read over the c= urrent document, looking in particular for requirements that you think may = be missing:

https://tools.ietf.org/html/draft-ietf-netvc-requ= irements-00

=C2=A0

Thanks!

=C2=A0

/a

=C2=A0

____________________________________________= ___

video-codec mailing list

video-c= odec@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


--047d7b5d51faf1f9e4052a6be755--