Subject: [AVT] Re: RFC 2250 revision

From: Ross Finlayson <[email-masked]>
Date: Thu, 28 Jun 2001 15:34:42 -0700

At 12:07 PM 6/5/01, M. Reha Civanlar wrote:
>Responding to the working group's requests, I am in the process of revising
>RFC 2250, "RTP Payload Format for MPEG1/MPEG2 Video." The following is a
>list of modifications collected since the publication of this RFC. I will
>appreciate receiving comments about the proposed changes and hear other
>requests if any. Thanks for your attention.

As someone who has recently been involved with several implementations of 
RFC 2250 (except for Transport Stream payloads), I'm pleased to hear of 
plans to revise this RFC to improve its clarity.  Along with the 
modifications you noted, I have some additional suggestions:

- First, I'd like to suggest that the document be split into three separate 
RFCs: one for MPEG Transport Streams; one for MPEG Video Elementary 
Streams; one for MPEG Audio Elementary Streams.  These are really three 
separate payload formats, and they have little in common to justify 
including them together in a single RFC.  Moving them to separate RFCs 
would help make it clear that these really are different payload formats, 
and eliminate any possible confusion as to which headers etc. apply to 
which payload format.

Along with this (but beyond the scope of this particular revision), I think 
it would be a good idea to have a future, "Informational" RFC that serves 
as an index for all of the various "MPEG payload formats" for RTP.  This 
document would contain 'pointers' to the collection of MPEG/RTP RFCs:
         - the three RFCs (Transport, Video, Audio) that result from revising
               RFC 2250
         - RFC 3119 (the alternative payload format for MP3 audio)
         - The RTP payload format for MPEG-2 AAC audio (if this becomes
               a RFC)
         - RFC 2343 (the experimental payload format for bundled
              (i.e., audio+video) MPEG)
         - The various MPEG-4/RTP RFCs that are in the pipeline

Returning now to comments about RFC 2250:

Use of the "M" bit in the Video Elementary Stream payload
============================================
The description of the use of the RTP "M" bit for Video Elementary Stream 
payloads is somewhat unclear: "For video, set to 1 on packet containing 
MPEG frame end code, 0 otherwise".  What is the "MPEG frame end code"?  At 
first, I thought that this meant the "video sequence end code".  It was 
only when I reverse-engineered the output from Precept (now Cisco)'s IP/TV 
server that I understood what this really meant.  I suggest changing the 
wording to:

"set to 1 if the packet contains the last slice of a picture (or, if the 
last slice of a picture is is fragmented over multiple packets, the last 
fragment of that slice); set to 0 otherwise."

Frame packetization & fragmentation rules
================================
The description of when multiple frames can (and cannot) be packed into a 
single packet, and how frames can be fragmented over multiple packets, is 
rather confusing, especially for the Video Elementary Stream payload 
format.  I found it difficult to figure out exactly what the allowed 
packing rules are.  I suggest the following rewording:

For the Audio Elementary Stream payload format:
----------
Multiple audio frames MAY be packed - in order - into a single RTP packet, 
provided that all such frames fit inside the RTP packet.  In this case, the 
"Frag_offset" field in the "MPEG Audio-specific header" MUST be set to zero.

If, however, an audio frame is too large to fit inside a single RTP packet, 
it is fragmented across multiple successive RTP packets.  In this case, the 
"Frag_offset" field in the "MPEG Audio-specific header" of each such RTP 
packet is set to the byte offset of the fragment within the entire 
frame.  (Thus, the "Frag_offset" of the first such packet is zero.)  If a 
frame is fragmented across multiple RTP packets, then these packets MUST 
each contain only one fragment (i.e., they MUST NOT be packed with data 
from any other frame).

For the Video Elementary Stream payload format:
----------
Multiple headers (Video_Sequence, GOP, Picture) and "slices" that form a 
Video Elementary Stream MAY be packed - in order - into a single RTP 
packet, provided that the headers will fit inside the RTP packet.  (Slices 
may, however, be fragmented over multiple RTP packets, as described 
below.)  Also, the headers that follow the last slice of each picture MUST 
NOT appear in the same RTP packet as this slice.  Instead, they MUST appear 
in one or more new RTP packets.

If a slice is too large to fit within a single RTP packet, it is fragmented 
across multiple successive RTP packets.  The first such fragment MAY appear 
in the same RTP packet as its preceding header(s), but the second and 
subsequent fragments - including the final fragment - MUST appear by 
themselves in a RTP packet.
----------

         Ross.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www.ietf.org/mailman/listinfo/avt

---

From: "Harsch, Tom" <[email-masked]>
Date: Fri, 29 Jun 2001 11:19:15 -0500

I tend to agree with the part about separating RFC 2250 into multiple parts.
There may not be enough implementations of cetain payload types (e.g., MP2T)
to allow all to advance on the standards track at the same time.

At last report, the MP2T, MP1S and MP2P MPEG video profiles are being
removed from
the RFC 1890 update because two interoperable implementations were not
found.
-- 
Tom Harsch

> -----Original Message-----
> From: Ross Finlayson [mailto:[email-masked]]
> Sent: Thursday, June 28, 2001 4:35 PM
> To: M. Reha Civanlar
> Cc: [email-masked]
> Subject: [AVT] Re: RFC 2250 revision
> 
>