[Live-devel] StreamReplicator bug deactivating a replica?

[Bruno Abreu]

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 we create 3 replicas (thank you also for the StreamReplicator) from each live source: one for multicast 
streaming, one for unicast streaming and another for video file storing.

Soon after we started using the StreamReplicator we noticed that frequently, when a unicast client closed a session, the whole pipeline 
stopped.

After some debugging I came across the following lines of code which I changed as you can see:

============
--- live-2012.04.27/liveMedia/StreamReplicator.cpp  2012-04-27 20:53:46.000000000 +0100
+++ live-new/liveMedia/StreamReplicator.cpp 2012-04-30 19:25:15.000000000 +0100
@@ -143,16 +143,16 @@
     }
   } else {
     // The replica that's being removed was not our 'master replica', but make sure it's not on any of our queues:
-    for (StreamReplica*& r1 = fReplicasAwaitingCurrentFrame; r1 != NULL; r1 = r1->fNext) {
-      if (r1 == replicaBeingDeactivated) {
-   r1 = replicaBeingDeactivated->fNext;
+    for (StreamReplica** r1 = &fReplicasAwaitingCurrentFrame; (*r1) != NULL; r1 = &((*r1)->fNext)) {
+      if ((*r1) == replicaBeingDeactivated) {
+   (*r1) = replicaBeingDeactivated->fNext;
    replicaBeingDeactivated->fNext = NULL;
    break;
       }
     }
-    for (StreamReplica*& r2 = fReplicasAwaitingNextFrame; r2 != NULL; r2 = r2->fNext) {
-      if (r2 == replicaBeingDeactivated) {
-   r2 = replicaBeingDeactivated->fNext;
+    for (StreamReplica** r2 = &fReplicasAwaitingNextFrame; (*r2) != NULL; r2 = &((*r2)->fNext)) {
+      if ((*r2) == replicaBeingDeactivated) {
+   (*r2) = replicaBeingDeactivated->fNext;
    replicaBeingDeactivated->fNext = NULL;
    break;
       }
============

By using a reference, it's always the head of the list that's updated which, I believe, is not what was meant. If there is (as it happens in 
our case) more than one replica waiting on a frame and the replica being deactivated in not the first on that list, the replicas in front of 
the list are lost.

Now I'm guessing a bit but I believe that then, when the frame finally arrives, the master replica will wait forever for the other replicas to 
ask for the current frame when, in fact, they already did (hence the pipeline halt).

Using the patch above did, at least, fix the symptoms. I don't think all the parentheses I've used are necessary but I like to use them for 
safety.

Thanks in advance for any enlightenment or new release that may fix this issue.
Bruno Abreu


--
Living Data - Sistemas de Informação e Apoio à Decisão, Lda.

Rua Luís de Camões, Nº 133, 1º B      Phone:  +351 213622163
1300-357 LISBOA                       Fax:    +351 213622165
Portugal                              URL: www.livingdata.pt