Expressing encoding limitations in CLUE signalling Design team call 26/11/2013

Encoder limits: SDP vs CLUE Want to express enough information about encoder limits to let media receiver make sensible decisions about resource segmentation SDP does the job, with some limits – Multiple O/As, limited syntax, unidirectional m-lines Does signalling encoder limits in CLUE provide enough benefit to justify new syntax rather than using existing SDP syntax?

Encoder limitations in CLUE Bandwidth Codec(s) Video- or audio-specific limits

Video-specific encode limits 0-1 of maxWidth (integer) 0-1 of maxHeight (integer) 0-1 of maxFramerate (integer ‘Traditional’ Syntax

Video-specific encode limits 0-1 of maxWidth (integer) 0-1 of maxHeight (integer) 0-1 of maxFramerate (integer 0-1 of maxPixelsPerFrame (integer) 0-1 of maxPixelsPerSecond (integer) ‘Traditional’ Syntax Pixel-focused Syntax

Audio-specific encode limits Beyond bandwidth and codec types, is there any need to express encoder limits for audio?

Per-codec limits Potentially, we could express different limits for different codecs While this does reflect real-world constraints, we are providing hints to the receiver not strict limits – do we need this level of detail?

Per-codec limits Potentially, we could express different limits for different codecs While this does reflect real-world constraints, we are providing hints to the receiver not strict limits – do we need this level of detail? ENC1 H264/90000 VP8/ H265/

Codec-specific limits Also potentially, we could allow optional codec-specific language Could allow extra codec-specific detail while not preventing new codecs from being used without new language Again – do we actually need this level of detail?

Codec-specific limits Also potentially, we could allow optional codec-specific language Could allow extra codec-specific detail while not preventing new codecs from being used without new language Again – do we actually need this level of detail? ENC

Bidirectional m-lines Expressing encoder limits in SDP necessitates unidirectional m-lines Is there a reason to mandate unidirectionality for m-lines under CLUE control if we express encoder limits in the ADVERTISMENT?

Other advantages Offerer who has seen far-end’s m-line can provide receive m-lines on offer If we support bidirectional m-lines and answerer has equal to or fewer streams than offerer, may not need a subsequent O/A – Even in this case may still need another O/A to allow fixing up of per-stream receive limits by initial offerer