Re: [payload] I-D Action: draft-ietf-payload-vp8-05.txt

["Sandy (Alexander) MacInnis" <[e-mail]>]

To clarify, I had suggested (4/25/12) that *if* the use of multiple partitions is important to some receivers in order for them to obtain the required throughput, then we might want the spec to signal the number, or the minimum number, but not the maximum number, of partitions. Receivers should never have a problem with too many partitions. Some might have a problem with too few.

I am not advocating this; I would prefer to require that all receivers simply be able to receive all streams of the indicated throughput, i.e. frame size & rate. However I have heard that there may be receivers that do require multiple partitions in order to meet their throughput requirements. One can see how this could be important for multi-threaded decoders. That's why I asked for input on this from Google.

--Sandy

From: [e-mail] [mailto:[e-mail]] On Behalf Of Patrik Westin
Sent: Tuesday, September 04, 2012 11:39 AM
To: Stephan Wenger
Cc: [e-mail]
Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-05.txt

Hi Stephan

Thanks for your feedback. Will incorporate your proposed wording change in the next update.

As for adding signaling the maximum number of partitions; that should never be needed to decode a stream and will only cause confusion.
All decoders (including HW) need to always implement support for all tools in a codec, there should be no problems in decoding any stream with number of partitions from 1 to 8.

On Fri, Aug 31, 2012 at 12:12 PM, Stephan Wenger <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

I had a quick look at the diff file only.  I think the introduction of the
two new (optional) parameters max_fs and max_fr address the concerns I
raised earlier.  I hope implementers will read 6.2.2 carefully and
understand that "optional" really meant "conditionally mandatory" :-)

The one substantial thing that needs further discussion (though not
necessarily a change in the draft, IMO), is Sandy's idea of including a
parameter for signaling the maximum number of coefficient
partitions--something that apparently may be useful for multi-threaded
decoders.  You google guys may want to comment on his idea.

A small nit for section 6.2.2: the final sentence of the section starts
with "In *many* practical applications, the max frame size and max frame
rate are known from other information; [...]".  I personally don't believe
that the word "many" is justified, and it may even be misleading.  I would
claim that in the vast majority of video-over-RTP implementations, there
is no pre-arranged knowledge of decoder capabilities before the
negotiation.  I don't see why VP8 is different here.  I believe that not
even in the webrtc case (which is, AFAIK, the main customer for this
payload format) there is pre-arranged knowledge of receiver capabilities.
So perhaps it's better to replace "many applications" with "some
applications".

Regards,
Stephan
[...snip...]