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

[Harald Alvestrand <[e-mail]>]

Thanks for the review, Cullen. It is only 3 months since the second WG 
Last Call on this document, and almost exactly one year since the first 
WG Last Call - most of what you mention has been unchanged even long 
before that, so this is definitely asking for late changes.

I haven't consulted with the experts on this yet - it seems they are on 
vacation or otherwise unavailable at the moment, so this is my attempt 
at responses.

On 02/26/2013 06:45 AM, Cullen Jennings (fluffy) 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.
I disagree. This is a payload that has some properties that make some 
scalability options possible, and the payload format needs some 
properties in order to take advantage of that.

There is no "non-scalable variant" of VP8. This is it.
> 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.

There are plenty of ways to negotiate upper limits on resolution. 
a=imageattr is just one of them.

When discussing what we need to limit with our hardware design people, 
max-fr and max-fs was the result of the discussion; max-fs limits the 
size of a frame, and max-fr limits the frame rate.

This was a topic raised at the first Last Call, the addition of max-fs 
and max-fr was the major technical change done at that time, and the 
original poster said that his issue had been addressed.
> I don't see a need for 7 bit pictureID, it just adds to complexity that will not be tested
7-bit picture IDs were added in order to reduce the overhead, I believe. 
Taking them out now would lead to an interesting interoperability issue 
with existing deployed code; I wouldn't want to remove it until all 
existing code has been checked to verify that they never generate it.

I can check with the people who maintain it if you really want to pursue 
the issue.
> 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

Feel free to file IPR disclosures on it.
As I said before, the codec has certain layering properties, and the 
payload needs to expose those.

> 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.
VP8 does not permit any decoder to duck out of supporting what the 
encoder is able to send.
It was a design decision to limit the negotiation to the absolute 
minimum; we'd like to keep that property unless compellling scenarios 
arguing for something else comes up.
> I'd like to see negotiation of the loop filter type used for a variety of reasons
Again, the choice of going for one profile without negotiation was a 
deliberate one. What cannot be negotiated cannot be messed up by 
negotiation failure.
So far, all VP8 decoders can decode all valid VP8 encoded streams; we'd 
like to keep that property.

If compelling use cases come up, we could revisit this - but they'd have 
to be very compelling.
> 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.
VP8 is a fixed bitstream, and Google does not have plans to develop it 
further.
Do you see a reason for making such changes to VP8 instead of 
contributing them into ongoing video work (video-codec, VP9)?
> 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.
Feel free to contact Aki for access to the hardware tapeouts.
> 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.
Apparently the current hardware decoders were able to make it work.
> It would be good to see more advice on how many partitions to use and why.
Advice is good, but I think this will change due to more circumstances 
than can easily fit into an RTP spec; I don't think this is the right 
place for that advice.
> I'm confused on the Y bit.
Please explain the nature of your confusion - I believe I understood it, 
but I may have missed something.
> Unclear if receiver is supposed to send positive ACK RPSI
It is allowed - the section describes why it is useful. It is not 
mandated; applications can do that if they want to, but the payload 
format is the same whether or not the application uses RPSI.

My summary comment: I don't see a reason to make technical changes to 
the spec based on these comments.
I also don't see a reason to delay the IETF-wide last call based on 
these comments.

Clarifications, if needed, can be addressed together with Last Call 
comments after IETF Last Call.

               Harald