Subject: [video-codec] Comments on draft-maxwell-videocodec-requirements-00

From: Kevin Gross <[email-masked]>
Date: Tue, 13 Nov 2012 18:37:54 -0700

Section 3.4

I would assume teleoperation would require greatly reduced latency compared
to telepresence.

Section 4, first paragraph:

Expand CDN -> Content Delivery Network

Section 4, third paragraph:

Here's an opportunity to focus the project. Instead of trying
to accommodate lossy and lossless networks, why not concentrate on the
lossy networks the IETF is most familiar with?

Lossless networks are the highest-performance networks and conserving
bandwidth on these is not likely a priority.

Section 4, fourth paragraph, last sentence:

There certainly are video interfaces (e.g. HDMI) that support incremental
delivery of frames. What are the interfaces that do not support subframes?

Section 4, fifth paragraph, bullet 2:

This is great for storage but, I'm not convinced this is helpful for
networks. For network operations, lower average bitrates with higher
unpredictability may be worse than higher average bitrates with greater
predictability.

If you want to keep this in, reference the teleconference applications in
sections 3.2 and 3.3 and explain how this helps those applications.

Section 5.1:

Justify the goal of reduced bitrates. On wired networks, available
bandwidth has been doubling every 18 months. Media bandwidth requirements
have been largely stagnate. See http://tinyurl.com/aes44wp figure 1 and 2.
Situations where quality is expected to be limited by available bandwidth
need to be identified.

If we're going to compare to existing codecs, we need to specify which
version of the codec we're referencing and what method(s) we'll use to do
the quality comparison.

Section 5.2 first paragraph:

Here's another opportunity to focus the project. The current text seems to
be saying that the the codec can be all things to everyone. At the BoF, the
primary IETF value of the effort was identified as open connectivity and
the biggest risk identified was IPR issues.

I will suggest that we want to build a low-complexity codec. A simpler
codec should interoperate more easily and be better at achiving our
connectivity goal. The reduced complexity should present a smaller surface
of exposure for IPR issues.

Section 5.2 second paragraph:

To maximize adoption potential the codec should be optimized, within
reason, for small memory footprint. Small memory footprint should be taken
to be small enough to fit on a smartphone or set-top box. If a
low-complexity codec is made a design goal, a small footprint should be
a natural consequence.

Section 7

During the BoF, the strength of the project was identified as open
connectivity, if we achieve this, we need to assume the codec will have
a long lifetime. Extensible as described here can help extend the usable
lifetime of the codec. It is well worth the cost of a small amount of
bandwidth.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org

---

From: John Koleszar <[email-masked]>
Date: Tue, 13 Nov 2012 22:17:22 -0800

On Tue, Nov 13, 2012 at 5:37 PM, Kevin Gross <[email-masked]> wrote:
[...]
> Here's an opportunity to focus the project. Instead of trying to accommodate
> lossy and lossless networks, why not concentrate on the lossy networks the
> IETF is most familiar with?
>

I read this to mean whether the layer 4 transport is lossless or not.
Consider a VOD stream served over HTTP/TCP vs a video conferencing
application over RTP/UDP. HTTP delivery should be a first class use
case.

> delivery of frames. What are the interfaces that do not support subframes?

They're generally not exposed in most software APIs.

Some sort of sub-frame encode latency support is probably valuable. In
the case where say the encoder and camera are on the same chip, you
can pipeline the encode with the camera. Even if you only get a whole
frame at the encoder, it could be valuable to be able to ship the data
as soon as you can fill an RTP packet, rather than waiting until the
whole frame is encoded. There are also pipelining considerations where
you'd want to be able to start decoding a frame before the previous
frame is complete in some cases (not relevant to low latency, but
mentioned in the same vein of data dependencies)

> sections 3.2 and 3.3 and explain how this helps those applications.

This is more of an issue for VOD applications rather than
teleconferencing. The rate variance you can accept is governed by how
much you can prebuffer. Taking advantage of this where possible can
get you substantial quality gains vs constant bitrate, for the same
average bitrate.

[...]
> primary IETF value of the effort was identified as open connectivity and the
> biggest risk identified was IPR issues.
>
> I will suggest that we want to build a low-complexity codec. A simpler codec
> should interoperate more easily and be better at achiving our connectivity
> goal. The reduced complexity should present a smaller surface of exposure
> for IPR issues.
>

I think that falling short of same feature sets and quality bars
posted by at least the two codecs mentioned in this section would be a
mistake, and we likely should be aiming substantially higher.

John

---

From: Kevin Gross <[email-masked]>
Date: Wed, 14 Nov 2012 09:41:10 -0700

Comments below.

> application over RTP/UDP. HTTP delivery should be a first class use

OK, let's add this clarification to the draft. I still think best to target
the lossy case. Clearly the the only way the lossless case will suffer for
this is in increased bandwidth. You've not engaged the topic in your
response but I hope I've made the case that bandwidth efficiency should not
be the primary focus of this project.

> mentioned in the same vein of data dependencies)

My reason for making the comment is I'm advocating low-latency is an
important requirement and it is compatible with other requirements of the
project. Sub-frame encoding immediately saves you up to 30 ms. That's a
gain that's hard to ignore. There are several commercial implementations
(e.g. Cavium) that do this now. If the APIs need to be improved to support
this, let's improve them.

> get you substantial quality gains vs constant bitrate, for the same

There are 8 applications listed in section 3. VOD is the only one that
clearly benefits here. How much emphasis do we want to put on that
application?

> codec

Why? The motivation for bandwidth efficiency is never convincingly
substantiated in the draft. I'm aware that bandwidth efficiency is a very
respected metric among codec developers. I'm questioning how important it
actually is for applications and users given that available network
bandwidth is increasing much faster than required media bandwidth and
the efficiency increases we expect to be able to achieve with a new codec
are comparatively modest.