[Live-devel] about the rtp payload for mpa

Ross Finlayson finlayson at live555.com
Thu Apr 15 14:02:24 PDT 2010


>     I have some questions about the rtp payload for mpa(type is 14) 
>when i use testOnDemandRTSPServer to stream mp3 file.When i capture 
>packet via Wireshark(an network capture tools), on the rtp layer, 
>the payload of the rtp packet is composed of audio frames.It 
>strongly trouble me thatthe composed way. Sometimes, 3 or 4 auido 
>frames are involved and the total length is nearly the 
>MTU(1350Bytes).But sometimes, only 2 audioframes are involved and 
>the total length is far below the MTU, and i think next audio frame 
>can be involved because there is enough space.

The RTP packaging code "MultiFramedRTPSink" usually fits as many 
frames as possible within each outgoing packet.  However - to use 
your example - if it has already packed 2 frames into a packet, it 
will send the packet immediately if it thinks that the 3rd frame 
(that it has not yet seen) will overflow the packet.  It does this by 
looking at the size of the most recently packed packet (the 2nd, in 
this case), and guessing that the 3rd frame will likely be the same 
size.  If another frame of the same size would overflow the packet, 
then the packet will be sent immediately, without waiting for the 3rd 
packet to arrive.  This is for efficiency; if the 3rd frame would 
indeed overflow the packet, then it would be somewhat inefficient to 
have to buffer its data to use later.  But if the 3rd frame in fact 
would *not* have overflowed the packet, then yes, we will send a 
packet that's somewhat smaller than it could have been.  (But this 
doesn't really matter; this should not "strongly trouble" you.)

Note that this is only an issue for VBR streams, because those are 
the only streams for which the frame sizes can vary.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/


More information about the live-devel mailing list