GNOME Bugzilla – Bug 633809
Ugly h264 videochat
Last modified: 2011-08-29 10:12:37 UTC
Since Ubuntu 10.10 (Empathy 2.32), Videochat with Gmail's users (and to a N900 phone) are very ugly, like a too compressed stream. No problems with h263 and Theora, only with H264 codec. If I change the "tune=0x4" option (no latency) in the "element-properties" file, the 3/4 secondes latency is back but the video is good. In fact, the zero latency option introduced in Empathy 2.32 seems doesn't work. Tested with Maverick's Empathy version, with the PPA version and with Maverick's Gstreamer version and his PPA version. Same results for all combinaisons.
I can reproduce with Maverick (gstreamer0.10-plugins-ugly-multiverse 0.10.16-1 and libx264-98 2:0.98.1653+git88b90d9-3). Indeed, this regression has been introduced with http://git.gnome.org/browse/empathy/commit/?id=c79d81eff8d5894ac8cc92112ecce18ccc89f1dd
It's a known bug in libx264. You can either get a more recent version of it. Or get the git version of gst-plugins-ugly which has a workaround.
For the record, the LP bug is https://bugs.edge.launchpad.net/empathy/+bug/663535
It's working now. Thanks Guillaume and Martin.
(In reply to comment #3) > For the record, the LP bug is > https://bugs.edge.launchpad.net/empathy/+bug/663535 The LP bug 663535 fix has been reverted to address a regression issue that got introduced by that fix; please see: https://bugs.launchpad.net/ubuntu/+source/x264/+bug/690296 This means that this issue isn't really resolved. So if you are reading this, and you can reopen this bug, please do. (In reply to comment #0) > No problems with h263 and Theora, only with H264 codec. > If I change the "tune=0x4" option (no latency) in the "element-properties" > file, the 3/4 secondes latency is back but the video is good. > In fact, the zero latency option introduced in Empathy 2.32 seems doesn't work. I can confirm that the video is ugly with default element-properties (it's a total blur: probably not an issue of too small bitrate, but perhaps something like incorrect compression/decompression, etc. (whatever it is, most pixels aren't there)). If i delete line 17 in element-properties[1], the video is as it is expected to be, but as the OP mentioned, there's a 2-to-4 second delay (for me as well). That said, if there isn't a better fix (that also takes care of delay) right now, i do believe line 17 should be taken out, and an update should be released, to get the video working for users. The delay would be nice to resolve as well, but that doesn't have to be done right now, so it can be fixed in a subsequent update, IMHO. There's no use having no delay, if the video is a blur, is there? Perhaps not a fitting allegory, but (unless i could do both at once) i'd extinguish the fire first, and fix things up further later on. IMHO, this issue is both of the following[2]: Urgent AND (Blocker (or at least Major)). [1] http://git.gnome.org/browse/empathy/tree/data/element-properties?id=c79d81eff8d5894ac8cc92112ecce18ccc89f1dd&h=gnome-2-32 [2] https://bugzilla.gnome.org/page.cgi?id=fields.html#importance Thank you (for reading my passionate "essay", even if nothing comes of it). :)
The real fix is in x264... once you have that fixed x264, it should be fine
The bug is logged against Empathy 2.32.x. From this viewpoint, there is a bug in both x264 and empathy: 1. the bug in x264 appears to be that it doesn't support the property being set: tune=0x4 2. the bug in empathy 2.32.x is that it tries by default to set a property (tune=0x4) on a dependent library (libx264), while it's well known that that property isn't supported by libx264 releases used by empathy 2.32.x; and it's not only not supported, but makes video stream uselessly blurry. If libx264 used by the development branch does support tune=0x4, then obviously it's OK to set it on the development branch. Since that's not the case in 2.32.x branch, obviously it's a bug to set tune=0x4 on that branch (until libx264 that supports it FOR THAT BRANCH is available). If there's no action taken by Empathy team here upstream, i'll have to log a bug to fix this at Ubuntu level, to make Empathy usable for a large proportion of users of Ubuntu 10.10. P.S. Item 2. above is a bug in Empathy code. Not doing anything to fix that bug, is a "bug in judgment". P.P.S. I see an easy and quick operational plan to get video chat working for a large proportion of users of Empathy 2.32.x: a. delete tune=0x4, and release an updated Empathy 2.32.x b. if and only if, x264 bug is ever resolved for libx264 used by Empathy 2.32.x, restore tune=0x4 property, and make another updated release. If you know another quick way of accomplishing the same, w/o changing empathy, please share the specific operational steps. Telling users to wait indefinitely for x264 to be fixed, while continuing to set a property it doesn't support and depriving them of video is not it. P.P.P.S. After a quick fix for Ubuntu 10.10 users, i was going to continue w/ another bug for Empathy 2.30.x currently released for Ubuntu 10.04 (Empathy-to-Gmail calls don't have any video since January (was nuisance to get it, but it was possible to have video before then), although reverse calls have it). I was going to ask Empathy team here whether changes made in 2.32.x minus tune=0x4 property could be ported to 2.30.x or ask Ubuntu whether they could upgrade Empathy released for 10.04 (and its dependencies) to 2.32.x. I think Empathy team (and Ubuntu developers) should care about users of both 2.32.x and 2.30.x and take the steps to get video working for both ASAP, and not waiting indefinitely for unknown changes to be determined and made in libx264. Here's another allegory: it's like a money transfer system trying to transfer money using a subsystem known to fail to transfer the money. Substitute Empathy for money transfer system, and video stream for money. "Not cool" is the softest thing i can say.
Empathy doesnt use libx264 directly, but through a plugin.. It's a distribution issue..
I'd really appreciate operational terms, similar to a. and b. in comment 7. We know that, for instance, Ubuntu 10.10's latest 2:0.98.1653+git88b90d9-3ubuntu2 version of libx264 doesn't support tune=0x4 property. Could you specify which release/version/revision/cherry-pick from which source or binary repo can be taken by a distro (such as Ubuntu), or a regular user in order to update libx264 so that Empathy's default tune=0x4 property doesn't cause any issues? P.S. If this cannot be specified, tune=0x4 property has to go. If it can, there would be an alternative of logging a bug to a distro (such as Ubuntu), so that they release an update to libx264.
They should just get the latest snapshot.. tune=0x4 was there in older versions, it was just broken
As Olivier said, that's a distribution issue, not an Empathy one. We already explained to Ubuntu where was the issue (libx264) and how to fix it. The rest is up to them. Furthermore, Empathy 2.32 is not maintained any more so it's very unlikely to have new 2.32.x releases.