[Live-devel] fNumFramesUsedSoFar and MutiFramedRTPSink

[David BERTRAND]

> Unfortunately I'm still not seeing any problem with
> this.  "sendNext()" calls "buildAndSendFrame()", which in turn resets
> "fNumFramesUsedSoFar" to zero.
True, but then later if a frame is got (in afterGettingFrame), fNumFramesUsedSoFar is incremented. It is then sent but "fNumFramesUsedSoFar" keeps its value until sendNext() is called again. So if ourHandleCLosure is called (before the new call to sendNext()), "fNumFramesUsedSoFar" equals 1. 
I added "fNumFramesUsedSoFar=0" just after sending the packet and my problem was fixed.
David
> ----- Original Message -----
> From: "Ross Finlayson" <finlayson at live555.com>
> To: "LIVE555 Streaming Media - development & use" <live-devel at ns.live555.com>
> Subject: Re: [Live-devel] fNumFramesUsedSoFar and MutiFramedRTPSink
> Date: Tue, 09 May 2006 13:14:05 -0700
> 
> 
> 
> > _Im not sure if this is clear but to say it another way : if our input
> > source closes between a nextSend event that led to a frame sending
> > (afterGettingFrame OK) and a nextSend event scheduled but that could not
> > reset fNumUsedFramedSofar yet, we have a problem.
> 
> Unfortunately I'm still not seeing any problem with
> this.  "sendNext()" calls "buildAndSendFrame()", which in turn resets
> "fNumFramesUsedSoFar" to zero.  So even if "sendNext()" ends up
> getting called after "ourHandleClosure()", "fNumFramesUsedSoFar" will
> still always have the correct value.
> 
> 
> 	Ross Finlayson
> 	Live Networks, Inc. (LIVE555.COM)
> 	<http://www.live555.com/>
> 
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel

>


-- 
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 8 at http://www.opera.com

Powered by Outblaze