Re: [payload] Review of draft-ietf-payload-vp8-08

[Stephan Wenger <[e-mail]>]

Hi Cullen, WG,

On 2.25.2013 21:45 , "Cullen Jennings (fluffy)" <[e-mail]> wrote:

>
>My major issues is I think it is not appropriate to define a temperable
>scalable codec in the same draft as the payload. I'm fine with the
>payloads for it but I think the temporal scalability stuff should be
>moved to a separate draft outside of payload - it's very confusing having
>the two mixed together.
[...]
>
>The temporal stuff does not seem to be specified very well. To be more
>specific, I think creating a layered codec from a non layered codec would
>better be done in a spec other than the payload description. Among other
>things that space is littered with IPR issues that should not be confused
>with the base payload

I disagree.  Strongly.  If you have one version of one codec then there
should also be only one payload spec that addresses all (or at least all
sensible) operation points of that version of the codec.  Ideally, the
payload spec should cover all versions, but that's sometimes not feasible.
 

If we start creating multiple payload formats for the same spec based on
application requirements, IPR considerations, implementation complexity,
..., we would encourage people in the future to worry only about their
application rather than generic use cases, and the result would be tons of
potentially incompatible payload formats for one media codec.  Bad.
(In H.264, we went this route for purely pragmatic reasons--3984 and 6184
are already close to unreadable due
to their size and density.).

As for the IPR, what do you think you would learn in addition to what you
know now, by separating the two specs?

For those who haven't followed the development of this draft, there is
only one IPR disclosure posted, which is from us (Vidyo; see
https://datatracker.ietf.org/ipr/1622/).  The licensing terms should sound
vaguely familiar to a person working on IETF matters in Cisco :-)
Interpreting the scope of that patent application is left as an exercise
to the interested reader; however, I will note that we filed our
disclosure shortly after the temporal scalability stuff was added into the
draft. 

The right way to deal with IPR-tricky parts of specs that are not
necessary for all implementations is to make them optional in the spec,
which implies an SDP codepoint for their negotiation.  However, given the
nature of video codecs and their payload formats in general, I don't think
you would gain or loose a lot in terms of commercial risk...

[...]

>I'd like to see a way of describing upper bound on macro block rate
>instead of the combined max-fs / max-fr solution. I don't see how to make
>hardware decoders work without this.

I was arguing in favor of that also, but after a long discussion I believe
we came to the conclusion that the computational complexity part of the
negotiation story is solved by the combined max-fs / max-fr trick, and the
memory aspect would be solved by the generic image attribute SDP.  While I
consider that solution suboptimal, I can live with it.  It's no worse than
the level concept of MPEG (which also mixes computational complexity and
memory demand), and sometimes a one-dimensional solution space is easier
to solve than a two-dimensional one.

[...]

Stephan

P.s.: in case anyone wonders, I still do not like VP8.