[AVT] Clarification regarding rfc 2250

[Sridhar <ksridhar at impulsesoft.com>]

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
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt