Re: [MMUSIC] Progressing the rid draft (RTP Payload Format Constraints)

[Stephan Wenger <[e-mail]>]

Hi all,
The comments I made in the mmusic session and sent to the list on 11/1 (with unfortunately an uninformative subject line; message attached for convenience) still stand.
Stephan





On 12/14/15, 12:09, "mmusic on behalf of Flemming Andreasen" <[e-mail] on behalf of [e-mail]> wrote:

>Greetings MMUSIC
>
>As you know, we have an external dependency and a fairly aggressive 
>timeline on the RTP Payload Format Constraints draft 
>(https://datatracker.ietf.org/doc/draft-ietf-mmusic-rid/)
>
>We haven't seen much list traffic on this draft since the Yokohama 
>meeting and hence would like to remind people to please take a look at 
>and post any comments you may have on the draft. If you have read the 
>current version of the draft and don't have any comments on it, we would 
>like to hear about that too.
>
>Thanks
>
>-- Flemming (as MMUSIC co-chair)
>
>
>_______________________________________________
>mmusic mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/mmusic

--- Begin Message ---

Hi,
As promised, here is a very rough idea how to express rid attributes:
Combine max_width and max_height to max-samples to allow resolution flexibility within given memory constraints.  (This would approximately correspond to the memory aspect of H.26x levels)
Keep max_fps, but define it for variable frame rate codec as an average over a second or so.  (Matches more closely the semantics of levels in H.26x)
Keep max_br as defined
Keep max_pps, but remove the confusing binding of max_pps with max_fps.   Max_pps controls “burstiness” of the codec (something that lives in the HRD parameters in H.26x).  
For codecs with a highly asymmetric behavior of entropy decoding complexity vs. reconstruction complexity (a decade ago I would have said H.264 w/ CABAC :-), you may want something limiting the number of bits per sample or bits per picture or something.
Stephan

--- End Message ---