Extreme poor Video Quality in Empathy (jabber)

Bug #663535 reported by Andreas Waigel on 2010-10-19
50
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Empathy
Unknown
Medium
x264 (Ubuntu)
High
Unassigned
Maverick
Low
Unassigned
Natty
High
Unassigned

Bug Description

Release Ubuntu 10.10; Problem also discovered under lucid...

Package (german):
empathy:
  Installiert: 2.32.0-0ubuntu2
  Kandidat: 2.32.0-0ubuntu2
  Versionstabelle:
 *** 2.32.0-0ubuntu2 0
        500 http://de.archive.ubuntu.com/ubuntu/ maverick/main i386 Packages
        100 /var/lib/dpkg/status

Description:
Using the Jabber Prot. with Video Chat. Both Clients Empathy 2.32.0 on Ubuntu 10.10
The calling partner receives a very poor video picture (seems to be a very low resolution, e.g. 20x15 pixels; value estimated) of the called one. He hisself can be seen very well on the other side of the connection.
Interchanging the calling and the called partner interchanges the problem vice versa.

affects: ubuntu → empathy (Ubuntu)
Guillaume Desmottes (cassidy) wrote :

As said in the upstream bug ( https://bugzilla.gnome.org/show_bug.cgi?id=633809 ) that's actually a libx264 bug.

Our options are:

A) Fix libx264 : http://git.videolan.org/?p=x264.git;a=commitdiff;h=3d0d9cda1d39239e9f388fe1fce29c9212d0273c and http://git.videolan.org/?p=x264.git;a=commitdiff;h=5f104e9957cc4b69f7197fecf93648a0e2ae0e59

B) Get the workaround in gst ugly : http://cgit.freedesktop.org/gstreamer/gst-plugins-ugly/commit/?id=6f2db739aed240d080b6a9cfe28ac1ec6d2c753c

C) Disable the setting in Empathy.

C) isn't great as it will re-introduce the big latency and can break interop with other clients.

Sebastien Bacher (seb128) wrote :

Ken could you backport the x264 patches listed?

affects: empathy (Ubuntu) → x264 (Ubuntu)
Changed in x264 (Ubuntu):
assignee: nobody → Ken VanDine (ken-vandine)
importance: Undecided → Low
Changed in x264 (Ubuntu Maverick):
importance: Undecided → Low
Changed in x264 (Ubuntu):
status: New → Triaged
Changed in x264 (Ubuntu Maverick):
status: New → Triaged
assignee: nobody → Ken VanDine (ken-vandine)
Changed in empathy:
importance: Unknown → Medium
Gam (gam-doodyandgam) wrote :

"C) isn't great as it will re-introduce the big latency and can break interop with other clients."

+1

Fix libx264 quickly isn't very easy, maybe use the workaround in gst ugly (fix framerate) in a first time (videochat will work) ?

Ken VanDine (ken-vandine) wrote :

I back ported the fix from git to the x264 version in maverick and confirmed it worked. I uploaded to maverick-proposed, but it still needs to get approved by ubuntu-sru.

To test it, you need to make sure you have gstreamer0.10-plugins-ugly-multiverse, libx264-98 and gstreamer0.10-ffmpeg installed, or empathy won't use H264.

Changed in x264 (Ubuntu Maverick):
status: Triaged → Confirmed
Ken VanDine (ken-vandine) wrote :

Actually I need to get it sponsored, lp:~ken-vandine/ubuntu/maverick/x264/maverick-proposed

Gam (gam-doodyandgam) wrote :

Me: "Fix libx264 quickly isn't very easy, maybe use the workaround in gst ugly (fix framerate) in a first time (videochat will work) ?"

Well, I said nothing :-}

Thanks for your reactivity.

Accepted x264 into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in x264 (Ubuntu Maverick):
status: Confirmed → Fix Committed
tags: added: verification-needed
Gam (gam-doodyandgam) wrote :

Empathy (Maverick PPA) <-> Gmail Web interface: It's working now.
Empathy (Maverick PPA) <-> Nokia N900 phone: Video a little jerky (big resolution for the phone ?) but it's working too.

Guillaume Desmottes (cassidy) wrote :

I tested empathy <-> empathy with both the libx264 fixes. The received video was switching between a few seconds of good image and then some grey shit. That could be because of https://bugzilla.gnome.org/show_bug.cgi?id=635020

I'd say to go for it because it's probably not related to libx264 and that's a general improvement any way.

Gam (gam-doodyandgam) wrote :

I tested Empathy PPA (Lucid) <-> Empathy PPA (Maverick with libx264 fixes) : It's good for me.

Martin Pitt (pitti) wrote :

Ken, please fix this in natty ASAP, so that this can go to m-updates. Thanks!

James Troup (elmo) wrote :

Martin, the x264 in natty has both these patches - can we get the x264 from maverick-proposed into maverick-updates now?

(I can confirm both the original problem and that the maverick-proposed update fixes it.)

Omer Akram (om26er) on 2010-12-09
tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package x264 - 2:0.98.1653+git88b90d9-3ubuntu1

---------------
x264 (2:0.98.1653+git88b90d9-3ubuntu1) maverick-proposed; urgency=low

  * debian/patches/x264.git-3d0d9cda1d39239e9f388fe1fce29c9212d0273c.patch
    - Fix CFR ratecontrol with timebase != 1/fps (LP: #663535)
  * debian/patches/x264.git-5f104e9957cc4b69f7197fecf93648a0e2ae0e59.patch
    - Fix bitrate calculation with DTS compression. (LP: #663535)
 -- Ken VanDine <email address hidden> Fri, 12 Nov 2010 15:37:53 +0100

Changed in x264 (Ubuntu Maverick):
status: Fix Committed → Fix Released
Martin Pitt (pitti) wrote :

Thanks for testing! releasing to -updates.

Ken, please apply the patch to Natty ASAP. Marking this RC, as it breaks the SRU policy. Pretty please always fix stuff in the devel release first.

Changed in x264 (Ubuntu Natty):
importance: Low → High
milestone: none → natty-alpha-2
Reinhard Tartler (siretart) wrote :

Easiest/Best fix seems to me to update the x264 package to the latest revision from the x264 stable branch

Martin Pitt (pitti) wrote :

James says this is fixed in the natty version already.

Changed in x264 (Ubuntu Natty):
status: Triaged → Fix Released

The x264 update generates a regression bug: #690296

Martin Pitt (pitti) wrote :

The maverick update got reverted to fix the serious regression in bug 690296.

Changed in x264 (Ubuntu Maverick):
status: Fix Released → Triaged
Jack Senechal (jacksenechal) wrote :

Any chance of getting this fix in Lucid?

Reşat SABIQ (tilde-birlik) wrote :

> Easiest/Best fix seems to me to update the x264 package to the latest revision from the x264 stable branch

Olivier from upstream also said the latest snapshot should be taken:
https://bugzilla.gnome.org/show_bug.cgi?id=633809#c10
He probably also implied "from stable branch".

If it really has been fixed in the stable branch of libx264, given that it alone would need to be upgraded (no other dependencies), is this the proposed solution then? If so, can we start moving in that direction? Are we there yet?

P.S.
The latest revision from stable branch of libx264 as of now is:
0.114.1907 429af21

Reşat SABIQ (tilde-birlik) wrote :

> Our options are:
>
> A) Fix libx264 : http://git.videolan.org/?p=x264.git;a=commitdiff;h=3d0d9cda1d39239e9f388fe1fce29c9212d0273c and http://git.videolan.org/?p=x264.git;a=commitdiff;h=5f104e9957cc4b69f7197fecf93648a0e2ae0e59

Since when these 2 patches were ported they resulted in a serious issue, and were then reverted, are we still certain that this issue is fixed in latest stable x264? Perhaps we should first at least estimate which commits after the 2 above have really fixed the issue, and then upgrade...

> B) Get the workaround in gst ugly : http://cgit.freedesktop.org/gstreamer/gst-plugins-ugly/commit/?id=6f2db739aed240d080b6a9cfe28ac1ec6d2c753c
> C) Disable the setting in Empathy.

If the issue isn't fixed in x264, is B or C the best way to go?

On Sun, Feb 27, 2011 at 04:22:26 (CET), Reşat SABIQ wrote:

>> Our options are:
>>
>> A) Fix libx264 : http://git.videolan.org/?p=x264.git;a=commitdiff;h=3d0d9cda1d39239e9f388fe1fce29c9212d0273c and http://git.videolan.org/?p=x264.git;a=commitdiff;h=5f104e9957cc4b69f7197fecf93648a0e2ae0e59
>
> Since when these 2 patches were ported they resulted in a serious issue,
> and were then reverted, are we still certain that this issue is fixed in
> latest stable x264? Perhaps we should first at least estimate which
> commits after the 2 above have really fixed the issue, and then
> upgrade...

we are certain that these commits do fix the issue. The problem is that
they change internal structures that require recompilation of *all*
users of x264. This is a no-go for a stable release update.

In order to follow the SRU protocol, the above fix needs to be rewritten
in a way that does not change the internal structures.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

Changed in x264 (Ubuntu Natty):
assignee: Ken VanDine (ken-vandine) → nobody
Changed in x264 (Ubuntu Maverick):
assignee: Ken VanDine (ken-vandine) → nobody
Adolfo Jayme (fitojb) on 2013-07-06
Changed in x264 (Ubuntu Maverick):
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.