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

[John Koleszar <[e-mail]>]

On Tue, Nov 13, 2012 at 5:37 PM, Kevin Gross <[e-mail]> wrote:
[...]
> 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.
>

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.

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

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)

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

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.

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

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