Hi Ross,
thank you for your quick reply.
And sorry for taking so long to get back to you. We've been dealing with some
other issues that arose regarding this problem (see below).
On Thu, 10 Jan 2013 11:00:43 -0800, Ross Finlayson wrote
> Instead, try making the following change to
> "FileSink::afterGettingFrame()" (lines 130-132 of
> "liveMedia/FileSink.cpp"): Change the order of the calls to
> onSourceClosure(this); and stopPlaying(); so that "stopPlaying()"
> is called first, before "onSourceClosure(this)".
>
> Let us know if this works for you. (If so, I'll make the change in
> the next release of the software.)
1.
Yes and no. It did work on the testReplicator app, but on our server a new issue
surfaced. We started getting "Internal Error" messages from the
StreamReplicator:
StreamReplicator::deliverReceivedFrame() Internal Error 2(2,2)!
...
StreamReplicator::deliverReceivedFrame() Internal Error 2(3,2)!
...
StreamReplicator::deliverReceivedFrame() Internal Error 2(4,2)!
...
And, soon enough our DeviceSource would stop working, making all sinks stop,
also.
The main difference - regarding this issue - between our server and the
testReplicator app is that, after an error occurs trying to write a video file,
we schedule the writing to start again at a later time. We do that by overriding
the MediaSink::stopPlaying method in our own FileSink class:
virtual void stopPlaying() {
MediaSink::stopPlaying();
// schedule to restart in 10 secs
envir() << "OurFileSink stopped! Scheduling to restart in 10 secs.\n";
envir().taskScheduler().scheduleDelayedTask(10000000,
(TaskFunc *) OurFileSink::startPlaying, this);
}
We added this functionality to the testReplicator app and tested again. Oddly
enough, we didn't get any error messages, nor did the multicast streaming stop
playing. So, we delved in a little dipper:
By examining the StreamReplicator error messages it soon became clear that with
each deactivation/reactivation of the FileSink replica the
fNumDeliveriesMadeSoFar variable would increase beyond the number of active
replicas. We then added and ID to StreamReplica class in order to make it easier
to tell which replica was doing what and populated the StreamReplicator with
debug messages. We found the StreamReplica ID particularly useful. Something you
may wish to add at a later time.
By examining the behavior of the replicas we were able to determine that our
FileSink replica was being deactivated while executing
StreamReplicator::deliverReceivedFrame(), because, when
FramedSource::afterGetting(replica), on line 259, was called, the write error
would occur again. Upon returning to StreamReplicator::deliverReceivedFrame(),
the fNumActiveReplicas would have been decreased an so, the condition
(fNumDeliveriesMadeSoFar == fNumActiveReplicas - 1 && fMasterReplica != NULL) on
line 262 would never be met.
We applied a fix to the StreamReplicator to decrease the fNumDeliveriesMadeSoFar
variable if the replica being deactivated was also receiving a frame. I'm
attaching the StreamReplicator class with our patches and newest version of the
testReplicator app with a FileSink extension.
With these changes our server is now working as expected.
2.
Also, we needed to change the visibility of the FileSink::continuePlaying()
method to protected, because, upon restarting to write we are also bypassing
some frames on H264 ES video file output by calling it until the metadata frames
come up. Could you please apply this change?
Thank you for all your attention
Bruno Abreu
--
Living Data - Sistemas de Informação e Apoio à Decisão, Lda.
LxFactory - Rua Rodrigues de Faria, 103,
edifício I - 4º piso Phone: +351 213622163
1300-501 LISBOA Fax: +351 213622165
Portugal URL: www.livingdata.pt
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
