Extreme poor Video Quality in Empathy (jabber)

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.

Ken could you backport the x264 patches listed?

"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) ?

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.

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

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!

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.

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.

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

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

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.)

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

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.

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

James says this is fixed in the natty version already.

The x264 update generates a regression bug: #690296

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

Any chance of getting this fix in Lucid?

> 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

> 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