added two more cases of eos reasoning

Original commit message from CVS:
added two more cases of eos reasoning

docs/random/eos

@@ -131,3 +131,76 @@ case 4)
 
   
 
+case 5) 
+
+ (--------)         (--------)         (--------) 
+ ! disksrc!         !  mad   !         !disksink! 
+ !       src ----- sink     src ---- sink       ! 
+ (--------)         (--------)         (--------)
+
+
+  disksrc detects the end of stream. It just sent the last buffer
+  and sets the srcpad to EOS with gst_pad_eos ().
+
+  the eos handler returns false because mad returns false on the
+  eos request. the parent removes mad as an EOS provider.
+
+  mad was responsible for the EOS delay and so it gets added to the bin 
+  as a possible EOS provider.
+
+  After mad has sent its last buffer, it performs gst_pad_eos on its
+  src pad.
+  the parent already has mad in the list of EOS providers so it does not
+  get added twice.
+  mad finally fires the EOS signal.  This time, disksink returns false on
+  the eos request.  the parent removes mad as an EOS provider. 
+  
+  disksink was responsible for the EOS delay and gets added to the bin
+  as a possible EOS provider.
+  When disksink has written all of it's data and closed the output file,
+  it fires EOS.
+  The parent already has disksink in the list of EOS providers so it does
+  not get added twice.
+  The parent removes the EOS provider 
+  from its list, and since the list is empty, the parent fires EOS.
+
+case 6) 
+
+ (--------)         (--------)         (--------) 
+ !disksrc1!         !  mad1  !         ! mixer  ! 
+ !       src ----- sink     src ---- sink1      !        (--------)
+ (--------)         (--------)         !        !        !disksink!
+                                       !       src ---- sink      !
+ (--------)         (--------)         !        !        (--------)
+ !disksrc2!         !  mad2  !         !        ! 
+ !       src ----- sink     src ---- sink2      ! 
+ (--------)         (--------)         (--------)
+
+  In this case, we want to make sure the pipeline keeps running after one
+  of the two sources reaches eos.  Suppose in this case that disksrc1 will
+  reach eos first.
+
+  disksrc1 detects the end of stream. It sets eos, mad1 will return false,
+  and mad1 will be responsible for eos.  When mad1 had sent out the last
+  buffer, it sends out eos.
+
+  The mixer intercepts eos and returns false.  mad1 is removed from the
+  eos providers and mixer is added.
+
+  (At this point, the mixer might choose to disconnect mad1->src and
+  mixer->sink1 pads, since it's received eos on mad1->src)
+
+  mixer will not send out eos since it hasn't received eos from 
+  mad2->src.
+
+  After a while, disksrc2 will detect end of stream, and eos will finally
+  propagate to mixer.  mixer might disconnect mad->src2, and after
+  realizing all of it's sources have reached eos, it sends out the final
+  buffer and fires EOS.
+
+  At this point, disksink will return false, mixer will be removed as an
+  eos provider, and disksink will write out it's final buffer and close
+  the file on disk.  At this point, it fires eos, and since it's the last
+  eos provider, the parent can fire eos.
+
+