[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