OUTDATED -------- case 1) (--------) (--------) (--------) ! fakesrc! !identity! !fakesink! ! src ----- sink src ---- sink ! (--------) (--------) (--------) fakesrc detects the end of stream. It just sent the last buffer and sets the srcpad to EOS with gst_pad_eos (). gst_pad_eos() will notify the parent about the plugins attempt to signal eos. the parent adds the element to its possible EOS providers. gst_pad_eos() will by default propagate to identy and to fakesink. none of these plugins override the default behaviour so gst_pad_eos returns TRUE and fakesrc signals EOS with the value TRUE. The parent looks in the list of EOS providers and finds the faksrc element that is now signaling EOS. all EOS providers are now in EOS and so the bin fires EOS. case 2) (---------------) !thread ! (--------) (--------) (--------) ! (--------)! ! fakesrc! !identity! ! queue ! ! !fakesink!! ! src ----- sink src ---- sink src ---- sink !! (--------) (--------) (--------) ! (--------)! (---------------) fakesrc detects the end of stream. It just sent the last buffer and sets the srcpad to EOS with gst_pad_eos (). gst_pad_eos() will notify the parent about the plugins attempt to signal eos. the parent adds the element to its possible EOS providers. gst_pad_eos() will by default propagate to identy and to queue. queue overrides the eos handler and returns false on the eos request. fakesrc signals EOS with a value of false and the parent bin removes the EOS provider from its list. after the queue has sent out the last buffer, its calls eos on its src pad. queue is added to the top level bin as an eos provider and the default eos handler signals EOS with a value of TRUE to the parent. the parent sees that all the eos providers are in eos now and signals EOS. case 3) (---------------) !thread ! (--------) (--------) (--------) ! (--------)! ! fakesrc! ! tee ! ! queue1 ! ! !fakesink!! ! src ----- sink src ---- sink src ---- sink !! (--------) ! ! (--------) ! (--------)! ! ! (---------------) ! ! ! ! (---------------) ! ! !thread ! ! ! (--------) ! (--------)! ! ! ! queue2 ! ! !fakesink!! ! src ---- sink src ---- sink !! ! ! (--------) ! (--------)! (--------) (---------------) fakesrc 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 both queues return false on the eos request. the parent removes fakesrc as an EOS provider. queue1 and queue2 were responsible for the EOS delay and so they get added to the bin as possible EOS providers. after the queues have sent out their last buffer, they calls eos on their src pads. the parent already has the two queues in the EOS provider list so they dont get added twice. the two queues perform gst_pad_eos () on their pads when the queue is empty, the parent removes the EOS providers from its list, when the list is empty, the parent fires EOS. case 4) (---------------) !thread ! (--------) (----------) (--------) ! (--------)! ! fakesrc! !mpeg1parse! ! queue1 ! ! !fakesink!! ! src -- sink src ---- sink src ---- sink !! (--------) ! ! (--------) ! (--------)! ! ! (---------------) ! ! ! ! (---------------) ! ! !thread ! ! ! (--------) ! (--------)! ! ! ! queue2 ! ! !fakesink!! ! src ---- sink src ---- sink !! ! ! (--------) ! (--------)! (----------) (---------------) this case differs from case3 in that one of the queues can be empty while the other isn't. we assume queue1 is empty while queue2 isn't yet. fakesrc 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 queue2 returns false on the eos request. the parent removes fakesrc as an EOS provider. queue2 was responsible for the EOS delay and so it gets added to the bin as a possible EOS provider. after the queue2 has sent its last buffer, it performs gst_pad_eos on its src pad. the parent already has the queue2 in the list of EOS providers so it does not get added twice. queue2 finally fires the EOS signal and the parent removes the EOS provider from its list, when the list is empty, the parent fires EOS. case 5) (--------) (--------) (--------) ! disksrc! ! mad ! !filesink! ! 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, filesink returns false on the eos request. the parent removes mad as an EOS provider. filesink was responsible for the EOS delay and gets added to the bin as a possible EOS provider. When filesink has written all of it's data and closed the output file, it fires EOS. The parent already has filesink 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 ! (--------) (--------) (--------) ! ! !filesink! ! 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, filesink will return false, mixer will be removed as an eos provider, and filesink 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.