lane
Uploaded by
11 SLIDES
247 VUES
110LIKES

Enhancing Multi-Stream RTP Decoding for Improved Consumer Experience

DESCRIPTION

The CLUE RTP usage proposal addresses the need for consumers to receive multiple RTP streams for efficient decoding, such as audio and video from various cameras and speakers. This document outlines approaches for using additional information in SDP and RTP header extensions to identify and manage multiple streams within a single RTP session. By proposing a consumer-chosen ID system, the solution effectively scales for complex scenarios and maintains standard RTCP behavior, streamlining interactions with remote providers without requiring prior SSRC declaration.

1 / 11

Télécharger la présentation

Enhancing Multi-Stream RTP Decoding for Improved Consumer Experience

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CLUE RTP usage Andy Pepperell andy.pepperell@silverflare.com

  2. Problem statement • CLUE consumers need to receive multiple RTP streams for decoding • Might be left + center + right camera and associated audio • Might be 16 loudest speaker streams for composition into 4 x 4 grid • More generally, could be any combination of streams being forwarded from other providers via a middle box (e.g. an MCU)

  3. Simple case • Singleaudio, single video Provider Consumer AC1 VC1

  4. Complex case Remote providers Remote consumer MCU VC1 VC2 VC3

  5. Possible solutions • Extra information in SDP for multi-stream • Pre-declaration of sender SSRC values • Extra information in CLUE and RTP • draft-lennox-clue-rtp-usage-04 • Solution to be presented here

  6. RTP sessions • Number of capture encodings from provider to consumer may be large • Sufficiently large to needmultiple RTP streams per RTP session / “m line” • General agreement that multiple RTP streams need to be sent within single “m line” • Many existing (Telepresence) endpoints already send multiple streams within a single RTP session

  7. Proposal • Additional ID in RTP streams of capture encodings • IDs chosen by consumer when it makes stream selection • IDs transported in RTP header extensions • SSRC and other header fields unaltered for forwarded streams • Multiple IDs possible for solving complex cases

  8. RTP header extension usage Remote providers’ media Remote consumer MCU VC1 . . . . . . . . . . . . . . . . . . MCU middle box changes which stream to forward, but does not change new CLUE RTP header extension contents

  9. Advantages • Scales well to complex cases • No impact on SDP, only later CLUE phase • No need to declare SSRC values in advance • RTP header fields can be forwarded from source • RTCP behavior simplified • Consumer acts in standard way on SSRC change within a capture encoding • Keeps CLUE concepts in CLUE

  10. Disadvantages of fixed SSRCs • Does not scale well to complex cases • Impact on SDP (and thus compatibility) • RTCP implications • Handling of BYEs, SDES • Other SSRC-centric issues • SRTP rollover counters

  11. Draft updates • Forthcoming changes to draft-lennox-clue-rtp-usage-04: • Use of new consumer-chosen ID in extension header • More detail on encryption

More Related