Arch Linux

Description:

About April 11, the x264 package was updated from 20100312-1 -> 20100410-1. Since this update, there seems to be a problem encoding video using the following command I use. This is the first pass of a two-pass process:

mencoder movie.vob -vf pullup,softskip,crop=$CROP,harddup -oac copy -ovc x264 -x264encopts bitrate=2400:subq=4:bframes=3:b_pyramid=normal:weight_b:turbo=1:threads=auto:pass=1 -of rawvideo -o /dev/null -msglevel all=0:statusline=5 || exit 1

I'd like to draw your attention to the "bitrate=2400". When I use the older 20100312-1 package, the status line from mencoder will look something like this:

Pos:1234.5s 12345f (12%) 27.65 fps Trem: 30min 1800mb A-V: 0.018 [2452:448]

The numbers at the tail end of this line represent the bitrate of the video and audio stream. As you can see, the bitrate for the video stream matches the bitrate I selected in the command. In addition, "Trem: 30" min indicates that about 30 minutes remain till the end of the encoding and the "1800mb" represents its guess of the final file size.

Now, with the newer 20100410-1 package, here's what I see:

x264 [warning]: non-strictly-monotonic PTS 11min 22mb A-V:-0.015 [29:448]

The "x264 warning" is obscuring a portion of the status line. The things to note are

* The "Trem" value is much smaller than I usually see for this step.
* The estimated file size is very small. I don't expect a movie to be encoded to a 22 MB file!
* The video bitrate is being shown as 29 kbps. This is inspite of specifying a target bitrate of 2400 kbps.

After this, the second pass fails with the error message:
x264 [error]: requested bitrate is too low. estimated minimum is 8 kbps

Now, I dug deeper.

The first pass produces a divx2pass.log file that contains data for the second pass. The first line of this log file lists the options the encoder is using. Here's the older package's options line (this is the package that seems to work):

#options: 720x352 fps=30000/1001 timebase=1001/30000 cabac=1 ref=1 deblock=1:0:0 analyse=0x3:0x13 me=hex subme=2 psy=1 psy_rd=0.00:0.00 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=12 sliced_threads=0 nr=0 decimate=1 interlaced=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 wpredb=1 wpredp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=abr mbtree=1 bitrate=2400 ratetol=1.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.40 aq=1:1.00

Now, here's the options line from the same vob file using the new x264 package:

#options: 720x352 fps=30000/1001 cabac=1 ref=1 deblock=1:0:0 analyse=0x3:0x13 me=hex subme=2 psy=1 psy_rd=0.00:0.00 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=12 sliced_threads=0 nr=0 decimate=1 mbaff=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 wpredb=1 wpredp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=abr mbtree=1 bitrate=2400 ratetol=1.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.40 aq=1:1.00

Things to note:
Both option lines are almost identical. The bitrate option is clearly passed to the encoder and set at 2400. The only difference is that the older package has a "timebase=1001/30000" option which is missing from the new package. This is probably either the cause or at least indicative of the cause of this problem.

For now, the fix is to downgrade the following packages:
mplayer(31040-1 -> 30886-1)
ffmpeg (22837-2 -> 22511-1)
x264 (20100410-1 -> 20100312-1)

in that order. This isn't a perfect fix, however. I notice that this older package doesn't seem to use all the cores of my processor for encoding and ends up taking longer to encode. But it results in a properly encoded file, so it's a workaround for now.

I hope this info helps in tracking the bug down. It's possible that this is an upstream bug in x264, but I couldn't find any references to this on the x264-devel mailing list (I assume somebody would have noticed this...) - so this could just be a bug in the Arch packages.

Additional info:
* package version(s)
x264-20100410-1

* config and/or log files etc.
-none-

Steps to reproduce:
1. Use the following commands to dump any DVD to a vob file and encode the video with x264 (uses mplayer/mencoder). In what follows, set the DVD, TRACK and CROP variables - usually, to "dvd", "1" and "" (or "720:480:0:0") respectively.

# Dump track to vob
mplayer -dvd-device /dev/$DVD dvd://$TRACK -dumpstream -dumpfile movie.vob -msglevel all=0
# Encode video (first pass)
mencoder movie.vob -vf pullup,softskip,crop=$CROP,harddup -oac copy -ovc x264 -x264encopts bitrate=2400:subq=4:bframes=3:b_pyramid=normal:weight_b:turbo=1:threads=auto:pass=1 -of rawvideo -o /dev/null -msglevel all=0:statusline=5
# Encode video (second pass)
mencoder movie.vob -vf pullup,softskip,crop=$CROP,harddup -oac copy -ovc x264 -x264encopts bitrate=2400:subq=5:8x8dct:frameref=2:bframes=3:b_pyramid=normal:weight_b:threads=auto:pass=2 -of rawvideo -o video.264 -msglevel all=0:statusline=5

2. You should be an abnormally small bitrate and estimated file size for the first pass and the second pass will fail with an error message from x264.