1 / 8

Some Background about 3GPP SA4’s RTSP extensions

Some Background about 3GPP SA4’s RTSP extensions. Thorsten Lohmar. This slides give some further motivation and background around 3GPP SA4’s extensions to RTSP 1.0. These slides are not endorsed by 3GPP SA4.

silvio
Download Presentation

Some Background about 3GPP SA4’s RTSP extensions

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. Some Background about 3GPP SA4’s RTSP extensions Thorsten Lohmar

  2. This slides give some further motivation and background around 3GPP SA4’s extensions to RTSP 1.0. These slides are not endorsed by 3GPP SA4. • S4-080090 contains the Liaison Statement “about on-going work on RTSP 2.0 and request for information on RTSP extensions”

  3. SA4’s extension to RTSP • SA4’s Packet Switched Streaming Specification (PSS) (TS 26.234) is based on RTSP 1.0 • SA4 has “profiled” RTSP 1.0 for Mobile Streaming usage • SA4 has defined several extensions to RTSP 1.0 • Liaison Statement about extensions • RTSP 2.0 will be discussed in 3GPP when it becomes an RFC

  4. Fast Content Switching and Startup • Motivation: • Switch content of a streaming session but re-using RTSP & RTP sessions • A set of content is offered to the user • Typical same number of media flows (eg. A &V) per content • Same codecs and resolution for the set of content • Example: Mobile TV with Fast Channel Switching • Switch between streams of same content • Example: languages or camera views in a streaming session without interrupting the whole streaming session • A content is provided in multiple languages or with multiple camera views • The user selects a different language or camera view during the running session • Pipelined Start-up (already adopted by RTSP 2.0) • Goal: Minimize Round-Trips to get new content played • Reference: TS 26.234 (Chapter 5.5 and Annex M) • Internet-Draft under preparation

  5. Quality of Experience Reporting • Motivation: Sending streaming specific information back • initial buffering duration • re-buffering events of streamed media • Packet loss bursts • Frame rate deviation • Channel switch events and duration • … • Reference: TS 26.234 (Chapter 11 and Chapter 5.3 for the extra RTSP header definitions)

  6. FLUTE session setup with RTSP • Motivation (defined in TS 26.346 clause clase 7.5): • Interactive Mobile TV: Proving “Interactive Media Documents” (IMD, cf. OMA BCAST) inband with the PSS unicast session • Alignment with Broadcast (MBMS / DVB) to “simplify” hybrid service offerings • Thus, FLUTE session is established together with other RTP streaming sessions to provide complementary information/services • IMDs are small in size and are evaluated after reception

  7. PSS Timeshifting (Work in Progress) • Motivation: Mobile TV and IPTV require “timeshifting” functionality • User enters “timeshifting state” just by pausing, seeking, or reverse playing a live session • RTSP session transits from “live” and “on-demand” timeline(Network Timeshift) • Timeshift may increase “perceived” quality of a broadcast to unicast handover • The media playout is continued without gaps, although the transport change and playout interruptions • Local “timeshift” considered, but likely not specified • The current Use-Cases and Working Assumptions are gathered in S4-080252

More Related