Subject: [video-codec] Comments on draft-filippov-netvc-requirements-00

From: Thomas Daede <[email-masked]>
Date: Thu, 02 Jul 2015 13:54:35 -0700

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: "Coppa, Greg" <[email-masked]>
Date: Fri, 3 Jul 2015 14:37:33 +0000

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 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.

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 the resolution of 2160p, 59.94 frames per second is a more realistic and necessary use case. I suggest that this also be added to Table 1.

greg
________________________________________
From: video-codec [[email-masked]] on behalf of Thomas Daede [[email-masked]]
Sent: Thursday, July 02, 2015 4:54 PM
To: [email-masked]
Subject: [video-codec] Comments on draft-filippov-netvc-requirements-00

2.2. Video conferencing

2.3. Video sharing

2.4. Screencasting

2.5. Game streaming

3.1. Basic requirements

_______________________________________________
video-codec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/video-codec

---

From: Thomas Daede <[email-masked]>
Date: Fri, 03 Jul 2015 11:59:49 -0700

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: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 03 Jul 2015 12:22:00 -0700

> 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.