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

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 26 Feb 2013 05:45:37 +0000

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. 

Need to be able to negotiate upper bound on resolution and frame rates - every time I have brought this up in the past the authors have strongly objected but I don't understand how hardware codecs work without this. The hardware codecs need to have the 4 image buffers and they will have a limit to the size of theses. My preferred way of dealing with resolution would be just to mandate use of rfc6236 when using VP8. 

I don't see a need for 7 bit pictureID, it just adds to complexity that will not be tested

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

The SDP does not allow one to specify the color space's supported but is seems that VP8 does so seems like something is needed in SDP. 

I'd like to see negotiation of the loop filter type used for a variety of reasons 

I'd like to see negotiation of the reconstrcuction filter type(s) used - amount other things new ones can be added to VP8 and we need a way to support that. 

I'd like to see what the limits are of google hardware implementation (or anyone else's if they exist) and make sure that all theses limits can be expressed in SDP. 

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. 

It would be good to see more advice on how many partitions to use and why. 

I'm confused on the Y bit. 

Unclear if receiver is supposed to send positive ACK RPSI

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 26 Feb 2013 09:36:01 +0000

Cullen, thanks for the review. I was just writing my pub-request email to
the AD. I am hoping the authors can respond back to your comments shortly
so that we don't delay this document any further.

Thanks.
-acbegen

-----Original Message-----
From: Cullen Jennings <[email-masked]>
Date: Tuesday, February 26, 2013 12:45 AM
To: "[email-masked]" <[email-masked]>
Subject: [payload] Review of draft-ietf-payload-vp8-08

>
>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.
>
>Need to be able to negotiate upper bound on resolution and frame rates -
>every time I have brought this up in the past the authors have strongly
>objected but I don't understand how hardware codecs work without this.
>The hardware codecs need to have the 4 image buffers and they will have a
>limit to the size of theses. My preferred way of dealing with resolution
>would be just to mandate use of rfc6236 when using VP8.
>
>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
>
>The SDP does not allow one to specify the color space's supported but is
>seems that VP8 does so seems like something is needed in SDP.
>
>I'd like to see negotiation of the reconstrcuction filter type(s) used -
>amount other things new ones can be added to VP8 and we need a way to
>support that. 
>
>I'd like to see what the limits are of google hardware implementation (or
>anyone else's if they exist) and make sure that all theses limits can be
>expressed in SDP. 
>
>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.
>
>_______________________________________________
>payload mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/payload
>

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 27 Feb 2013 13:48:50 +0000

Hi Cullen, WG,

>moved to a separate draft outside of payload - it's very confusing having
[...]
>things that space is littered with IPR issues that should not be confused

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

[...]

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