Encoding syntax alternatives

Oct 8th 2013, CLUE design team meeting

Encodings in CLUE

• Allows multiplexing of multiple streams onto a single m-line

• Encodings are expressed in CLUE advertisment• Uses SSRC (or appId) to differentiate between

streams in SDP• Also uses SSRC to relate CLUE encodings to

specific m-lines (could use appId, or could use label)

Offer SDP and Advertisment

m=video ......a=ssrc:1234a=ssrc:2345a=ssrc:3456a=sendrecv

Capture Scene 1: Capture 1: Left (Encoding Group 1) Capture 2: Center (Encoding Group 1) Capture 3: Right (Encoding Group 1) Capture 4: Switched Capture Scene Entry 1: 1,2,3 Capture Scene Entry 2: 4 Simultaneous Sets: 1,2,3,4 Encoding Group 1: Encoding 1: H264, 1080p30, ssrc=1234 Encoding 2: H264, 1080p30, ssrc=2345 Encoding 3: H264, 1080p30, ssrc=3456

Offer SDP

Advertisment

Answer SDP and Configure

m=video ...... H264@720p30a=sendrecv

Capture 1, Encoding 1 Capture 2, Encoding 2 Capture 3, Encoding 3

Answer SDP Configure

Expressing receiver limitations

• fmtp parameters refer to total for all streams– Not all parameters can be subdivised (max-fs)– Allows a single over-large stream to be sent

• fmtp parameters refer to total for any one stream

• Need to decide how to deal with different stream needing different limits– Reproduce limits in CLUE– Receiver must split streams onto seperate m-lines

Answer SDP and Configure

m=video ...... H264@720p30a=sendrecv

Capture 1, Encoding 1, 720p30 Capture 2, Encoding 2, 720p30 Capture 3, Encoding 3, 720p30

Answer SDP Configure

Dealing with multiple m-lines

• Disaggregated use case requires multiple m-lines, as may receiving streams with different limits

• Hard to write rules for how to change the number of m-lines in use.

Advantages/Disadvantages

• Can express full send limitations• Fewer O/As and m-lines required

• Need to reinvent codec-specific language• Varying the number of m-lines is painful• Media-specific information CLUE messages

limits interworking with other ongoing IETf work.

Encoding constraints in CLUE

• Alternate approach, more similar to ‘encodings in SDP’ approach

• Seperate m-line per stream• Send limitations are expressed in CLUE

Offer SDP and Advertisment

m=video ...... H264@720p30a=label:Aa=sendrecvm=video ...... H264@720p30a=label:Ba=sendrecvm=video ...... H264@720p30a=label:Ca=sendrecv

Capture Scene 1: Capture 1: Left (Encoding Group 1) Capture 2: Center (Encoding Group 1) Capture 3: Right (Encoding Group 1) Capture 4: Switched Capture Scene Entry 1: 1,2,3 Capture Scene Entry 2: 4 Simultaneous Sets: 1,2,3,4 Encoding Group 1: Encoding 1: H264, 1080p30, label=A Encoding 2: H264, 1080p30, label=B Encoding 3: H264, 1080p30, label=C

Offer SDP Advertisment

Upshots of this approach

• m-lines can now be sendrecv, as there is no need to use sendonly to express the send limits

• Receive limits are expressed via SDP

Answer SDP and Configure

m=video ...... H264@720p30a=sendrecvm=video ...... H264@720p30a=sendrecvm=video ...... H264@720p30a=sendrecv

Capture 1, Encoding 1 Capture 2, Encoding 2 Capture 3, Encoding 3

Answer SDP

Configure

Advantages/Disadvantages

• Can express full send limitations• Can use sendrecv for many m-lines, reduces

number of O/As needed

• Need to reinvent codec-specific language