Re: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st

[Stephan Wenger <[e-mail]>]

Hi Patrick,

On 3.21.2012 16:46 , "Patrik Westin" <[e-mail]> wrote:

>Answers to questions regarding draft-ietf-payload-vp8-03.
>
>Answers to question from Stephan Wenger
>
>The decoder does not exhibit a significant non-uniformity
>computational complexity, we assume that the call set up process will
>provide a method for negotiating the max received resolution. Given
>that this is a commonly needed feature, we do not define any
>codec-specific way of doing this negotiation here. We will add a note
>about the need for it.

Sorry, but I do not think this is sufficient.

A simple note will not do, as it, in practice, renders the VP8 payload
close to unusable and insecure in heterogenous environments, for reasons I
mentioned in my previous email.  A normative reference to a resolution
negotiation document would help somewhat, but AFAIK, there is no document
in the IETF space that you could reference today.  If there were one,
please normatively reference it.

Beyond the payload format:

I'm not quite sure whether a generic (SDP-) code point for resolution
negotiation, independent from other properties, would be such a great
idea.  For example, think in MPEG terms, profiles and levels.  Profiles
select coding tools based on (among other things) complexity and
application requirements.  Levels are selected in units roughly
representing to picture size and frame rate, something like macroblocks
per second.  What one should shoot for, if one were trying to create a
single-dimension resolution negotiation draft, would be the rough
equivalent of signaling a level, not just a spatial resolution.  And even
with that, while in VP8 the complexity should be roughly proportional to
the MB/sec measure, this is not true for other codecs that have a
developed profile system.  If one were creating a generic solution for
resolution signaling, profile specific complexity behavior (which, quite
obviously, is highly codec dependent) would have to be taken care of.
Also, please take a look at the HEVC-type parallelization tools.  (A very
preliminary description of the problem with parallelization tools can be
found in http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-00,
section 1.)  Briefly put, with HEVC, you can sometimes decode a bitstream
even if a single core or CPU could not bear the load--if your bitstream is
tailored to support parallel decoding and if you have multiple cores.
It's an HEVC specific thing, so it has to live in the HEVC payload.  But
how would this be compatible with a hypothetical generic resolution
negotiation mechanism?

To summarize, I think you should consider the inclusion of code points
allowing to negotiate decoding complexity (macroblocks per second,
decoding memory requirements (maximum picture size), and perhaps also
maximum framerate.

Stephan

>
>
>Answers to questions from Roni Even
>
>1. Good idea, we will add it to figure 2.
>
>2. We will reformulate the paragraph so that it is clear that it's
>only summarizing information from RFC 6386.
>
>3. The packet does not belong to a discardable frame, will add a note
>about it.
>
>4. Will change to reference RFC 4566
>
>
>
>-Patrik Westin
>