After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 602937 - Can't display video preview when there is no call
Can't display video preview when there is no call
Status: RESOLVED FIXED
Product: empathy
Classification: Core
Component: VoIP
2.29.x
Other Linux
: Normal normal
: ---
Assigned To: empathy-maint
Depends on:
Blocks:
 
 
Reported: 2009-11-25 13:43 UTC by Guillaume Desmottes
Modified: 2011-08-29 10:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
http://git.collabora.co.uk/?p=user/cassidy/empathy;a=shortlog;h=refs/heads/video-preview-602937 (20.02 KB, patch)
2010-02-17 15:17 UTC, Guillaume Desmottes
none Details | Review

Description Guillaume Desmottes 2009-11-25 13:43:35 UTC
Once a call has been terminated, it's not possible to display the video preview until a new call is started. That's because the pipeline is completely destroyed when the call is closed and a new one is recreated later.
We should refactor the pipeline code to be able to always have video preview.
Comment 1 Guillaume Desmottes 2009-12-08 11:26:57 UTC
I started working on this but I'm currently blocked by my misunderstanding of GStreamer.
Currently the pipeline is set to the playing state in empathy_call_window_bus_message when we receive a state-changed message from the pipeline saying that it became "paused".

To be able to display the preview after the call has been terminated, the new pipeline (a new pipeline is created for the future second call after the first one has been terminated) should be set to playing before the new call is started.
What's the best option?

a) Set the newly created pipeline to playing right away? Then, when should we call empathy_call_handler_start_call? It's currently called just before setting the pipeline to playing in  empathy_call_window_bus_message
If we do that, should we start playing the pipeline for the first call as well?

b) Don't start the whole pipeline but only the bits needed to display the preview. I tried but it seems that setting the video_input, preview and video_tee to playing is not enough.

c) other idea?
Comment 2 Guillaume Desmottes 2010-02-17 15:17:32 UTC
Created attachment 154044 [details] [review]
http://git.collabora.co.uk/?p=user/cassidy/empathy;a=shortlog;h=refs/heads/video-preview-602937

 src/empathy-call-window.c |  345 ++++++++++++++++++++++++++-------------------
 1 files changed, 200 insertions(+), 145 deletions(-)
Comment 3 Guillaume Desmottes 2010-03-02 17:35:56 UTC
Let's wait for 2.32 before merging this, it changes a lot of code.
Comment 4 Olivier Crête 2010-03-30 21:54:13 UTC
Some comment son the branch,

call-window: factor out create_pipeline (and other patches
split create_video_output_widget out of create_pipeline:
- g_object_unref (bus); -> gst_object_unref (bus); (its a GstObject)

Actually turn off the camera when preview/sending is disabled:
- Avoid the gst_*_many functions, they don't report errors. You want to to add and link them them one by one and check for errors using gst_bin_add and gst_element_link

The rest looks fine to me.
Comment 5 Guillaume Desmottes 2010-03-31 13:14:24 UTC
(In reply to comment #4)
> Some comment son the branch,
> 
> call-window: factor out create_pipeline (and other patches
> split create_video_output_widget out of create_pipeline:
> - g_object_unref (bus); -> gst_object_unref (bus); (its a GstObject)

According to Sjoerd gst_object_unref isn't needed any more. 

> Actually turn off the camera when preview/sending is disabled:
> - Avoid the gst_*_many functions, they don't report errors. You want to to add
> and link them them one by one and check for errors using gst_bin_add and
> gst_element_link

Done.

I fixed few more issues, see the 6 top commits of
http://git.collabora.co.uk/?p=user/cassidy/empathy;a=shortlog;h=refs/heads/video-preview-602937

Also, according my understanding of the doc of gst_element_get_request_pad (), we should callgst_element_release_request_pad () and gst_object_unref() once we're done with the pad. Is that right?
Comment 6 Olivier Crête 2010-03-31 15:22:59 UTC
(In reply to comment #5)
> (In reply to comment #4)
> Also, according my understanding of the doc of gst_element_get_request_pad (),
> we should callgst_element_release_request_pad () and gst_object_unref() once
> we're done with the pad. Is that right?

Yes, you can unref the pad as soon as you don't have a pointer to it. You only have to release it if you want to get it of it before its parent element.
Comment 7 Guillaume Desmottes 2010-03-31 15:49:49 UTC
Done:
http://git.collabora.co.uk/?p=user/cassidy/empathy;a=commitdiff;h=a177b40ac1b43beedf68fdb4e9254be6f2e5fd2c

Not sure if we should release in that case.

Any other comment regarding the branch?
Comment 8 Guillaume Desmottes 2010-04-01 08:16:20 UTC
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.