[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