On 01/22/2013 09:51 PM, Ross Finlayson wrote:
Yes, I agree. In the next version of the software, this piece of code -
in "FileSink::afterGettingFrame()" - will become:
if (fOutFid == NULL || fflush(fOutFid) == EOF) {
// The output file has closed. Handle this the same way as if
the inp
On 01/23/2013 01:27 AM, Ross Finlayson wrote:
We applied a fix to the StreamReplicator to decrease the
fNumDeliveriesMadeSoFar
variable if the replica being deactivated was also receiving a frame.
Ugh. I'm not thrilled by this hack, but right now I don't see a better
solution, so I've gone ahe
On 01/22/2013 09:51 PM, Ross Finlayson wrote:
Yes, I agree. In the next version of the software, this piece of code -
in "FileSink::afterGettingFrame()" - will become:
if (fOutFid == NULL || fflush(fOutFid) == EOF) {
// The output file has closed. Handle this the same way as if
the inp
> 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
>> The right place to be scheduling a new 'playing' task is in your
>> 'after playing' function - i.e., the function that you passed as a
>> parameter when you called "startPlaying()" on your "FileSink"
>> subclass. That 'after playing' function will get called,
>> automatically, when writes to
On Tue, 22 Jan 2013 10:08:49 -0800, Ross Finlayson wrote
> OK, so I'll make that change (changing the order of the calls to
> "onSourceClosure(this);" and "stopPlaying();" in
> "FileSink::afterGettingFrame()") in the next release of the software.
>
> > The main difference - regarding this issue
> 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); andstopPlaying(); so that "stopPlaying()"
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::a
> - sink->fSource = NULL; // indicates that we can be played again
> + // sink->fSource = NULL; // indicates that we can be played again
[...]
> We're just not sure that this is a correct solution
No, it's not.
Instead, try making the following change to "FileSink::afterGettingFrame()"
(lines 13
Hello Ross,
We have been running for some time a RTSPServer that acquires video from a live
source (with our own DeviceSource) from which we create 2 or 3 replicas: one for
multicast streaming and another to feed a FileSink for file storage. The third
replica is created on demand for unicast strea
10 matches
Mail list logo
