Any x264 build using speedcontrol?

[Blue_MiSfit]

Hey folks,

Is anyone out there building x264 with the speedcontrol patch?

I'd be really interested in a windows 32 bit CLI, and a 32 bit VFW as well.

If not, I guess it's time for me to spend some time learning how to do this stuff by myself, but I figured no harm in asking.

Thx all!

MiSfit

[LoRd_MuldeR]

Where is the patch? If you point me to the .diff file for the latest revision, I can make a build.

[Selur]

read about it some time ago in Dark Shakiris Blog, but I always thought that the patch never reached the public,...

[Blue_MiSfit]

http://pastebin.com/ErL2eAW8

[LoRd_MuldeR]

$ patch -p1 < ../x264_speed.diff
patch unexpectedly ends in middle of line
patch: **** Only garbage was found in the patch input.

Ideas? :confused:

[Blue_MiSfit]

Dunno... I'm not an expert :p

You sure you're using the correct file?

~MiSfit

[LoRd_MuldeR]

Dunno... I'm not an expert :p

You sure you're using the correct file?

~MiSfit

I used the file you pointed me to (obtained via "download" button). In the build environment that I use all day long...

[rack04]

I hand patched r1592 and rediffed it for you.

http://pastebin.com/QcTQUUgx

WARNING UNTESTED!

x264_x86_r1592M_speedcontrol (http://www.multiupload.com/HSTLLT9LA3)

Speedcontrol:

--speed <float> Automatically adjust other options to achieve this
fraction of realtime.
--speed-bufsize <int> Averaging period for speed. (in frames) [30]

[Blue_MiSfit]

<33333 thanks rack04!! I'll test this soon!

Any chance of VFW? The main purpose of this is to capture inside a digital rapids box.

If not, no worries. I assume this is all a lot of work.

Thank you!!
~MiSfit

[Audionut]

Can I do silly things with this patch like specify --preset placebo and half realtime. I guess so that it will always try placebo but lower as necessary.
I wouldn't do that in real life though. But something like --preset veryslow --speed 0.5 could be useful, where I'm happy to encode at half real-time and the --preset gets adjusted in low motion scenes to raise quality rather than just encode it faster.

Now that I think about it, this could be beneficial in MSU's tests where the is a speed component to the testing.


edit: seems something is wrong.

>x264 --preset veryslow --tune animation --crf 20 --speed 0.5 -o f:\speed.mkv f:\monster.avs
avs [info]: 1280x544p 0:0 @ 24000/1001 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 5.0
x264 [warning]: speedcontrol underflow (-1.891740 sec)
x264 [warning]: speedcontrol idle (0.030685 sec), eta 3:19:46
x264 [warning]: speedcontrol idle (0.358302 sec), eta 3:11:13
x264 [warning]: speedcontrol idle (0.459255 sec), eta 3:07:42
x264 [warning]: speedcontrol idle (0.550211 sec), eta 2:59:33
x264 [warning]: speedcontrol idle (0.346299 sec), eta 2:56:11
x264 [warning]: speedcontrol idle (0.563079 sec), eta 2:52:49
x264 [warning]: speedcontrol idle (0.486211 sec), eta 2:48:06
x264 [warning]: speedcontrol idle (0.633167 sec), eta 2:47:16
x264 [warning]: speedcontrol idle (0.600167 sec), eta 2:43:01
x264 [warning]: speedcontrol idle (0.729036 sec), eta 2:38:30
x264 [warning]: speedcontrol idle (0.557212 sec), eta 2:37:47
x264 [warning]: speedcontrol idle (0.640168 sec), eta 2:34:24
x264 [info]: frame I:2 Avg QP:12.65 size: 9276
x264 [info]: frame P:139 Avg QP:23.82 size: 2119
x264 [info]: frame B:179 Avg QP:23.84 size: 1300
x264 [info]: consecutive B-frames: 28.9% 0.6% 13.2% 5.0% 12.6% 34.0% 0.0% 0.0% 5.7% 0.0% 0.0%
x264 [info]: mb I I16..4: 75.2% 19.3% 5.6%
x264 [info]: mb P I16..4: 11.0% 1.4% 0.2% P16..4: 11.0% 1.9% 0.9% 0.0% 0.0% skip:73.6%
x264 [info]: mb B I16..4: 1.1% 0.4% 0.0% B16..8: 21.5% 1.8% 0.2% direct: 0.2% skip:74.7% L0:40.8% L1:56.5% BI: 2.7%
x264 [info]: 8x8 transform intra:13.9% inter:85.3%
x264 [info]: direct mvs spatial:98.9% temporal:1.1%
x264 [info]: coded y,uvDC,uvAC intra: 9.4% 0.0% 0.0% inter: 2.3% 0.0% 0.0%
x264 [info]: i16 v,h,dc,p: 43% 25% 11% 21%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 23% 23% 5% 7% 6% 10% 6% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17% 17% 20% 6% 9% 8% 8% 7% 7%
x264 [info]: i8c dc,h,v,p: 100% 0% 0% 0%
x264 [info]: Weighted P-Frames: Y:7.2%
x264 [info]: ref P L0: 72.7% 4.7% 17.6% 5.0%
x264 [info]: ref B L0: 92.9% 5.8% 1.2%
x264 [info]: ref B L1: 96.0% 4.0%
x264 [info]: kb/s:327.18
x264 [info]: speedcontrol: avg preset=7.623 buffer min=-1.450 max=1.066

aborted at input frame 401, output frame 320
encoded 320 frames, 14.62 fps, 261.42 kb/s

x264 --preset veryslow --tune animation --crf 20 --speed 0.5 --speed-bufsize 60 -o f:\speed.mkv f:\monster.avs
avs [info]: 1280x544p 0:0 @ 24000/1001 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 5.0
x264 [warning]: speedcontrol underflow (-0.918479 sec)
x264 [warning]: speedcontrol idle (0.020118 sec), eta 3:12:35
x264 [warning]: speedcontrol idle (0.467256 sec), eta 3:06:58
x264 [warning]: speedcontrol idle (0.388299 sec), eta 3:03:56
x264 [warning]: speedcontrol idle (0.453255 sec), eta 2:56:38
x264 [warning]: speedcontrol idle (0.583035 sec), eta 2:52:37
x264 [warning]: speedcontrol idle (0.436255 sec), eta 2:48:39
x264 [warning]: speedcontrol idle (0.549211 sec), eta 2:46:55
x264 [warning]: speedcontrol idle (0.683079 sec), eta 2:42:02
x264 [warning]: speedcontrol idle (0.807992 sec), eta 2:39:06
x264 [info]: frame I:2 Avg QP:12.65 size: 9276
x264 [info]: frame P:132 Avg QP:24.14 size: 2086
x264 [info]: frame B:151 Avg QP:23.80 size: 1427
x264 [info]: consecutive B-frames: 32.1% 0.7% 12.5% 2.8% 12.2% 33.4% 0.0% 0.0% 6.3% 0.0% 0.0%
x264 [info]: mb I I16..4: 75.2% 19.3% 5.6%
x264 [info]: mb P I16..4: 11.5% 1.9% 0.2% P16..4: 10.6% 1.5% 0.7% 0.0% 0.0% skip:73.6%
x264 [info]: mb B I16..4: 1.5% 0.7% 0.0% B16..8: 22.3% 1.9% 0.2% direct: 0.3% skip:73.1% L0:40.7% L1:56.5% BI: 2.8%
x264 [info]: 8x8 transform intra:17.1% inter:84.7%
x264 [info]: direct mvs spatial:98.7% temporal:1.3%
x264 [info]: coded y,uvDC,uvAC intra: 10.6% 0.0% 0.0% inter: 2.4% 0.0% 0.0%
x264 [info]: i16 v,h,dc,p: 43% 25% 11% 20%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 13% 24% 24% 5% 7% 6% 8% 5% 7%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 21% 22% 6% 8% 7% 8% 7% 6%
x264 [info]: i8c dc,h,v,p: 100% 0% 0% 0%
x264 [info]: Weighted P-Frames: Y:7.6%
x264 [info]: ref P L0: 74.3% 4.6% 16.7% 4.4%
x264 [info]: ref B L0: 94.1% 5.0% 1.0%
x264 [info]: ref B L1: 96.9% 3.1%
x264 [info]: kb/s:342.82
x264 [info]: speedcontrol: avg preset=6.775 buffer min=-0.352 max=1.027

aborted at input frame 366, output frame 285
encoded 285 frames, 14.29 fps, 267.30 kb/s

[Dark Shikari]

Can I do silly things with this patch like specify --preset placebo and half realtime. I guess so that it will always try placebo but lower as necessary.
I wouldn't do that in real life though. But something like --preset veryslow --speed 0.5 could be useful, where I'm happy to encode at half real-time and the --preset gets adjusted in low motion scenes to raise quality rather than just encode it faster.

Now that I think about it, this could be beneficial in MSU's tests where the is a speed component to the testing.The presets aren't very optimized, particularly for high bitrates; they were come up with pretty arbitrarily, mostly targeted at broadcast use.

If we were to commit this in mainline x264 we'd want to generalize it a bit more.

[Audionut]

Ok, thanks DS. Did you catch my edit. Are you interested in continuing with this patch?

[Dark Shikari]

Ok, thanks DS. Did you catch my edit. Are you interested in continuing with this patch?Yes, but it should use the preset system in some fashion or another, and it would really be nice if it didn't need hardcoded speed values.

[Audionut]

x264 [warning]: speedcontrol underflow (-1.891740 sec)
x264 [warning]: speedcontrol idle (0.030685 sec), eta 3:19:46
x264 [warning]: speedcontrol idle (0.358302 sec), eta 3:11:13
x264 [warning]: speedcontrol idle (0.459255 sec), eta 3:07:42
x264 [warning]: speedcontrol idle (0.550211 sec), eta 2:59:33
x264 [warning]: speedcontrol idle (0.346299 sec), eta 2:56:11
x264 [warning]: speedcontrol idle (0.563079 sec), eta 2:52:49
x264 [warning]: speedcontrol idle (0.486211 sec), eta 2:48:06
x264 [warning]: speedcontrol idle (0.633167 sec), eta 2:47:16
x264 [warning]: speedcontrol idle (0.600167 sec), eta 2:43:01
x264 [warning]: speedcontrol idle (0.729036 sec), eta 2:38:30
x264 [warning]: speedcontrol idle (0.557212 sec), eta 2:37:47
x264 [warning]: speedcontrol idle (0.640168 sec), eta 2:34:24


How overly concerned should I be about this?

[ifb]

<33333 thanks rack04!! I'll test this soon!

Any chance of VFW? The main purpose of this is to capture inside a digital rapids box.

If not, no worries. I assume this is all a lot of work.

Thank you!!
~MiSfit
Here's my git format-patch (http://pastebin.org/262006).

I can get x264vfw to link (after hacking the Makefile), but the resulting DLL is around 6MB (double Komisar's) and it doesn't work (can't open the config page). Sorry. Maybe someone else with a better-behaved mingw environment can do it.

Unrelated to this thread, I finally got around to testing Komisar's x264vfw build on my (SD only) digital rapids box Monday. Anytime CPU usage spikes, the Stream software starts filling its buffer. Even when CPU usage is down, buffer usage stays constant. Normally, it would use that opportunity to work on the backlog, but that doesn't happen. Speedcontrol may workaround this (always realtime means no buffer usage), but I think there's another issue (probably in Stream?). It simply won't encode faster than realtime to catch up when there are buffered frames waiting and CPU usage is not 100%. For example, I noticed it sitting at 28% buffer usage and had CPU usage around 10% during a long low-motion scene.

My other (minor) issue is having to use the AVI output, since changing the codec properties and the -o switch can't be automated. I encode audio to a separate AAC file in Stream and script ffmpeg to remux afterward. The resulting AVI has about 40 dropped frames at the beginning so I think lipsync is probably screwed (no time to check). If you don't do B-frames this is probably a non-issue. (If libfaac didn't suck, I'd use it when ffmpeg does the remux.)

How overly concerned should I be about this?It's not an issue. The speed-presets need tweaked like DS said. You can do --preset placebo --speed 1 and it'll eventually catch up.

[MasterNobody]

Blue_MiSfit
Here is highly experimental build of x264vfw with new GUI (not fully finished) + speedcontrol patch:
x264vfw_speedcontrol_experimental.exe (http://komisar.gin.by/test/x264vfw_speedcontrol_experimental.exe)

P.S. Thanks to Komisar for file hosting.

[Blue_MiSfit]

When using x264 with Digital Rapids, it's very helpful to enable options equivalent to --tune zerolatency - i.e. disabling b-frames, using sliced threads, and turning off all lookaheads. Those of us used to using x264 in offline mode might gasp, but it's not a big deal when capturing at crf14 etc :)

Using these options I can capture 1080i60 with no problems, and ABR is usually under 50mbps with sane content.

Also @MasterNobody:
Thanks! I have lots of HDCAM-SR tapes to capture next week, and I will try the speedcontrol VFW build on this project.

~MiSfit