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 577811 - Video makes a voice call drop out (Empathy 2.26.0.1)
Video makes a voice call drop out (Empathy 2.26.0.1)
Status: RESOLVED OBSOLETE
Product: empathy
Classification: Core
Component: VoIP
2.26.x
Other All
: Normal major
: ---
Assigned To: empathy-maint
Depends on:
Blocks:
 
 
Reported: 2009-04-03 07:27 UTC by jaduncan
Modified: 2009-08-28 12:25 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26



Description jaduncan 2009-04-03 07:27:44 UTC
Please describe the problem:
When using the Jaunty Empathy client on both ends, a voice call can be connected between two hosts. The audio is sent correctly. When video is sent from either end, the call instantly disconnects. The cameras concerned are a Lenovo UVC camera from a x200s (Bus 001 Device 003: ID 17ef:480c Lenovo) and a Sony Motion Eye (Bus 001 Device 003: ID 05ca:1839 Ricoh Co., Ltd) from a PCG-5J5M. Both devices display an image in gstreamer-properties, so the input should work. Audio works, so the transfer of data seems ok (it should be noted that both devices are on the same NAT network). The calls are from gtalk to gtalk account, although the bug is also reproducible when creating an account on jabber.org and as mentioned the audio does go through so the connection seems OK. I am confused. I also note that the cameras are both high resolution, but show up in the preview window fine. I have attached a screen shot of this (and why yes, it is me looking like a man filing a bug report). The screenshot is taken at the time after the voice call is created, and the video preview is fine but before the point at which the video call is initiated and the receiving client disconnects. The sending client is not aware that the call has ended at this point (might this be due to a crash on the receiving end rather than a neat ending of the call?), but continues to count time upwards as if the call is fine but it happens to be receiving no data. I will also include the empathy.log from sender and receiver in the comments.
.
The one thing I did wonder is if the 1280*1024 capture resolution of the camera is crashing the stream somehow.

The video failure thus seems like a large bug, and one that I had assumed would be fixed by the 2.26.0.1 updates. Versions of relevant software are current as of Jaunty, 3/Apr/09: empathy 2.26.0.1-0ubuntu1, telepathy-gabble 0.7.22-1ubuntu3, gstreamer-plugins-base 0.10.22-4, and gstreamer-nice 0.0.5-build1

I will be around for all of today, and so any requests for more info can be fulfilled.

Steps to reproduce:
1. Connect two Jaunty empathy clients.
2. Start a voice chat.
3. Turn on the video.


Actual results:


A snip that seems the source of the crash from receiver's empathy.log - is one client really sending a stream that the other client cannot decode? Surely not, given that this is gstrtptheoradepay.c. It looks like an error with getting the two cryptography pads right. This would also appear to imply that the size of the stream is not the issue:

"(empathy:17332): GLib-GObject-WARNING **: IA__g_object_set_valist: object class `GstRTPDTMFMux' has no property named `clock-rate'
** (empathy:17332): DEBUG: stream 2 (video) _tf_stream_bus_message: Send codec changed: 96: video THEORA clock:90000 channels:1 params:0x2494280
** (empathy:17332): DEBUG: stream 2 (video) cb_fs_new_active_candidate_pair: called
** (empathy:17332): DEBUG: tp_call_stream_state_changed_cb: Stream state changed - stream id: 2, state state: 2
** (empathy:17332): DEBUG: stream 2 (video) set_stream_playing: 1
** (empathy:17332): DEBUG: stream 2 (video) tf_stream_request_resource: Requesting resource for direction 2
** (empathy:17332): DEBUG: stream 2 (video) tf_stream_request_resource: Requesting resource for direction 2 returned 1
** (empathy:17332): DEBUG: stream 2 (video) set_stream_sending: 0
** (empathy:17332): DEBUG: stream 2 (video) cb_fs_stream_src_pad_added: New pad
** Message: Element error: Could not decode stream. -- gstrtptheoradepay.c(618): gst_rtp_theora_depay_process (): /GstPipeline:pipeline0/FsRtpConference:fsrtpconference0/GstBin:recv_2_1432799103_96/GstRtpTheoraDepay:rtptheoradepay0:
Could not switch codebooks

** (empathy:17332): DEBUG: tf_channel_dispose
** (empathy:17332): DEBUG: _tf_session_dispose"

Expected results:
A working video call, given that the two clients can see and communicate with each other.

Does this happen every time?
Yes.

Other information:
The bug is also added in Ubuntu at https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/354323. Please add responses/fixes to this as well as the GNOME bug.
Comment 1 jaduncan 2009-04-03 07:29:45 UTC
Full logs are attached in the launchpad link.
Comment 2 Guillaume Desmottes 2009-04-03 09:50:39 UTC
There are 2 bugs here:
- the codec issue
- Empathy shouldn't disconnect the call when such issue happens.

Let's use this bug to track the first one. I opened bug 577820 about the second.
Comment 3 Guillaume Desmottes 2009-04-17 14:41:43 UTC
Could you upgrade Telepathy packages from the PPA and retry please?
See http://cass.no-ip.com/~cassidy/blog/index.php/post/2009/04/14/Telepathy-Jaunty-PPA-open-for-business
Comment 4 jaduncan 2009-04-17 23:51:42 UTC
It does not with PPA packages.
Comment 5 Guillaume Desmottes 2009-04-23 12:25:48 UTC
Both sides were using latest packages from PPA? Then please upload new logs using these versions.
Comment 6 Stanislav 2009-05-03 14:25:00 UTC
Ubuntu 9.04. Last PPAs.


** (empathy:11108): DEBUG: stream 1 0x993e5e8 (audio) _tf_stream_try_sending_codecs: 98: audio speex clock:16000 channels:1
** (empathy:11108): DEBUG: stream 1 0x993e5e8 (audio) _tf_stream_try_sending_codecs: 98: audio speex clock:16000 channels:1
** (empathy:11108): DEBUG: stream 1 0x993e5e8 (audio) _tf_stream_try_sending_codecs: 98: audio speex clock:16000 channels:1
** (empathy:11108): DEBUG: stream 1 0x993e5e8 (audio) _tf_stream_try_sending_codecs: 0: audio PCMU clock:8000 channels:0
** (empathy:11108): DEBUG: stream 1 0x993e5e8 (audio) set_stream_sending: 1
** (empathy:11108): DEBUG: stream 1 0x993e5e8 (audio) tf_stream_request_resource: Requesting resource for direction 1
** (empathy:11108): DEBUG: stream 1 0x993e5e8 (audio) tf_stream_request_resource: Requesting resource for direction 1 returned 1
** (empathy:11108): DEBUG: stream 1 0x993e5e8 (audio) set_stream_playing: 1
** (empathy:11108): DEBUG: stream 1 0x993e5e8 (audio) tf_stream_request_resource: Requesting resource for direction 2
** (empathy:11108): DEBUG: stream 1 0x993e5e8 (audio) tf_stream_request_resource: Requesting resource for direction 2 returned 1
** (empathy:11108): DEBUG: stream 1 0x993e5e8 (audio) set_stream_sending: 1
** (empathy:11108): DEBUG: stream 1 0x993e5e8 (audio) _tf_stream_bus_message: Send codec changed: 98: audio speex clock:16000 channels:1 params:(nil)
** (empathy:11108): DEBUG: stream 1 0x993e5e8 (audio) add_remote_candidate: adding remote candidate R1

** (empathy:11108): WARNING **: stream 1 0x993e5e8 (audio) _tf_stream_bus_message: error (connection-failed (108)): Could not establish connection : Could not establish connection on the RTP component
** Message: tf_stream_error: stream error errorno=0 error=Could not establish connection
** (empathy:11108): DEBUG: stream 1 0x993e5e8 (audio) set_stream_playing: 0
** (empathy:11108): DEBUG: stream 1 0x993e5e8 (audio) close: close requested by connection manager
** Message: Element error: Internal data flow error. -- gstbasesrc.c(2330): gst_base_src_loop (): /GstPipeline:pipeline0/EmpathyGstAudioSrc:empathygstaudiosrc0/GstGConfAudioSrc:gconfaudiosrc0/GstBin:bin6/GstAlsaSrc:alsasrc0:
streaming task paused, reason not-linked (-1)
Comment 7 Stéphane Maniaci 2009-06-07 22:55:08 UTC
I get the same "streaming task paused, reason not-linked" with latest PPA version.
Comment 8 Javier Jardón (IRC: jjardon) 2009-08-12 23:50:28 UTC
From downstream reporter: https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/354323/comments/6

"Confirmed that the PPA packages fix this"
Comment 9 Guillaume Desmottes 2009-08-28 12:25:07 UTC
Closing this bug then.