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

I think I will prepare the document write-up and ship it to the AD. If there are remaining comments that one feels the authors should address, we still have the IETF LC process.

-acbegen

On Mar 4, 2013, at 9:57 PM, Harald Alvestrand <harald@alvestrand.no> wrote:

> 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
> 
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload