Subject: [video-codec] Call for review comments: draft-ietf-netvc-requirements

From: Adam Roach <[email-masked]>
Date: Thu, 14 Jan 2016 15:55:54 -0600

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: Minhua Zhou <[email-masked]>
Date: Thu, 14 Jan 2016 23:03:34 +0000

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 need to have additional parameters to restrict decoder on/off chip memory footprint and entropy decoding throughput. At least the following parameters are missing:

*         Maximum horizontal picture size  => impacts line buffer size

*         Memory size for buffering bitstream and decoded reference pictures  => impacts off-chip memory size

*         Maximum bit-rate and minimum compression ratio => impacts 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 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. 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:[email-masked]] On Behalf Of Adam Roach
Sent: Thursday, January 14, 2016 1:56 PM
To: [email-masked]
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 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:

Thanks!

/a

_______________________________________________

video-codec mailing list

[email-masked]<mailto:[email-masked]>

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

---

From: "Coppa, Greg" <[email-masked]>
Date: Fri, 15 Jan 2016 14:45:35 +0000

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 [[email-masked]] on behalf of Minhua Zhou [[email-masked]]
Sent: Thursday, January 14, 2016 6:03 PM
To: Adam Roach; [email-masked]
Subject: Re: [video-codec] Call for review comments: draft-ietf-netvc-requirements

Dear all,

1)      Table 6.

·         Maximum horizontal picture size  => impacts line buffer size

·         Memory size for buffering bitstream and decoded reference pictures  => impacts off-chip memory size

·         Maximum bit-rate and minimum compression ratio => impacts entropy decoding throughput requirement for real-time decoding

2)      Section 3.1

5)      Section 4.1

Regards,

Minhua

-----Original Message-----
From: video-codec [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Thursday, January 14, 2016 1:56 PM
To: [email-masked]
Subject: [video-codec] Call for review comments: draft-ietf-netvc-requirements

NETVCers:

Thanks!

/a

video-codec mailing list

---

From: "Krupiczka, Andrew" <[email-masked]>
Date: Fri, 15 Jan 2016 15:13:21 +0000

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:[email-masked]] On Behalf Of Coppa, Greg
Sent: Friday, January 15, 2016 9:46 AM
To: Minhua Zhou; Adam Roach; [email-masked]
Subject: Re: [video-codec] Call for review comments: draft-ietf-netvc-requirements

Dear All -

greg

To: Adam Roach; [email-masked]<mailto:[email-masked]>

Dear all,

1)      Table 6.

2)      Section 3.1

5)      Section 4.1

Regards,

Minhua

-----Original Message-----
From: video-codec [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Thursday, January 14, 2016 1:56 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [video-codec] Call for review comments: draft-ietf-netvc-requirements

NETVCers:

Thanks!

/a

video-codec mailing list

---

From: James Hurley <[email-masked]>
Date: Thu, 28 Jan 2016 13:50:24 -0800

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 <
[email-masked]> wrote:

> *From:* video-codec [mailto:[email-masked]] *On Behalf Of *Coppa,
> Greg
> *Sent:* Friday, January 15, 2016 9:46 AM
> *To:* Minhua Zhou; Adam Roach; [email-masked]
>
> *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 [[email-masked]] on behalf of Minhua
> Zhou [[email-masked]]
> *Sent:* Thursday, January 14, 2016 6:03 PM
> *To:* Adam Roach; [email-masked]
> *Subject:* Re: [video-codec] Call for review comments:
> draft-ietf-netvc-requirements
>
> Dear all,
>
>
>
> It seems that the parameters there only constrain the maximum pixel rate,
> 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 throughput. At least the following
> parameters are missing:
>
> ·         Maximum bit-rate and minimum compression ratio => impacts
> 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 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)
>
>
>
> 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
>
>
>
>
>
> From: video-codec [mailto:[email-masked]
> <[email-masked]>] On Behalf Of Adam Roach
> item. The current document has taken into account most of the comments from
> that meeting.
>
>
>
> [email-masked]
> [email-masked]