home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-avt-mpeg-new-00.txt < prev    next >
Text File  |  1997-04-29  |  32KB  |  844 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Internet Engineering Task Force      Audio/Video Transport Working Group
  8. INTERNET-DRAFT                                                D. Hoffman
  9. draft-ietf-avt-mpeg-new-00.txt                               G. Fernando
  10.                                                   Sun Microsystems, Inc.
  11.                                                                 V. Goyal
  12.                                                   Precept Software, Inc.
  13.                                                         M. Reha Civanlar
  14.                                                     AT&T Labs - Research
  15.                                                               April 1997
  16.                                                     Expires October 1997
  17.  
  18.  
  19.                 RTP Payload Format for MPEG1/MPEG2 Video
  20.  
  21. Status of this Memo
  22.  
  23.    This document is an Internet-Draft.  Internet-Drafts are working
  24.    documents of the Internet Engineering Task Force (IETF), its areas,
  25.    and its working groups.  Note that other groups may also distribute
  26.    working documents as Internet-Drafts.
  27.  
  28.    Internet-Drafts are draft documents valid for a maximum of six months
  29.    and may be updated, replaced, or obsoleted by other documents at any
  30.    time.  It is inappropriate to use Internet-Drafts as reference
  31.    material or to cite them other than as "work in progress."
  32.  
  33.    To learn the current status of any Internet-Draft, please check the
  34.    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  35.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  36.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  37.    ftp.isi.edu (US West Coast).
  38.  
  39.    Distribution of this document is unlimited.
  40.  
  41. Abstract
  42.  
  43.    This memo describes a packetization scheme for MPEG video and audio
  44.    streams.  The scheme proposed can be used to transport such a video
  45.    or audio flow over the transport protocols supported by RTP.  Two
  46.    approaches are described. The first is designed to support maximum
  47.    interoperability with MPEG System environments.  The second is
  48.    designed to provide maximum compatibility with other RTP-encapsulated
  49.    media streams and future conference control work of the IETF.
  50.  
  51.    This memo is a revision of RFC 2038, an Internet standards track pro-
  52.    tocol, prepared for publication as a revised RFC.  In this revision,
  53.    the packet loss resiliance mechanisms in Section 3.4 were extended to
  54.    include additional picture header information required for MPEG2.
  55.  
  56.  
  57.  
  58. Hoffman, et. al.          Expires October 1997                  [Page 1]
  59.  
  60. Internet-Draft  RTP Payload Format for MPEG1/MPEG2 Video      April 1997
  61.  
  62.  
  63. 1. Introduction
  64.  
  65.    ISO/IEC JTC1/SC29 WG11 (also referred to as the MPEG committee) has
  66.    defined the MPEG1 standard (ISO/IEC 11172)[1] and the MPEG2 standard
  67.    (ISO/IEC 13818)[2].  This memo describes a packetization scheme to
  68.    transport MPEG video and audio streams using the Real-time Transport
  69.    Protocol (RTP), version 2 [3, 4].
  70.  
  71.    The MPEG1 specification is defined in three parts: System, Video and
  72.    Audio.  It is designed primarily for CD-ROM-based applications, and
  73.    is optimized for approximately 1.5 Mbits/sec combined data rates. The
  74.    video and audio portions of the specification describe the basic for-
  75.    mat of the video or audio stream.  These formats define the Elemen-
  76.    tary Streams (ES).  The MPEG1 System specification defines an encap-
  77.    sulation of the ES that contains Presentation Time Stamps (PTS),
  78.    Decoding Time Stamps and System Clock references, and performs multi-
  79.    plexing of MPEG1 compressed video and audio ES's with user data.
  80.  
  81.    The MPEG2 specification is structured in a similar way. However, it
  82.    hasn't been restricted only to CD-ROM applications. The MPEG2 System
  83.    specification defines two system stream formats:  the MPEG2 Transport
  84.    Stream (MTS) and the MPEG2 Program Stream (MPS).  The MTS is tailored
  85.    for communicating or storing one or more programs of MPEG2 compressed
  86.    data and also other data in relatively error-prone environments. The
  87.    MPS is tailored for relatively error-free environments.
  88.  
  89.    We seek to achieve interoperability among 4 types of end-systems in
  90.    the following specification. The 4 types are:
  91.  
  92.         1. Transmitting Interworking Unit (TIU)
  93.  
  94.            Receives MPEG information from a native MTS system for
  95.            distribution over packet networks using a native RTP-based
  96.            system layer (such as an IP-based internetwork). Examples:
  97.            real-time encoder, MTS satellite link to Internet, video
  98.            server with MTS-encoded source material.
  99.  
  100.         2. Receiving Interworking Unit (RIU)
  101.  
  102.            Receives MPEG information in real time from an RTP-based
  103.            network for forwarding to a native MTS environment.
  104.            Examples: Internet-based video server to MTS-based cable
  105.            distribution plant.
  106.  
  107.         3. Transmitting Internet End-System (TAES)
  108.  
  109.            Transmits MPEG information generated or stored within the
  110.            internet end-system itself, or received from internet-based
  111.  
  112.  
  113.  
  114. Hoffman, et. al.          Expires October 1997                  [Page 2]
  115.  
  116. Internet-Draft  RTP Payload Format for MPEG1/MPEG2 Video      April 1997
  117.  
  118.  
  119.            computer networks.  Example: video server.
  120.  
  121.         4. Receiving Internet End-System (RAES)
  122.  
  123.            Receives MPEG information over an RTP-based internet for
  124.            consumption at the internet end-system or forwarding to
  125.            traditional computer network.  Example: desktop PC or
  126.            workstation viewing training video.
  127.  
  128.    Each of the 2 types of transmitters must work with each of the 2
  129.    types of receivers.  Because it is probable that the TAES, and cer-
  130.    tain that the RAES, will be based on existing and planned internet-
  131.    connected computers, it is highly desirable for the interoperable
  132.    protocol to be based on RTP.
  133.  
  134.    Because of the range of applications that might employ MPEG streams,
  135.    we propose to define two payload formats.
  136.  
  137.    Much interest in the MPEG community is in the use of one of the MPEG
  138.    System encodings, and hence, in Section 2 we propose encapsulations
  139.    of MPEG1 System streams and MPEG2 Transport and Program Streams with
  140.    RTP.  This profile supports the full semantics of MPEG System and
  141.    offers basic interoperability among all four end-system types.
  142.  
  143.    When operating only among internet-based end-systems (i.e., TAES and
  144.    RAES) a payload format that provides greater compatibility with the
  145.    Internet architecture is desired, deferring some of the system issues
  146.    to other protocols being defined in the Internet community (such as
  147.    the MMUSIC WG).  In Section 3 we propose an encapsulation of
  148.    compressed video and audio data (referred to in MPEG documentation as
  149.    "Elementary Streams" (ES)) complying with either MPEG1 or MPEG2.
  150.    Here, neither of the System standards of MPEG1 or MPEG2 are utilized.
  151.    The ES's are directly encapsulated with RTP.
  152.  
  153.    Throughout this specification, we make extensive use of MPEG termi-
  154.    nology.  The reader should consult the primary MPEG references for
  155.    definitive descriptions of this terminology.
  156.  
  157. 2. Encapsulation of MPEG System and Transport Streams
  158.  
  159.    Each RTP packet will contain a timestamp derived from the sender's
  160.    90KHz clock reference.  This clock is synchronized to the system
  161.    stream Program Clock Reference (PCR) or System Clock Reference (SCR)
  162.    and represents the target transmission time of the first byte of the
  163.    packet payload.  The RTP timestamp will not be passed to the MPEG
  164.    decoder.  This use of the timestamp is somewhat different than nor-
  165.    mally is the case in RTP, in that it is not considered to be the
  166.    media display or presentation timestamp. The primary purposes of the
  167.  
  168.  
  169.  
  170. Hoffman, et. al.          Expires October 1997                  [Page 3]
  171.  
  172. Internet-Draft  RTP Payload Format for MPEG1/MPEG2 Video      April 1997
  173.  
  174.  
  175.    RTP timestamp will be to estimate and reduce any network-induced
  176.    jitter and to synchronize relative time drift between the transmitter
  177.    and receiver.
  178.  
  179.    For MPEG2 Transport Streams the RTP payload will contain an integral
  180.    number of MPEG transport packets.  To avoid end system inefficien-
  181.    cies, data from multiple small MTS packets (normally fixed in size at
  182.    188 bytes) are aggregated into a single RTP packet.  The number of
  183.    transport packets contained is computed by dividing RTP payload
  184.    length by the length of an MTS packet (188).
  185.  
  186.    For MPEG2 Program streams and MPEG1 system streams there are no pack-
  187.    etization restrictions; these streams are treated as a packetized
  188.    stream of bytes.
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Hoffman, et. al.          Expires October 1997                  [Page 4]
  227.  
  228. Internet-Draft  RTP Payload Format for MPEG1/MPEG2 Video      April 1997
  229.  
  230.  
  231. 2.1 RTP header usage
  232.  
  233.    The RTP header fields are used as follows:
  234.  
  235.         Payload Type: Distinct payload types should be assigned for
  236.           MPEG1 System Streams, MPEG2 Program Streams and MPEG2
  237.           Transport Streams.  See [4] for payload type assignments.
  238.  
  239.         M bit:  Set to 1 whenever the timestamp is discontinuous
  240.           (such as might happen when a sender switches from one data
  241.           source to another). This allows the receiver and any
  242.           intervening RTP mixers or translators that are synchronizing
  243.           to the flow to ignore the difference between this timestamp
  244.           and any previous timestamp in their clock phase detectors.
  245.  
  246.         timestamp: 32 bit 90K Hz timestamp representing the target
  247.           transmission time for the first byte of the packet.
  248.  
  249. 3. Encapsulation of MPEG Elementary Streams
  250.  
  251.    The following ES types may be encapsulated directly in RTP:
  252.  
  253.         (a) MPEG1 Video (ISO/IEC 11172-2)
  254.         (b) MPEG2 Video (ISO/IEC 13818-2)
  255.         (c) MPEG1 Audio (ISO/IEC 11172-3)
  256.         (d) MPEG2 Audio (ISO/IEC 13818-3)
  257.  
  258.    A distinct RTP payload type is assigned to MPEG1/MPEG2 Video and
  259.    MPEG1/MPEG2 Audio, respectively. Further indication as to whether the
  260.    data is MPEG1 or MPEG2 need not be provided in the RTP or MPEG-
  261.    specific headers of this encapsulation, as this information is avail-
  262.    able in the ES headers.
  263.  
  264.    Presentation Time Stamps (PTS) of 32 bits with an accuracy of 90 kHz
  265.    shall be carried in the fixed RTP header. All packets that make up a
  266.    audio or video frame shall have the same time stamp.
  267.  
  268. 3.1 MPEG Video elementary streams
  269.  
  270.    MPEG1 Video can be distinguished from MPEG2 Video at the video
  271.    sequence header, i.e. for MPEG2 Video a sequence_header() is followed
  272.    by sequence_extension().  The particular profile and level of MPEG2
  273.    Video (MAIN_Profile@MAIN_Level, HIGH_Profile@HIGH_Level, etc) are
  274.    determined by the profile_and_level_indicator field of the
  275.    sequence_extension header of MPEG2 Video.
  276.  
  277.    The MPEG bit-stream semantics were designed for relatively error-free
  278.    environments, and there is significant amount of dependency (both
  279.  
  280.  
  281.  
  282. Hoffman, et. al.          Expires October 1997                  [Page 5]
  283.  
  284. Internet-Draft  RTP Payload Format for MPEG1/MPEG2 Video      April 1997
  285.  
  286.  
  287.    temporal and spatial) within the stream such that loss of some data
  288.    make other uncorrupted data useless.  The format as defined in this
  289.    encapsulation uses application layer framing information plus addi-
  290.    tional information in the RTP stream-specific header to allow for
  291.    certain recovery mechanisms.  Appendix 1 suggests several recovery
  292.    strategies based on the properties of this encapsulation.
  293.  
  294.    Since MPEG pictures can be large, they will normally be fragmented
  295.    into packets of size less than a typical LAN/WAN MTU.  The following
  296.    fragmentation rules apply:
  297.  
  298.         1. The MPEG Video_Sequence_Header, when present, will always
  299.            be at the beginning of an RTP payload.
  300.         2. An MPEG GOP_header, when present, will always be at the
  301.            beginning of the RTP payload, or will follow a
  302.            Video_Sequence_Header.
  303.         3. An MPEG Picture_Header, when present, will always be at the
  304.            beginning of a RTP payload, or will follow a GOP_header.
  305.  
  306.    Each ES header must be completely contained within the packet.  Con-
  307.    sequently, a minimum RTP payload size of 261 bytes must be supported
  308.    to contain the largest single header defined in the ES (that is, the
  309.    extension_data() header containing the quant_matrix_extension()).
  310.    Otherwise, there are no restrictions on where headers may appear
  311.    within packet payloads.
  312.  
  313.    In MPEG, each picture is made up of one or more "slices," and a slice
  314.    is intended to be the unit of recovery from data loss or corruption.
  315.    An MPEG-compliant decoder will normally advance to the beginning of
  316.    next slice whenever an error is encountered in the stream.  MPEG
  317.    slice begin and end bits are provided in the encapsulation header to
  318.    facilitate this.
  319.  
  320.    The beginning of a slice must either be the first data in a packet
  321.    (after any MPEG ES headers) or must follow after some integral number
  322.    of slices in a packet.  This requirement insures that the beginning
  323.    of the next slice after one with a missing packet can be found
  324.    without requiring that the receiver scan the packet contents.  Slices
  325.    may be fragmented across packets as long as all the above rules are
  326.    met.
  327.  
  328.    An implementation based on this encapsulation assumes that the
  329.    Video_Sequence_Header is repeated periodically in the MPEG bit-
  330.    stream.  In practice (though not required by MPEG standard) this is
  331.    used to allow channel switching and to receive and start decoding a
  332.    continuously relayed MPEG bit-stream at arbitrary points in the media
  333.    stream.  It is suggested that when playing back from an MPEG stream
  334.    from a file format (where the Video_Sequence_Header may only be
  335.  
  336.  
  337.  
  338. Hoffman, et. al.          Expires October 1997                  [Page 6]
  339.  
  340. Internet-Draft  RTP Payload Format for MPEG1/MPEG2 Video      April 1997
  341.  
  342.  
  343.    represented at the beginning of the stream) that the first
  344.    Video_Sequence_Header (preceded by an end-of-stream indicator) be
  345.    saved by the packetizer for periodic injection in to the network
  346.    stream.
  347.  
  348. 3.2 MPEG Audio elementary streams
  349.  
  350.    MPEG1 Audio can be distinguished from MPEG2 Audio from the MPEG
  351.    ancillary_data() header.  For either MPEG1 or MPEG2 Audio, distinct
  352.    Presentation Time Stamps may be present for frames which correspond
  353.    to either 384 samples for Layer-I, or 1152 samples for Layer-II or
  354.    Layer-III.  The actual number of bytes required to represent this
  355.    number of samples will vary depending on the encoder parameters.
  356.  
  357.    Multiple audio frames may be encapsulated within one RTP packet.  In
  358.    this case, an integral number of audio frames must be contained
  359.    within the packet and the fragmentation header defined in Section 3.5
  360.    shall be set to 0.
  361.  
  362.    Also, if relatively short packets are to be used, one frame may be so
  363.    large that it may straddle multiple RTP packets.  For example, for
  364.    Layer-II MPEG audio sampled at a rate of 44.1 KHz each frame would
  365.    represent a time slot of 26.1 msec. At this sampling rate if the
  366.    compressed bit-rate is 384 kbits/sec (i.e.  48 kBytes/sec) then the
  367.    average audio frame size would be 1.25 KBytes.  If packets were to be
  368.    500 Bytes long, then each audio frame would straddle 3 RTP packets.
  369.    The audio fragmentation indicator header (See Section 3.5) shall be
  370.    present for an MPEG1/2 Audio payload type to provide for this frag-
  371.    mentation.
  372.  
  373. 3.3 RTP Fixed Header for MPEG ES encapsulation
  374.  
  375.    The RTP header fields are used as follows:
  376.  
  377.         Payload Type: Distinct payload types should be assigned
  378.           for video elementary streams and audio elementary streams.
  379.           See [4] for payload type assignments.
  380.  
  381.         M bit:  For video, set to 1 on packet containing MPEG frame
  382.           end code, 0 otherwise.  For audio, set to 1 on first packet
  383.           of a "talk-spurt," 0 otherwise.
  384.  
  385.  
  386.         PT:  MPEG video or audio stream ID.
  387.  
  388.         timestamp: 32-bit 90K Hz timestamp representing presentation
  389.           time of MPEG picture or audio frame.  Same for all packets
  390.           that make up a picture or audio frame.  May not be
  391.           monotonically increasing in video stream if B pictures
  392.  
  393.  
  394.  
  395. Hoffman, et. al.          Expires October 1997                  [Page 7]
  396.  
  397. Internet-Draft  RTP Payload Format for MPEG1/MPEG2 Video      April 1997
  398.  
  399.  
  400.           present in stream.  For packets that contain only a video
  401.           sequence and/or GOP header, the timestamp is that of the
  402.           subsequent picture.
  403.  
  404. 3.4 MPEG Video-specific header
  405.  
  406.    This header shall be attached to each RTP packet after the RTP fixed
  407.    header.
  408.  
  409.  0                   1                   2                   3
  410.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  411. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  412. |    MBZ  |T|         TR        | |N|S|B|E|  P  | | BFC | | FFC |
  413. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  414.                                 AN              FBV     FFV
  415.  
  416.         MBZ: Unused. Must be set to zero in current
  417.            specification. This space is reserved for future use.
  418.  
  419.         T: MPEG-2 (Two) specific header extension present (1 bit).
  420.            Set to 1 when MPEG-2 specific picture header information
  421.            follows this header. This information consists of a 32 bit
  422.            MPEG-2 video specific header extension and other optional
  423.            extensions. MPEG-2 specific information may be needed for
  424.            improved error resilience; however, its inclusion in an
  425.            RTP packet is optional. (See Appendix 1.)
  426.  
  427.         TR: Temporal-Reference (10 bits). The temporal reference of
  428.            the current picture within the current GOP. This value
  429.            ranges from 0-1023 and is constant for all RTP packets of a
  430.            given picture.
  431.  
  432.         AN: Active N bit for error resilience (1 bit). Set to 1 when
  433.            the following bit (N) is used to signal changes in the
  434.            picture header information for MPEG-2 payloads. It must be
  435.            set to 0 for MPEG-1 payloads or when N bit is not used.
  436.  
  437.         N: New picture header (1 bit). Used for MPEG-2 payloads when
  438.            the previous bit (AN) is set to 1. Otherwise, it must
  439.            be set to zero. Set to 1 when the information contained in
  440.            the previously transmitted Picture Headers can't be used to
  441.            reconstruct a header for the current picture. This happens
  442.            when the current picture is encoded using a different
  443.            set of parameters than the previous pictures of the same
  444.            type. The N bit must be constant for all RTP packets that
  445.            belong to the same picture so that receipt of any packet
  446.            from a picture allows detecting whether information
  447.            necessary for reconstruction was contained in that picture
  448.  
  449.  
  450.  
  451. Hoffman, et. al.          Expires October 1997                  [Page 8]
  452.  
  453. Internet-Draft  RTP Payload Format for MPEG1/MPEG2 Video      April 1997
  454.  
  455.  
  456.            (N = 1) or a previous one (N = 0).
  457.  
  458.         S: Sequence-header-present (1 bit). Normally 0 and set to 1 at
  459.            the occurrence of each MPEG sequence header.  Used to
  460.            detect presence of sequence header in RTP packet.
  461.  
  462.         B: Beginning-of-slice (BS) (1 bit). Set when the start of the
  463.            packet payload is a slice start code, or when a slice start
  464.            code is preceded only by one or more of a
  465.            Video_Sequence_Header, GOP_header and/or Picture_Header.
  466.  
  467.         E: End-of-slice (ES) (1 bit). Set when the last byte of the
  468.            payload is the end of an MPEG slice.
  469.  
  470.         P: Picture-Type (3 bits). I (1), P (2), B (3) or D (4). This
  471.            value is constant for each RTP packet of a given picture.
  472.            Value 000B is forbidden and 101B - 111B are reserved to
  473.            support future extensions to the MPEG ES specification.
  474.  
  475.         FBV: full_pel_backward_vector
  476.         BFC: backward_f_code
  477.         FFV: full_pel_forward_vector
  478.         FFC: forward_f_code
  479.            Obtained from the most recent picture header, and are
  480.            constant for each RTP packet of a given picture. For I
  481.            frames none of these values are present in the picture
  482.            header and they must be set to zero in the RTP header.
  483.            For P frames only the last two values are present and
  484.            FBV and BFC must be set to zero in the RTP header. For
  485.            B frames all the four values are present.
  486.  
  487. 3.4.1 MPEG-2 Video-specific header extension
  488.  
  489.  0                   1                   2                   3
  490.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  491. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  492. |X|E|f_[0,0]|f_[0,1]|f_[1,0]|f_[1,1]| DC| PS|T|P|C|Q|V|A|R|H|G|D|
  493. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  494.  
  495.  
  496.         X: Unused (1 bit). Must be set to zero in current
  497.            specification. This space is reserved for future use.
  498.  
  499.         E: Extensions present (1 bit). If set to 1, this header,
  500.            including the composite display extension when D = 1, will
  501.            be followed by one or more of the following extensions:
  502.            quant matrix extension, picture display extension, picture
  503.            temporal scalable extension, picture spatial scalable
  504.  
  505.  
  506.  
  507. Hoffman, et. al.          Expires October 1997                  [Page 9]
  508.  
  509. Internet-Draft  RTP Payload Format for MPEG1/MPEG2 Video      April 1997
  510.  
  511.  
  512.            extension and copyright extension.
  513.  
  514.            The first byte of these extensions data gives the length of
  515.            the extensions in 32 bit words including the length field
  516.            itself. Zero padding bytes are used at the end if required
  517.            to align the extensions to 32 bit boundary.
  518.  
  519.            Since they may not be vital in decoding of a picture, the
  520.            inclusion of any one of these extensions in an RTP packet
  521.            is optional even when the MPEG-2 specific extension is
  522.            included in the packet (T = 1). (See Appendix 1.)If present,
  523.            they should be copied from the corresponding extensions
  524.            following the most recent MPEG-2 picture coding extension and
  525.            they remain constant for each RTP packet of a given picture.
  526.  
  527.            The extension start code (32 bits) and the extension start
  528.            code ID (4 bits) are included. Therefore the extensions are
  529.            self identifying.
  530.  
  531.         f_[0,0]: forward horizontal f_code (4 bits)
  532.         f_[0,1]: forward vertical f_code (4 bits)
  533.         f_[1,0]: backward horizontal f_code (4 bits)
  534.         f_[1,1]: backward vertical f_code (4 bits)
  535.         DC: intra_DC_precision (2 bits)
  536.         PS: picture_structure (2 bits)
  537.         T: top_field_first (1 bit)
  538.         P: frame_predicted_frame_dct (1 bit)
  539.         C: concealment_motion_vectors (1 bit)
  540.         Q: q_scale type (1 bit)
  541.         V: intra_vlc_format (1 bit)
  542.         A: alternate scan (1 bit)
  543.         R: repeat_first_field (1 bit)
  544.         H: chroma_420_type (1 bit)
  545.         G: progressive frame (1 bit)
  546.         D: composite_display_flag (1 bit). If set to 1, next 32 bits
  547.            following this one contains 12 zeros followed by 20 bits
  548.            of composite display information.
  549.  
  550.         These values are copied from the most recent picture
  551.         coding extension and are constant for each RTP packet
  552.         of a given picture. Their meanings are as explained in
  553.         the MPEG-2 standard.
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562.  
  563. Hoffman, et. al.          Expires October 1997                 [Page 10]
  564.  
  565. Internet-Draft  RTP Payload Format for MPEG1/MPEG2 Video      April 1997
  566.  
  567.  
  568. 3.5 MPEG Audio-specific header
  569.  
  570.    This header shall be attached to each RTP packet at the start of the
  571.    payload and after any RTP headers for an MPEG1/2 Audio payload type.
  572.  
  573.  0                   1                   2                   3
  574.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  575. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  576. |             MBZ               |          Frag_offset          |
  577. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  578.  
  579.         Frag_offset: Byte offset into the audio frame for the data
  580.            in this packet.
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618.  
  619. Hoffman, et. al.          Expires October 1997                 [Page 11]
  620.  
  621. Internet-Draft  RTP Payload Format for MPEG1/MPEG2 Video      April 1997
  622.  
  623.  
  624. Appendix 1. Error Recovery and Resynchronization Strategies.
  625.  
  626.    The following error recovery and resynchronization strategies are
  627.    intended to be guidelines only.  A compliant receiver is free to
  628.    employ alternative (or no) strategies.
  629.  
  630.    When initially decoding an RTP-encapsulated MPEG Elementary Stream,
  631.    the receiver may discard all packets until the Sequence-header-
  632.    present bit is set to 1.  At this point, sufficient state information
  633.    is contained in the stream to allow processing by an MPEG decoder.
  634.  
  635.    Loss of packets containing the GOP_header and/or Picture_Header are
  636.    detected by an unexpected change in the Temporal-Reference and
  637.    Picture-Type values.  Consider the following example GOP sequence:
  638.  
  639.         In display order: 0B 1B 2I 3B 4B 5P 6B 7B 8P GOP_HDR 0B ...
  640.         In stream order:  2I 0B 1B 5P 3B 4B 8P 6B 7B GOP_HDR 2I ...
  641.  
  642.    Consider also two counters:
  643.  
  644.         ref_pic_temp (Reference Picture (I,P) Temporal Reference)
  645.         dep_pic_temp (Dependent Picture (B) Temporal Reference)
  646.  
  647.    At each GOP beginning, set these counters to the temporal reference
  648.    value of the corresponding picture type. For our example GOP
  649.    sequence, ref_pic_temp = 2 and dep_pic_temp = 0. Keep incrementing
  650.    BOTH counters by unity with each following picture. Ref_pic_temp
  651.    should match the temporal references of the I and P frames, and
  652.    dep_pic_temp should match the temporal references of the B frames.
  653.  
  654.        dep_pic_temp: -  0  1  2  3  4  5  6  7        8  9
  655.    In stream order:  2I 0B 1B 5P 3B 4B 8P 6B 7B GOP_H 2I 0B 1B ...
  656.        ref_pic_temp: 2  3  4  5  6  7  8  9  10  ^    11
  657.                      --------------------------  |    ^
  658.                                 Match            Drop |
  659.                                                       Mismatch
  660.                                                        in ref_pic_temp
  661.  
  662.    The loss of a GOP header can be detected by matching the appropriate
  663.    counter (based on picture type) to the temporal reference value. A
  664.    mismatch indicates a lost GOP header. If desired, a GOP header can be
  665.    re-constructed using a "null" time_code, repeating the closed_gop
  666.    flag from previous GOP headers, and setting the broken_link flag to
  667.    1.
  668.  
  669.    The loss of a Picture_Header can also be detected by a mismatch in
  670.    the Temporal Reference contained in the RTP packet from the appropri-
  671.    ate dep_pic_temp or ref_pic_temp counters at the receiver. For MPEG-1
  672.  
  673.  
  674.  
  675. Hoffman, et. al.          Expires October 1997                 [Page 12]
  676.  
  677. Internet-Draft  RTP Payload Format for MPEG1/MPEG2 Video      April 1997
  678.  
  679.  
  680.    payloads, after scanning to the next Beginning-of-slice the
  681.    Picture_Header is reconstructed from the P, TR, FBV, BFC, FFV and FFC
  682.    contained in that packet, and from stream-dependent default values.
  683.  
  684.    For MPEG-2, additional information is needed for the reconstruction.
  685.    This information is provided by the MPEG-2 video specific header
  686.    extension contained in that packet if the T bit is set to 1, or the
  687.    Picture Header for the current picture may be available from previous
  688.    packets belonging to the same picture. The transmitter's strategy for
  689.    inclusion of the MPEG-2 video specific header extension may depend
  690.    upon a number of factors. This header may not be needed when:
  691.  
  692.       1. the information has been transmitted a sufficient number of
  693.       times in previous packets to assure reception with the desired
  694.       probability, or
  695.  
  696.       2. the information is transmitted over a separate reliable
  697.       channel, or
  698.  
  699.       3. expected loss rates are low enough that missed frames are
  700.       not a concern, or
  701.  
  702.       4. conserving bandwidth is more important than error resilience,
  703.       etc.
  704.  
  705.    If T=1 and E=0, there may be extensions present in the original video
  706.    bitstream that are not included in the current packet. The
  707.    transmitter may choose not to include extensions in a packet when
  708.    they are not necessary for decoding or if one of the cases listed
  709.    above for not including the MPEG-2 video specific header extension in
  710.    a packet applies only to the extension data.
  711.  
  712.    If N=0, then the Picture Header from a previous picture of the same
  713.    type (I,P or B) may be used so long as at least one packet has been
  714.    received for every intervening picture of the same type and that the
  715.    N bit was 0 for each of those pictures. This may involve:
  716.  
  717.       1. Saving the relevant picture header information that can be
  718.       obtained from the MPEG-2 video specific header extension or
  719.       directly from the video bitstream for each picture type,
  720.  
  721.       2. Keeping validity indicators for this saved information based
  722.       on the received N bits and lost packets, and,
  723.  
  724.       3. Updating the data whenever a packet with N=1 is received.
  725.  
  726.    If the necessary information is not available from any of these
  727.    sources, data deletion until a new picture start code is advised.
  728.  
  729.  
  730.  
  731. Hoffman, et. al.          Expires October 1997                 [Page 13]
  732.  
  733. Internet-Draft  RTP Payload Format for MPEG1/MPEG2 Video      April 1997
  734.  
  735.  
  736.    Any time an RTP packet is lost (as indicated by a gap in the RTP
  737.    sequence number), the receiver may discard all packets until the
  738.    Beginning-of-slice bit is set.  At this point, sufficient state
  739.    information is contained in the stream to allow processing by an MPEG
  740.    decoder starting at the next slice boundary (possibly after recon-
  741.    struction of the GOP_header and/or Picture_Header as described
  742.    above).
  743.  
  744. References
  745.  
  746.    [1] ISO/IEC International Standard 11172; "Coding of moving pictures
  747.        and associated audio for digital storage media up to about 1,5
  748.        Mbits/s", November 1993.
  749.  
  750.    [2] ISO/IEC International Standard 13818; "Generic coding of moving
  751.        pictures and associated audio information", November 1994.
  752.  
  753.    [3] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson,
  754.        "RTP: A Transport Protocol for Real-Time Applications",
  755.        RFC 1889, January 1996.
  756.  
  757.    [4] H. Schulzrinne, "RTP Profile for Audio and Video Conferences
  758.        with Minimal Control", RFC 1890, January 1996.
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786.  
  787. Hoffman, et. al.          Expires October 1997                 [Page 14]
  788.  
  789. Internet-Draft  RTP Payload Format for MPEG1/MPEG2 Video      April 1997
  790.  
  791.  
  792. Authors' Addresses
  793.  
  794.    Gerard Fernando
  795.    Sun Microsystems, Inc.
  796.    Mail-stop UMPK14-305
  797.    2550 Garcia Avenue
  798.    Mountain View, California 94043-1100
  799.    USA
  800.  
  801.    Phone: +1 415-786-6373
  802.    EMail: gerard.fernando@eng.sun.com
  803.  
  804.  
  805.    Vivek Goyal
  806.    Precept Software, Inc.
  807.    1072 Arastradero Rd,
  808.    Palo Alto, CA 94304
  809.    USA
  810.  
  811.    Phone: +1 415-845-5200
  812.    EMail: goyal@precept.com
  813.  
  814.  
  815.    Don Hoffman
  816.    Sun Microsystems, Inc.
  817.    Mail-stop UMPK14-305
  818.    2550 Garcia Avenue
  819.    Mountain View, California 94043-1100
  820.    USA
  821.  
  822.    Phone: +1 503-297-1580
  823.    EMail: don.hoffman@eng.sun.com
  824.  
  825.  
  826.    M. Reha Civanlar
  827.    AT&T Labs - Research
  828.    101 Crawfords Corner Road, 4C520
  829.    Holmdel, NJ 07733-3030
  830.    USA
  831.  
  832.    Phone: +1 908-949-6705
  833.    EMail: civanlar@research.att.com
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842.  
  843. Hoffman, et. al.          Expires October 1997                 [Page 15]
  844.