Wrong framerate with x264 CLI encoding (Lagarith source)

[Hadrian]

I'm trying to compress a Lagarith source using the following x264 binary from x264.nl:


x264 0.133.2334 a3ac64b
(libswscale 2.3.100)
(libavformat 55.7.100)
(ffmpegsource 2.17.4.0)
built on May 21 2013, gcc: 4.7.3
configuration: --bit-depth=10 --chroma-format=all

The input file is an RGB Lagarith video at 1080p and 24fps. It is detected (and played back) correctly by media players and editing programs.

When playing back the x264-encoded output, the framerate is way off. I tried using the --fps and --force-cfr flags but they appear to have no effect at all.

Here a sample of what the console puts out:
x264 --preset slow --force-cfr --fps 24 --qp 0 --output-csp i422 --input-csp rgb -o "output.mp4" "input.avi"
ffms [info]: 1920x1080p 0:1 @ 8934/1001 fps (cfr)
resize [warning]: converting from rgb24 to yuv422p
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x264 [info]: profile High 4:4:4 Predictive, level 5.0, 4:2:2 10-bit
x264 [info]: frame I:14 Avg QP: 0.00 size:377718
x264 [info]: frame P:1750 Avg QP: 0.00 size: 11827
x264 [info]: mb I I16..4..PCM: 83.0% 2.0% 15.0% 0.0%
x264 [info]: mb P I16..4..PCM: 0.9% 0.1% 0.2% 0.0% P16..4: 0.4% 0.2% 0.
1% 0.0% 0.0% skip:98.1%
x264 [info]: 8x8 transform intra:4.7% inter:27.5%
x264 [info]: coded y,uvDC,uvAC intra: 23.8% 24.6% 24.6% inter: 0.3% 0.4% 0.4%
x264 [info]: i16 v,h,dc,p: 76% 23% 1% 0%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 40% 44% 9% 3% 1% 1% 0% 0% 2%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 43% 37% 9% 3% 1% 2% 1% 1% 3%
x264 [info]: i8c dc,h,v,p: 68% 13% 19% 0%
x264 [info]: Weighted P-Frames: Y:0.1% UV:0.1%
x264 [info]: ref P L0: 54.5% 18.6% 12.2% 6.9% 7.8%
x264 [info]: kb/s:2828.33

encoded 1764 frames, 21.51 fps, 2828.40 kb/s

The fps value in the ffms line (in this case 8934/1001) varies greatly with different input files. Any idea how to resolve this issue?

Thanks!

[Hadrian]

I just noticed something important: the problem occurs at the file input stage. The console output reads 1764 encoded frames, but the Lagarith source contains 4804.

Edit: I think I found the culprit. Lagarith has the option to encode "NULL frames", i.e. store practically nothing but timecode if the frame content doesn't change. It would seem this wasn't interpreted correctly by x264.

Do you think there's a way to keep using this feature? I'm using Lagarith for screen capture of my desktop and it helps keep filesize down.

[qyot27]

Use an AviSynth script to serve it in.

AVISource("lagarithvideo.avi")
And that's it. Alternatively, you could see whether --demuxer lavf reads the nulls correctly.

[Hadrian]

Thanks, I'll serve via AviSynth then. lavf was one of the first things I tried, but it didn't resolve the issue.

[Lyris]

I used to have x264 report wrong input frame rates before. For example, with a 23.976fps input, it gave me "2997/125 fps (cfr)".

That caused the resulting file (designed for Blu-ray) non-compliant (I have the verifier log to hand). Fortunately, the file was only for an internal use test disc and not something that would be replicated.

So, when I use x264 for Blu-ray, I always do what qyot27 mentioned and use an AVISynth script to feed in, with the line assumefps("NTSC_FILM"). And for added paranoia I always make sure x264 reports the proper frame rate (which in this case should be 24/1001). With that done, the output is totally spec compliant.

[MasterNobody]

I used to have x264 report wrong input frame rates before. For example, with a 23.976fps input, it gave me "2997/125 fps (cfr)".
It is not x264 that report wrong input frame rates but input plugins (avisynth/lavf/ffms) that report it "wrong" to x264 and it simply trust them because if we wouldn't trust them than this would be even more mess if the reported fps was correct and we "fixed" it (a specially in vfr case). So it is user task to make check and fix the input fps reported by this plugins.