140 likes | 265 Views
This document outlines the proposal for standardizing MPEG-4 over IP frameworks, focusing on enhancing interoperability and defining MIME types for MPEG-4 files and data structures. It discusses the usage of RTP and SDP, explores the payload formats for MPEG-4 streams, and emphasizes error resilience and packetization. Key areas covered include session management via RTSP and the importance of mapping elementary stream IDs. Additionally, it outlines the next steps for collaborating between IETF and MPEG, aiming for a non-controversial and practical approach to standardization.
E N D
MPEG-4 on IP Frameworkdraft-singer-mpeg4-ip-00MPEG M6150 Joint IETF/MPEG submission, IETF to ‘standardize’ David Singer singer@apple.com Apple Computer, USA
Why? and What? • Common framework for ANY part, or all, of MPEG-4 • agree on that which can be agreed on… • intended to be non-controversial • collation of ideas and practices • Enhance interoperability • Document and assign MIME types • Refer to and use only existing drafts and specifications MPEG-4 on IP
Areas Covered • Use of RTP • common features of payload formats • Unicast and Multicast • Use of SDP • Use of RTSP • MIME names for MPEG-4 files and data structures MPEG-4 on IP
Areas NOT covered • RTP payload formats (there are several already) • Or their names (RTPMAP names) MPEG-4 on IP
RTP mapping • Send in decode order • 1st frame in each packet, allow interleave • Timescales the same • Timestamp is the presentation time (Composition time stamp) • Use RTP synchronization (map OCR or FCR to NTP) MPEG-4 on IP
RTP payload formats • One, simple, base-level scheme ought to be available • carry any Mpeg-4 stream • possibly non-optimally • any receiver ought to be able to handle it • it’s good if senders can be persuaded to send it • One scheme only for Flexmux • handles the many-small-PDUs problem MPEG-4 on IP
RTP Payloads needed • Encourage development of new schemes • Media-aware packetization • Error resilience and protection • either use existing and developing IETF techniques • or do custom formats, if more applicable • (combined source/channel coding) MPEG-4 on IP
SDP Use—IOD • 0 or 1 MPEG session in an SDP session • would be good to loosen this restriction • If an IOD is needed, find by • URL giving location • or DESCRIBE in RTSP, if no location given • global attribute a=mpeg4-iod[:location] • two round trips, different ‘accept’ values, in SDP • location is data:, http: etc. MPEG-4 on IP
SDP Use—Stream Mapping • Mapping Elementary Stream IDs (MPEG) to RTP session • single stream • FlexMux • For single streams, attrribute a=mpeg4-esid <a> • For flexmux, part of • a=mpeg4-flexmuxinfo:locatioon MPEG-4 on IP
RTSP Usage • Care with sessions, which are dependent/independent streams • Care with tearing down streams and losing session ID • Dual round-trip IF IOD is needed noted already MPEG-4 on IP
MIME names • The MPEG-4 format when used as a file (e.g. HTTP) • The IOD, over RTSP/DESCRIBE or file access • FlexMux Info (mapping, structure) • Not payload names for RTPMAP • they are in the I-Ds or RFCs that document those payload formats MPEG-4 on IP
Issues • MIME name for the standard file format: • MPEG4 or MP4? • Video, audio, or application? • Indicating terminal buffering needed? • At most 1 MPEG session in SDP • (Ignorance)? • file format for elementary streams • Multicast URLs • Flexmux tables? MPEG-4 on IP
Next steps • (MPEG has reviewed once) • Form next draft based on IETF and MPEG comments • probably also email discussion • AHG meeting in September • MPEG meeting in October MPEG-4 on IP