[Live-devel] Query on AMRDeinterleaver::deliverIncomingFrame
changchun.zhang at tektronix.com
changchun.zhang at tektronix.com
Thu Jan 21 22:46:45 PST 2010
Thanks Ross.
I now do see that there is a while loop in the
MultiFramedRTPSource::doGetNextFrame1 and the
BufferedPacket::use is used in the loop to travers all the frames in the single packet unitl this packet is used out.
Also the afterGetting(this) is called in this loop to ensure that " each "RawAMRRTPSource"
delivers only one AMR frame at a time to its downstream object (an
"AMRDeinterleaver"),"
Am I right?
B.R,
Changchun (Alex)
-----Original Message-----
From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Thursday, January 21, 2010 8:37 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Query on AMRDeinterleaver::deliverIncomingFrame
>Have someone tested the functions used to deinterleave multi AMR
>frames in a single RTP packet? Here I have a question on the method
>AMRDeinterleave::deliverIncomingFrame.
>I suspect this method can only support the scenario that one RTP
>packet contains only one AMR frame.
No. Although our current implementation supports only the
transmission of only one AMR frame in each RTP packet
("AMRAudioRTPSink"), it *does* support the reception (and
deinterleaving) of multiple frames in each RTP packet. It does this
by redefining the virtual function "nextEnclosedFrameSize()" (in the
class "AMRBufferedPacket"). Because of this, each "RawAMRRTPSource"
delivers only one AMR frame at a time to its downstream object (an
"AMRDeinterleaver"), regardless of how many AMR frames were actually
present in the incoming RTP packet.
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
More information about the live-devel
mailing list