Hi,
since we only have one audio stream but two video streams available on the wifi
cameras, as we wrote some time ago,
we have now integrated a stream replicator as recommended and create a separate
replicate for both video streams.
However, the stream replicator is now permanently consuming th
Bruno,
Thanks for the report. This will be fixed in the next release of the software.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-
Hello Ross,
we've been facing occasional frame delivery stops when using StreamReplicator
with 3 replicas. We know this happens when one of the replicas is being
removed, another is being held as the master replica and the third one as
already received the current frame.
Internal state of the rep
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
> After some days of testing I'm afraid I'm now pretty sure this solution
> (released on 2012.05.03) is still buggy.
Yes, you're right. (Stupidity on my part...)
I've now released a new version of the code that includes your proposed
solution. Thanks again for your help.
Ross Finlayson
Live
On 05/01/2012 02:32 AM, Ross Finlayson wrote:
Try replacing those two "for" loops with the following:
for (StreamReplica* r1 = fReplicasAwaitingCurrentFrame; r1 != NULL;) {
if (r1 == replicaBeingDeactivated) {
if (r1 == fReplicasAwaitingCurrentFrame) fReplicasAwaitingCurrentFrame =
r
Hello Ross,
sorry for the late reply.
I'm afraid replacing the 2 "for" loops with the code you provided
generates a segmentation fault in our app.
Of course, it may be something in our application so I'll run more tests
today and will provide you with more information as soon as I can.
Than
Thanks for the report. Yes, there is a bug in that code, although it wasn't
quite what you thought. Try replacing those two "for" loops with the following:
for (StreamReplica* r1 = fReplicasAwaitingCurrentFrame; r1 != NULL;) {
if (r1 == replicaBeingDeactivated) {
if (r1 == fRe
Hello Ross and everyone
I never got to thank you for fixing the race condition in
H264VideoFileServerMediaSubsession and MPEG4VideoFileServerMediaSubsession
(release
2011.06.14) so, thank you very much for that one.
I believe I came across another bug.
We are running an application in which w
> I create the replicator with the false option to avoid it deletes the input
> Source when removing all replicas.
> StreamReplicator::createNew(*env, Source, false)
>
> then create the source to feed it into the sink
> FramedSource* source = replicator->createStreamReplica();
>
> What would
Hi Ross
I create the replicator with the false option to avoid it deletes the input
Source when removing all replicas.
StreamReplicator::createNew(*env, Source, false)
then create the source to feed it into the sink
FramedSource* source = replicator->createStreamReplica();
What would be the best
Mike,
Thanks for noticing this bug. Your suggested fix looks good, and will be
included in the next release of the software.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-devel mailing list
live-devel@lists.live555.com
http://l
Hello All,
I have been looking at the new StreamReplicator class and find I am
hitting the 'Internal Error 2' logging in
StreamReplicator::deliverReceivedFrame() when a StreamReplica is removed
whilst another remains active.
This could be due to a double-decrement of fNumActiveReplicas as
S
22 matches
Mail list logo
