libx264 2:0.98.1653+git88b90d9-3ubuntu1 messes up bitrate when encoding (at least using mencoder)

Bug #690296 reported by Loïc Martin on 2010-12-14
68
This bug affects 10 people
Affects Status Importance Assigned to Milestone
x264 (Ubuntu)
Undecided
Unassigned
Maverick
High
Ken VanDine
Natty
Undecided
Unassigned

Bug Description

Binary package hint: x264

New version of libx264-98 don't seem to respect bitrates when encoding, and it seems to mess up crf too (far too big sizes for crf=20).

Previous version in Maverick didn't exhibit this problem. I've encoded about 10 movies in the past few days, and on Friday evening after updating to the new version, using the same files and encoding options the resulting video steam was either 6 times too big or far to small (a few MB) and unplayable.

Results have been reproduced on two computers, one with a C2Q 9550 and one with an i5 520M; both computers have had a fresh install of Maverick in the weeks following release, and I never tweaked anything related to mplayer, mencoder or x264.

It's far easier to spot on long videos, 1h30 videos streams with bitrates requested to be 1200kbps end up above 6GB instead of the 900MB they should be, or end up a few MB, and in both cases they're unplayable. Doesn't seem to be a problem with bites/bytes since it never end up as a multiple of eight times the size.

Here are some of the command lines used in case you're not used to mencoder (video.m2v is the original stream, output.264 is the resulting stream, -x264encopts are options passed to the x264 encoder):

- single pass, simple example:
mencoder video.m2v -nosound -of rawvideo -ovc x264 -x264encopts bitrate=1000

- 2 pass, :
mencoder video.m2v -vf crop=720:544:0:16 -ofps 25 -nosound -of rawvideo -o output.264 -ovc x264 -x264encopts threads=6:bitrate=1530:bframes=16:b-adapt=2:ref=3:direct_pred=auto:weight_b:partitions=all:8x8dct:me=umh:me_range=48:subq=9:mixed-refs:trellis=2:no-fast-pskip:no-dct-decimate:nr=0:fps=25:sps-id=1:pass=1:zones=1,720,b=0.2;180151,182851,b=0.5;182852,190272,b=0.25
(change pass=1>pass=2 for second pass)

This problem makes it impossible to encode videos any more, since the resulting file is either bigger than the original MPEG2 file, or unplayable. It seems to be better without specifying bitrate or using crf, but then you don't know what you end up with (crf gave me results not in line with the size it should really have been, especially with conservative values between 19 to 23).

I've attached a list of al the packages updated between the time it worked in Maverick and after - I did encode a video a few hours before installing those updates without any trouble, and launched another encode a few hours after the update, which didn't work anymore.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: libx264-98 2:0.98.1653+git88b90d9-3ubuntu1
ProcVersionSignature: Ubuntu 2.6.35-23.41-generic-pae 2.6.35.7
Uname: Linux 2.6.35-23-generic-pae i686
NonfreeKernelModules: nvidia
Architecture: i386
Date: Tue Dec 14 19:18:23 2010
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
ProcEnviron:
 LANG=fr_FR.utf8
 SHELL=/bin/bash
SourcePackage: x264

Loïc Martin (loic-martin3) wrote :
Loïc Martin (loic-martin3) wrote :

mencoder was latest version 2:1.0~rc4~try1.dsfg1-1ubuntu1 (and still is) before and after the problem started to occur.

llogan (loul) wrote :

Using x264 2:0.98.1653+git88b90d9-3 directly doesn't reproduce this behavior on x86_64:
x264 --bitrate 1000 -o test1.h264 IronMan.mkv
x264 --crf 20 -o test2.h264 IronMan.mkv

Compiled x264 0.110.1820 fdcf2ae:
x264 --bitrate 1000 -o test3.h264 IronMan.mkv
x264 --crf 20 -o test4.h264 IronMan.mkv

13M test1.h264
72M test2.h264
13M test3.h264
72M test4.h264

However, there is a difference between the repo and compiled FFmpeg:
Using FFmpeg 4:0.6-2ubuntu6 and libx264-98 2:0.98.1653+git88b90d9-3ubuntu1:
ffmpeg -i IronMan.mkv -an -vcodec libx264 -vpre medium -b 1000k -threads 0 1b.mp4
ffmpeg -i IronMan.mkv -an -vcodec libx264 -vpre medium -crf 20 -threads 0 1crf.mp4

FFmpeg SVN-r25943 and x264 x264 0.110.1820 fdcf2ae:
ffmpeg -i IronMan.mkv -an -vcodec libx264 -vpre medium -b 1000k -threads 0 2b.mp4
ffmpeg -i IronMan.mkv -an -vcodec libx264 -vpre medium -crf 20 -threads 0 2crf.mp4

290M 1b.mp4
72M 1crf.mp4
13M 2b.mp4
72M 2crf.mp4

Sample: http://mirror05.x264.nl/Dark/x264clips/

Reinhard Tartler (siretart) wrote :

Natty has a newer version of x264:

      x264 | 2:0.98.1653+git88b90d9-3ubuntu1 | maverick-updates/universe | source, amd64, i386
      x264 | 2:0.106.1741-3 | natty/universe | source, amd64, i386

Can you please retry with that x264-106?

Loïc Martin (loic-martin3) wrote :

I'm trying it with backported 2:0.106.1741-3 from Natty (https://launchpad.net/~loic-martin3/+archive/x264) but so far I still get insane results on the C2Q. The encode isn't finished, but I get an expected filesize of 5MB on a 1h30 1500kbps encode, and the FPs are round 98 for the first pass, where before they where below 20 (for the working Maverick version), like it was with the faulty Maverick version.

Loïc Martin (loic-martin3) wrote :

I noticed I still have libx264-98 along with libx264-106, and -98 is probably still used by mencoder since it depends on it.

However, I tried using x264 directly (since I only have the -106 version on the system now) and even though LouL command line fails here :
       raw [error]: raw input requires a resolution.
       x264 [error]: could not open input file `IronMan.mkv' via any method!
trying with "x264 --bitrate 1000 --input-res 1280x720 -o test.264 IronMan.mkv" produces an 8MB file that's unplayable.

I have the same behaviour with ffmpeg after updating x264.

Jean-Baptiste Lallement (jibel) wrote :

Adding maverick task to track the regression with the current version in -updates.

tags: added: regression-update
removed: regression
Changed in x264 (Ubuntu Maverick):
importance: Undecided → High
status: New → Triaged
Changed in x264 (Ubuntu Natty):
status: New → Confirmed
tags: added: regression-release

I have rolled back libx264 and now ffmpeg behaves right (with 2:0.98.1653+git88b90d9-3).

With the updated version, the ouput bitrate doesn't match the expected one.

Crao (come-desplats) wrote :

I have also the same behavior with avidemux.

Loïc Martin (loic-martin3) wrote :

I've rolled back to 2:0.98.1653+git88b90d9-3 and the bug is still there when I use mencoder with the bitrate x264 parameter (while it wasn't before upgrading to 2:0.98.1653+git88b90d9-3ubuntu1). It's upsetting, because it shouldn't do that and I've got no clue why it doesn't work anymore (same script, system is fully up to date except x264 and libx264, no customization at all).

llogan (loul) wrote :

Downgrading to libx264-98 2:0.98.1653+git88b90d9-3 seems to work when used with FFmpeg:
ffmpeg -i IronMan.mkv -an -vcodec libx264 -vpre medium -b 1000k -threads 0 3.h264
15M 3.h264

So I assume one or both of the following patches are causing this issue:

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

llogan (loul) wrote :

Both of the patches are in trunk, but:
<Dark_Shikari> they changed x264.h without changing X264_BUILD

Reinhard Tartler (siretart) wrote :

Further discussion with Jason (aka Dark_Shikari):

10:00 <Dark_Shikari> You inserted a variable into x264_param_t.
10:00 <Dark_Shikari> This shifts down all the other variables.

From the diff, I spot this change:
http://launchpadlibrarian.net/59039785/x264_2:0.98.1653%2Bgit88b90d9-3_2:0.98.1653%2Bgit88b90d9-3ubuntu1.diff.gz

+=== modified file 'x264.h'
+--- old/x264.h 2010-11-02 19:26:22 +0000
++++ new/x264.h 2010-11-02 19:26:35 +0000
+@@ -328,7 +328,9 @@
+ int b_annexb; /* if set, place start codes (4 bytes) before NAL units,
+ * otherwise place size (4 bytes) before NAL units. */
+ int i_sps_id; /* SPS and PPS id number */
+- int b_vfr_input; /* VFR input */
++ int b_vfr_input; /* VFR input. If 1, use timebase and timestamps for ratecontrol purposes.
++ * If 0, use fps only. */
++ int b_pulldown; /* use explicity set timebase for CFR */
+ uint32_t i_fps_num;
+ uint32_t i_fps_den;
+ uint32_t i_timebase_num; /* Timebase numerator */
+

This strictly speaking requires a SONAME bump and therefore is totally unacceptable for an SRU. I strongly suggest to revert this change.

Reinhard Tartler (siretart) wrote :

This issue has never affected the x264 package in natty, as there, the SONAME was properly bumped.

Changed in x264 (Ubuntu Natty):
status: Confirmed → Invalid
Reinhard Tartler (siretart) wrote :

Ken, I see that you are not subscribed to this bug but prepared the SRU. Can you please have a look at this issue?

Changed in x264 (Ubuntu Maverick):
assignee: nobody → Ken VanDine (ken-vandine)
Loïc Martin (loic-martin3) wrote :

Ok, finally found what was the other problem on top of libx264 2:0.98.1653+git88b90d9-3ubuntu1

Turns out that since at least June 2010, mencoder has a problem when using the -vf crop= option. I found another report in http://lists.mplayerhq.hu/pipermail/mencoder-users/2010-June/011642.html and it's exactly what I've been also experiencing (while libx264 2:0.98.1653+git88b90d9-3ubuntu1 didn't work at all with the bitrate option, using mencoder and 2:0.106 from natty will not work, but only when using the -vf crop mencoder option). However for whatever reason mplayer developers don't appear to have acknowledged the email.

I'll send an email to mencoder's mailing list and, depending on the replies I'll also open a bug report against mencoder in launchpad. Strange thing is it worked in maverick initially, and stopped working the same day libx264 2:0.98.1653+git88b90d9-3ubuntu1 arrived. Could be a problem on my side with delayed updates since the notification system for Ubuntu is borked, but I'm not sure I really hadn't updated for weeks (mencoder got an update a few weeks before libx264 AFAIR).

Martin Pitt (pitti) wrote :

Reinhard, can you please reupload with a fixed LP: # syntax in the changelog for this bug? Thanks!

Martin Pitt (pitti) wrote :

Reinhard, unfortunately you changed the wrong bug in the changelog:

   * Revert previous change, reopens LP: #663535, fixes: #690296.

You want to close #690296, _not_ #663535. So, please:

   * Revert previous change, reopens LP #663535 (LP: #690296).

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: Triaged → Fix Committed
tags: added: verification-needed
llogan (loul) wrote :

Tested libx264-98 2:0.98.1653+git88b90d9-3ubuntu2 and works for me on Maverick x86_64:

ffmpeg -i IronMan.mkv -an -vcodec libx264 -vpre medium -b 1000k -threads 0 proposed-b.h264
15M proposed-b.h264 = ~1132 kbit/s

Martin Pitt (pitti) on 2011-01-07
tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

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

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

  * Revert previous change, reopens LP #663535, fixes LP: #690296.
 -- Reinhard Tartler <email address hidden> Wed, 05 Jan 2011 09:07:47 +0100

Changed in x264 (Ubuntu Maverick):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers