[Live-devel] startPlaying - stopPlaying - startPlaying issues

David BERTRAND bidibulle at operamail.com
Thu Feb 23 22:25:37 PST 2006


Thanks for this new release Ross. 
Sorry to disturb you all again with my stopPlaying/startPlaying issue but I found one more (last?) problem to be able to restart playing smoothly after a stopPlaying (sort of pausePlaying):
when calling fRTPInterface.stopNetworkReading() in 
MultiFramedRTPSource::doStopGettingFrames(), you stop handling READ 
events coming from your receiving socket but if your RTP source 
continues to send RTP data, OS buffers for this socket are still 
fed with those data until the buffer max size is reached. When you 
start playing again your MultiFramedRTPSource, you will call again 
fRTPInterface.startNetworkReading(handler) but the first packets 
you will receive will be obsolete RTP packets. I tried to fix this 
by the cleanest way but the only way was to reset socket buffers 
before calling fRTPInterface.startNetworkReading(handler) to be 
sure to receive "fresh data".
I copied-pasted the fix here below but as I agree this fix may seem 
a little bit extreme I would like to know if someone (and of course 
you Ross) has a better solution for this. By the way this "buffer 
reset" should maybe part of a static function in GroupSockHelper. 
Please have a look on it and give me your feelings.

Also I copied-pasted here below another suggestion to improve my 
last patch in Class MultiFramedRTPSource, I forgot to reinitialize 
some private fields in doStopGettingFrames. Sorry for fixing this 
in two times ...

Thanks 

David

patch 1 :
void MultiFramedRTPSource::doGetNextFrame() {
   if (!fAreDoingNetworkReads) {
     // Turn on background read handling of incoming packets:
     fAreDoingNetworkReads = True;
     
     // david 23/02/06 : proposed patch to livemedia : flushing socket OS buffers 
before registering network read handler  
     unsigned char buffer[1000000]; 
        // buffer max size should maybe be determined more properly
     int curFlags = fcntl(fRTPInterface.gs()->socketNum(), F_GETFL, 0);
        // keep track of current socket options

     if (fcntl(fRTPInterface.gs()->socketNum(), F_SETFL, 
curFlags|O_NONBLOCK) < 0)
        // set read mode in non-blocking in case of empty buffer   
       { 
       envir() << strerror(errno);
       }
     
     SOCKLEN_T addressSize = sizeof fRTPInterface.gs()->groupAddress();
     int bytesRead = 0;
     int curBytesRead;
     // read all packets readable on socket
     while ((curBytesRead = 
recvfrom(fRTPInterface.gs()->socketNum(),buffer, sizeof(buffer), 
0,(struct 
sockaddr*)(&fRTPInterface.gs()->groupAddress()),&addressSize)) > 0) 
{ 
     bytesRead += curBytesRead;
     }
     
     if (fcntl(fRTPInterface.gs()->socketNum(), F_SETFL, curFlags) < 0) 
        // restore socket options
     { 
       
       envir() << strerror(errno);
     }
   

     // Now we, can start real network reading ...
     TaskScheduler::BackgroundHandlerProc* handler
       = (TaskScheduler::BackgroundHandlerProc*)&networkReadHandler;
     fRTPInterface.startNetworkReading(handler);
   
     ....


patch 2 :
void MultiFramedRTPSource::doStopGettingFrames() {
    
   fRTPInterface.stopNetworkReading();
   fAreDoingNetworkReads = False;
   
   // david 23/02/06 : proposed patch to liveMedia library
   fCurrentPacketBeginsFrame = True;
   fCurrentPacketCompletesFrame = True;
   fNeedDelivery = False;
   fPacketLossInFragmentedFrame = False;
   
   // optional : Ross, feel free to decide ..
   receptionStatsDB().reset();

   fReorderingBuffer->reset();
  }  


At 07:24 AM 2/14/2006, you wrote:

> Ross,
> I found another issue regarding cascading calls to startPlaying 
> and stopPlaying on the same RTP source.
> In MultiFramedRTPSource::doStopGettingFrames() a reset of the 
> ReorderingPacketBuffer should be done so tat you can restart 
> playing again the same source without waiting for an old 
> "NextExpectedSeqNo" or using an old "fHeadPacket".
> I suggest the following patch :


Thanks for catching this.  This will get included in the next 
software release.


     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



More information about the live-devel mailing list