Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#12758 closed patch (fixed)

Hanging up a video call freezes other running calls

Reported by: haakon Owned by: Maiku
Milestone: 2.7.10 Component: Voice and Video
Version: 2.7.3 Keywords:

Description (last modified by darkrain42)

Steps to reproduce:

  • start two parallel video calls
  • end one of these calls
  • you can still see and hear participant from the second call, but your voice and video is not sent to him anymore

Problem seems to be in purple_media_backend_fs2_dispose(), where calling

gst_element_set_state(GST_ELEMENT(priv->confbin), GST_STATE_NULL);

causes that media sources stop sending data.

I was able to fix this problem by doing this:

  • gst_object_ref() the confbin we are going to remove
  • remove confbin from the pipeline without setting its state to NULL
  • set confbin state to NULL
  • unreference the element so it gets disposed

Please see attached patch.

Attachments (3)

purple_media_fs2_dispose.patch (576 bytes) - added by haakon 9 years ago.
purple_media_fs2_dispose_2.patch (3.1 KB) - added by haakon 8 years ago.
Corrected version
dynamicpipe.c (2.4 KB) - added by haakon 8 years ago.
Dynamic pipeline demonstration

Download all attachments as: .zip

Change History (12)

Changed 9 years ago by haakon

comment:1 Changed 8 years ago by QuLogic

  • Milestone set to Patches Needing Review

comment:2 Changed 8 years ago by darkrain42

  • Description modified (diff)

comment:3 Changed 8 years ago by darkrain42

I guess this looks OK, but it's far beyond my knowledge of gstreamer, and I'd prefer someone knowledgeable about Gstreamer look at it.

comment:4 Changed 8 years ago by haakon

The original version of the patch did not fix the problem, it accidentally worked when "videotestsrc" was used, but when I now plugged in a real webcam, simultaneous call freezes again as described earlier.

After some more investigations in docs and mailing lists it seems to me that right way how to unplug elements from running pipeline it to block the corresponding src pad of audio or video source bin, right before confbin is unlinked.

New patch that I am attaching worked OK with every configuration of media sources I have tried so far. Please ignore the original file.

Changed 8 years ago by haakon

Corrected version

comment:5 follow-up: Changed 8 years ago by darkrain42

For the reference of people like me who know little about gstreamer, do you have pointers to the documentation that lead you to this conclusion?

My previous comment applies here (the updated patch looks fine, caveat etc)

comment:6 in reply to: ↑ 5 Changed 8 years ago by haakon

Replying to darkrain42:

do you have pointers to the documentation that lead you to this conclusion?

There is not much official documentation for this, probably the most relevant is this design document (see "dynamically switching an element in a PLAYING pipeline" section near the end)

Here is a mailing post of someone trying to solve similar problem with dynamic adding/removing elements from running pipeline, suggesting solution using gst_pad_set_blocked()

And finally I attached a minimalistic demonstration program that I used for my own experiments. When run, randomly attaches and detaches xvimagesinks displaying a test pattern from videotestsrc. The playback should run constantly and never stop.

Changed 8 years ago by haakon

Dynamic pipeline demonstration

comment:7 Changed 8 years ago by rekkanoryo

  • Milestone changed from Patches Needing Review to 2.7.10

comment:8 Changed 8 years ago by jakub.adam@…

  • Resolution set to fixed
  • Status changed from new to closed

(In a0565ad3f3685a23a6b4e17e0197799f61d8f74e):
This patch fixes #12758.

If the user starts two parallel video calls, then ends one of them some time later, the user can still see and hear the participant from the non-ended call, but the other participant no longer receives the user's video or audio. The problem lies in purple_media_backend_fs2_dispose(), which calls gst_element_set_state() in such a way that the media sources stop sending data.

Additional reference information is mentioned on #12758, comment 6 (

comment:9 Changed 8 years ago by rekkanoryo@…

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!