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

From: Patrik Westin <[email-masked]>
Date: Wed, 21 Mar 2012 16:46:49 +0100

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.

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

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 21 Mar 2012 17:27:28 +0000

Hi Patrick,

>codec-specific way of doing this negotiation here. We will add a note

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

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 22 Mar 2012 10:18:45 +0100

On 03/21/2012 06:27 PM, Stephan Wenger wrote:
> Hi Patrick,
>
> On 3.21.2012 16:46 , "Patrik Westin"<[email-masked]>  wrote:
>
I don't understand this objection, but I may be dense.
An implementation can be written as:

   negotiated resolution in pixels = <very big number>

   negotiate, draw conclusion about resolution negotiated

   if (negotiated resolution in pixels * negotiated max frame rate > my 
maximum supported rate)
        report failure
   else
        process with decoding
   endif

I do not see how this is either unusable or insecure, and I don't think 
it's appropriate for the payload format to specify normatively a single 
negotiation method.
> developed profile system.
The need for negotiating vertical and horizontal resolution has been 
identified in a *lot* of other contexts. Indeed, it's hard to find an 
application where the need does not exist.
In the main, the need exists independently of the need to determine 
decoder complexity requirements.

In VP8, the need for a "developed profile system" has not been 
identified, and we're eager to avoid having to develop one; after 
looking at the factors that drive decoder complexity for VP8, we think 
that knowing the resolution is information enough.

The fact that other codecs have other needs should not impact VP8.
>    If one were creating a generic solution for
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload
>