GNOME Bugzilla – Bug 595251
gabble video gets stuck
Last modified: 2010-10-19 13:34:57 UTC
I'm trying to get working empathy<->empathy video between my desktop and notebook (over XMPP). Both have recent (one trunk, one 2.27.92+video fix) versions of empathy and latest farsight2 and telepathy-farsight releases. Desktop has a cam, notebook does not. The problem: if I initiate the video chat from either side (does not matter) I see the local cam picture on the desktop but only a black picture on the notebook. If I disable video (on the desktop) and re-enable it right away, the notebook displays one frame but seems to get stuck. I will attach the logs from both sides with accounts changed to AAA (desktop) and BBB (notebook).
Created attachment 143217 [details] Desktop empathy log
Created attachment 143218 [details] Desktop gabble log
Created attachment 143219 [details] Notebook gabble log
Created attachment 143220 [details] Notebook empathy log
Created attachment 143221 [details] Notebook gabble log
Thanks for your bug report Michael. Is audio working?
Also, could you try to reproduce this issue with our echo bot and tell us how it works? echo@test.collabora.co.uk
Hmm I tested again, empathy 2.28.1.1 running on both ends now. 1 Voice calls seem to work for a short while before the laptop side freezes (which looks to be a pulseaudio problem). 2 calling the echo test from desktop seems to work fine. 3 calling the echo test from the laptop makes pulseaudio use 100% cpu and freezes empathy... seems to be the same as 1 4 Video calls regressed further. As soon as I accept the video call (on either side, does not matter), Empathy crashes on the *desktop* (which is the one that has webcam) The laptop is running older pulseaudio which may be the problem regarding audio. The video crash seems to be another problem though...
Just in case you wonder, laptop has pulseaudio-0.9.15, desktop is already at pulseaudio-0.9.19.
Interesting. Your sound problem is probably because of the older pulseaudio; you should really upgrade to 0.9.19. Could you attach Empathy logs on the desktop side (when crashing) and a stack trace please?
(In reply to comment #10) > you should really upgrade to 0.9.19. Well, that's not really an option right now but that's fine. I can test with up-to-date packages using Fedora 12 live on this system. With this (meaning both systems use exactly the same tp and pulse versions) audio calls work fine (speach quality is bad but I guess I could fix this with a better mic). As for video calls, I can initiate them just fine from the laptop side but I just get a black image now (sound still works). When opened from the desktop side, the desktop client still crashes as soon as I accept on the remote side. I guess what you need is a stack trace of empathy's crash on desktop? telepathy-gabble is still running after the crash btw.
Created attachment 146997 [details] Backtrace This is a backtrace of the empathy crash. Do I actually need to install more debuginfo?
This crash is in your H264 encoder; not empathy.
(In reply to comment #13) > This crash is in your H264 encoder; not empathy. Eh... and that would be gst-plugins-ugly? Well, I really wonder why empathy uses H264 anyway?
Because if H264 is installed Empathy will use it (it's needed for Google video for example).
(In reply to comment #15) > Because if H264 is installed Empathy will use it (it's needed for Google video > for example). None of my test accounts have been @google ones... can't you just use theora for non @google communication? x264enc seems to come from gst-plugins-ugly (0.10.12-4.fc12.i686) which is not even shipped by Fedora by default but many users get it from rpmfusion for one reason or another.
Further info: the *called* system does in fact *not* have -ugly, so it would not even be able to decode the stream? Empathy needs to ask the other system for supported codecs before falling back on a non-free codec. After removing -ugly from the calling system I no get a crash, right... but I still/again only see black on the other system, so video still does not seem to work...
Could you please post logs when calling using Theora? If H264 is available, Empathy will try to use it as it provides better quality than Theora.
(In reply to comment #18) > Could you please post logs when calling using Theora? Sure > If H264 is available, Empathy will try to use it as it provides better quality > than Theora. Well, no problem with that if empathy would actually make sure that H.264 is supported on BOTH ends... Btw I think I just found a workaround to make theora video calls work, but first some logs where it fails:
Created attachment 147361 [details] Empathy log: callee
Created attachment 147362 [details] Empathy log: caller
Created attachment 147363 [details] Gabble log: callee
Created attachment 147364 [details] Gabble log: caller
Ok I can now confirm that this will make the video work: - initiate video call from either side - wait until both are connected, video will show black - toggle video off and on - wait about 5 seconds - video shows up on the other box So to sum up the problems: A) the h264 encoder crashes => gst-plugins-ugly bug B) empathy should not always expect the other side to have h264 => file new bug? C) theora video is not correctly initialized and needs a restart => this bug The following packages are installed on both my machines atm: empathy-2.28.1.1-3.fc12.i686 telepathy-gabble-0.8.8-1.fc12.i686 telepathy-mission-control-5.2.5-2.fc12.i686 telepathy-farsight-0.0.12-1.fc12.i686 telepathy-glib-0.9.0-1.fc12.i686
B) isn't really a bug. That's how codec discovery works, they have to be launched to get their config. You should really get your encoder fixed or uninstall it for now. C) sounds like a bug on our side. Does it work if you make an audio call and send video once it's established?
Ok, so B) makes sense. The only problem I see is that -ugly seems to be not as well tested as -base and -good. Regarding C), yes, if I initiate a voice only call and enable video after the call is established, video works (after a few seconds)
<sjoerd> i discovered some issues with theoraenc/theoradec yesterday <sjoerd> i don't trust those plugins untill those are fixed Could be related to this issue. We have someone working on this.
The Theora issue has been fixed (bug #601627). Any chance you could pick the GStreamer fix and retry?
Can the patch be applied to the latest stable -base release? If so, I may be able to build and test. I can't really test git code atm...
The patch has been merged and will be in the next -base release. It has been backported to the Debian Sid package and should be in the Ubuntu Telepathy PPA soon. Maybe you could ask to your distribution to backport it as well?
I just tried a video call with this fix and it worked fine.
Bastien says the patch is already in the latest -base package in F12. I have tested this now with the updated package on both ends and it does not make a difference, still 100% the same.
Reopening as the information requested in comment #7 has been provided.
Audio/Video calling has certainly got much improved over the past in empathy. Is this still an issue?
I'll try asap with a recent Fedora 14 live cd. Depending on the state of the unstable distribution, maybe "asap" will mean "beta".
Michael, any news on this? I am closing as OBSOLETE because the comments indicate that this issue has been resolved. Please reopen if this is not the case.