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

[Harald Alvestrand <[e-mail]>]

On 03/21/2012 06:27 PM, Stephan Wenger wrote:
> 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.
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.
> 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.
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
> 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
>>
>
> _______________________________________________
> payload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/payload
>