Subject: [AVT] Clarification regarding rfc 2250

From: Sridhar <[email-masked]>
Date: Fri, 15 Apr 2005 19:09:10 +0530

Hello All,

i need your help in clarifying a doubt that i have in rfc 2250.

we are currently working to package mpeg audio streams using rtp and 
hence we are trying to provide an implementation in which concepts of 
rfc 2250 are incorporated.

=====================================================================

we have a transport packet whose structure is as follows:

(a) rtp-header (12 bytes) as specified in section 5.1 of rfc 1889.
     here we dont have any CSRC identifiers.
(b) this is followed by the 4 byte header MPEG Audio-specific header
     as specified in section 3.5 of rfc 2250
(c) this is followed by mpeg frame(s)

(b) and (c) is henceforth referred as media payload

=====================================================================

scenario (i) : no fragmentation, i.e. there are 1 or more
(integral) number of mpeg frames present in the transport packet.
in this case

+ we have rtp 12 byte header filled with some details
+ MPEG Audio-specific header (as per para 2 of section 3.2
   of rfc 2250) is as follows :
   MBZ == 0 and Frag_Offset == 0
+ followed by one or more frames mpeg audio frames

=====================================================================

scenario (ii) : fragmentation, i.e. one mpeg audio frame is
split into multiple transport packets.
lets take an example of an mpeg audio frame being 414 bytes
long (just an example) and the transport packet being limited
to a maximum of 200 bytes.

first packet
------------
+ we have rtp 12 byte header filled with some details
+ MPEG Audio-specific header (as per para 2 of section 3.2
   of rfc 2250) is as follows :
   MBZ == 0 and Frag_Offset == 0
+ followed by the first fragment of the audio frame which is
   187 bytes
+ total size of the transport packet == 200

second packet
------------
+ we have rtp 12 byte header filled with some details
+ MPEG Audio-specific header is as follows :
   MBZ == 0 and Frag_Offset == 187
+ followed by the second fragment of the audio frame which is
   187 bytes
+ total size of the transport packet == 200

third packet
------------
+ we have rtp 12 byte header filled with some details
+ MPEG Audio-specific header is as follows :
   MBZ == 0 and Frag_Offset == 374
+ followed by the third fragment of the audio frame which is
   40 bytes
+ total size of the transport packet == 53

=====================================================================

question-1 > is my understanding correct in the fragmentation
case ?

=====================================================================

question-2 > if the answer to question-1 is yes, i would like
know the following from the perspective of implementation.

In order to detemine whether the media payload of rtp contains a 
fragmented packet we have to
(i)  examine if Frag_offset == 0
(ii) if this is so, we may be faced with a case of either
      (a) no fragmentation case or
      (b) first fragment of a frame.
      now one of (a) or (b) can be ascertained only by
      1. peeking into mpeg header,
      2. determining the frame length
      3. comparing the frame length with the transport packet length
         if (frame length > transport packet length)
         then we have (b)
         else we have (a)

There are two issues that we face here, these are
I1) in the normal case where we would have no fragmentation, we have to
     perform the compute intensive frame header parsing and frame length
     calculation for every rtp packet
I2) This also restricts that we should minimally have to have the mpeg
     frame header in the fragment (which is quite acceptable except in
     very rare transport protocol limitation cases).

primarily is there a way to overcome I1, i.e. find out if a have a mpeg
fragment without computing the frame size (using the frame header and
comparing this to the transport packet size) ?

=====================================================================

i would be extremely grateful to anybody who could spend some time to 
respond to this query of mine.

thanking you
with regards
k. sridhar

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

---

From: Ross Finlayson <[email-masked]>
Date: Fri, 15 Apr 2005 21:20:43 -0700

>(a) rtp-header (12 bytes) as specified in section 5.1 of rfc 1889.

FYI, RFC 1889 has been obsoleted by RFC 3550 (although that has no 
relevance to the rest of your question).

>to a maximum of 200 bytes.

Your math is a little off here.  If your UDP payload is limited to 200 
bytes, then - after allowing for the RTP header (12 bytes) and MPEG 
audio-specific header (4 bytes) - you have 184 bytes left for the MPEG 
audio frame data.

>know the following from the perspective of implementation.

Yes, you have discovered the 'dirty little secret' about RFC 2250: The 
"Frag_offset" field in the MPEG audio-specific header is close to useless, 
because:
1/ (As you discovered) it doesn't tell you whether or not a packet with 
"Frag_offset == 0" contains one or more complete frames, or is instead the 
start of a single fragmented frame.
2/ It doesn't tell you whether or not a packet (regardless of the value of 
the "Frag_offset" field) contains the *end* of an audio frame.
3/ If a packet containing the start of a fragment was lost, then any 
following fragments are going to be completely useless to a decoder 
(because of the structure of MPEG audio frames), so it doesn't matter at 
all that the "Frag_offset" field tells the receiver exactly where in the 
frame the received data would belong.

Quite frankly, I'm amazed that this design made it through the working 
group and IESG.  But we're now stuck with it.

Fortunately, fragmentation rarely occurs, because every legal MPEG audio 
frame sze is < 1500 bytes, which is what most systems use as the maximum 
size of a RTP packet.

In fact, every receiver implementation of RFC 2250 audio that I'm aware of 
just ignores the "Frag_offset" field, and delivers all received data 
straight to the MPEG audio decoder, regardless of the value of "Frag_offset".

         Ross.

---

From: Sridhar <[email-masked]>
Date: Tue, 19 Apr 2005 10:24:03 +0530

Thank you,

> audio-specific header (4 bytes) - you have 184 bytes left for the MPEG 

Oops sorry about this.

> "Frag_offset" field in the MPEG audio-specific header is close to 
> useless, because:
> "Frag_offset == 0" contains one or more complete frames, or is instead 
> the start of a single fragmented frame.
> 2/ It doesn't tell you whether or not a packet (regardless of the value 
> of the "Frag_offset" field) contains the *end* of an audio frame.
> In fact, every receiver implementation of RFC 2250 audio that I'm aware 
> of just ignores the "Frag_offset" field, and delivers all received data 

i shall also do the same in our implementation.
thanks once again for the detailed clarification

sridhar