[Pidgin] #13237: Use Gstreamer event probe instead of pad blocking when removing ended call from pipeline

[Pidgin]

#13237: Use Gstreamer event probe instead of pad blocking when removing ended call
from pipeline
-----------------------------------------+----------------------------------
 Reporter:  haakon                       |     Owner:  Maiku
     Type:  patch                        |    Status:  new  
Component:  Voice and Video              |   Version:  2.7.9
 Keywords:  event probe d unlink callpa  |  
-----------------------------------------+----------------------------------
 This ticket relates to #12758.

 Although my proposed solution with calling gst_pad_set_blocked() before
 unlinking the pad was correct for most of the situations, there are rare
 cases when the pad blocking call will never return and hang the whole
 application. That's because to make gst_pad_set_blocked() succeed, data
 buffers MUST be flowing through the pipeline. I found it out when I
 discovered this post from Håvard Graff from Tandberg on gstreamer-devel
 mailing list:

 ----

 The problem with the "block-pad" soultion is that you are dependant of
 getting another buffer on the tee srcpad after you block it. If this is no
 problem, then this solution is the easiest one. If there is a chance no
 more buffers will arrive on the src-pad you can do:

  1. Attach an event-probe to the tee srcpad you want to unlink.
  2. Send a custom downstream serialized event on the tee sinkpad
  3. Inside the callback of the event-prove, confirm the arrival of your
 custom event and:
    a. Unlink the branch from the tee srcpad
    b. remove the probe
    c. release the tee srcpad (note that this is actually safe to do inside
 the callback!)
    d. return FALSE (so you don't pass that event downstream)

 For us this is absolutely necessary, since the call can be ended at any
 time, and hence you can't know if you get another buffer.

 ([http://web.archiveorange.com/archive/v/8yxpzgdSQWgHNM8zknYz Full
 discussion thread])

 ----

 I tried to simulate pipeline without flowing buffers by running video call
 with unplugged camera and ended up with frozen Pidgin, forever waiting for
 gst_pad_set_blocked() to complete (because of no data flowing through the
 pads), so the statement above is correct. When I implemented the described
 event-probe technique, the call correctly hangs up because of missing
 webcam and no freeze occurred.

 Sorry to reopen this issue, but documentation about this area is sparse
 and key facts are discovered by accident. Attached patch works in every
 case the previous one did + will not hang the IM client in above described
 situations. It can be applied without reverting the previous changes.

-- 
Ticket URL: <http://developer.pidgin.im/ticket/13237>
Pidgin <http://pidgin.im>
Pidgin