Slow libx264 encoding on 1.1.0/1.1.2 vs 1.0.7

HandBrake for Windows support
Forum rules
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
Locked
flcowboy7
Posts: 4
Joined: Sun Nov 11, 2018 3:13 am

Slow libx264 encoding on 1.1.0/1.1.2 vs 1.0.7

Post by flcowboy7 » Sun Nov 11, 2018 9:00 am

Not using QSV here, but I can attest to 1.1.0 and 1.1.2 running at seemingly much slower speeds. My average FPS on 1.0.7 was above 100 for almost everything (BluRays, DVDs, Movies, TV Shows, etc). Lately, I'm lucky to see it go faster than 30fps. I have not had any hardware changes between versions. Not trying to hijack a thread, just adding fuel to the fact that QSV may not be the problem. Was desperately Googling for answers (because I HB a ton of files daily) and found this thread. Or, it's possible that I have a different issue, entirely and should have started my own thread...

Running Windows 10 Home; using AMD Ryzen 1950x 3.4GHz with 32GB RAM (really wish HB would use more of the CPU...lol) and NVIDIA GeForce GTX 1060 6GB (running the latest drivers).

I ran the following tests:

1) For the 1st test, I started an encode on a single source file using v1.1.2. (This is uncommon, as I would typically have 30-100 jobs pending). Oddly, this 1st test ran at an average of ~120fps (not the expected 30fps as previously mentioned). According to the log, it only took 5 minutes to process a 21 minute source file. I had planned on running this same test in both v1.0.7 and v1.1.2, but since the results were not as bad as I expected, I started to wonder whether there was a different issue at play.
** Activity Log for Test #1: https://www.dropbox.com/s/9srjbj9t4j623 ... 2.txt?dl=0

2) For the 2nd test, I copied the same source file from the 1st test 4 additional times (creating 5 identical source files with slightly different file names). Added all to queue and processed. This 2nd test started out at an average of ~90fps, but continually slowed down as the processing went on. Before processing completed on the first source file, it was down to less than 50fps (still with an average of ~70fps). The second source file maintained around 50fps (slowing the average to ~50fps, as well), taking around 11 minutes to process the same 21 minute source file. Based on the 1st test AND previous experiences using HB, I would have expected ~100 to 120fps, so ~50fps isn't great. Third and fourth files averaged ~46fps. At 11 min per file, I aborted part way through the fourth file.
** Activity Log for Test #2: https://www.dropbox.com/s/macxxav3bccoy ... 2.txt?dl=0

3) The 3rd test is exactly the same as the 2nd test, except I added a total of 30 files to the queue before I started processing (all identical to the one used in the 1st test, of course). I used the "add all" option, though I don't imagine that would have made a difference. The first file started at ~120fps, but gradually dropped ~40fps (with average below ~80fps) before it was completed - took around 7 min to finish. The second file started at ~50fps. Admittedly, at that point, I walked away for the desk for a bit. When I returned, it was on the sixth file, still with an average of ~46fps. I aborted the queue.
** Activity Log for Test #3: https://www.dropbox.com/s/69xxgrxjlsd7l ... 2.txt?dl=0

4) At this point, I thought it was only fair to re-run the first test in v1.0.7, to see if there was any significant difference. Test #4 is the same as test #1, but on v1.0.7. The results were surprising with only an average of ~52fps. When v1.0.7 was first installed, I don't recall it being that slow. So now I'm wondering what other conflicts could be playing a role... maybe other software/driver updates since v1.0.7 between the time v1.0.7 was first installed and now - with v1.1.2?
** Activity Log for Test #4: https://www.dropbox.com/s/vxv8xwf8tt8qg ... 7.txt?dl=0

5) After the unexpected results from test #4, I re-installed v1.1.2 and re-ran test #1. Test #5 is identical to test #1, except that the average was once again only ~48fps. Why was test #1 ~120fps, but now test #5 (an identical situation) is only ~50fps??? What the heck?! Now I'm totally confused.
** Activity Log for Test #5: https://www.dropbox.com/s/asokpnbueqgtb ... 2.txt?dl=0

>Note: It may be worth mentioning that while processing, my CPU never went over 25% utilization (sigh - really wish I could force HB to use more of the power in this rig) and the GPU was right around 15%. So it's not as though something else was taking over the processor in the background.

This is all somewhat surprising to me, considering the potential power of this rig...

rollin_eng
Veteran User
Posts: 2905
Joined: Wed May 04, 2011 11:06 pm

Re: Slow QuickSync encoding on 1.1.0/1.1.2 vs 1.0.7

Post by rollin_eng » Sun Nov 11, 2018 11:11 am

@flcowboy7

You should probably start your own thread for this.

User avatar
Rodeo
HandBrake Team
Posts: 11957
Joined: Tue Mar 03, 2009 8:55 pm

Re: Slow libx264 encoding on 1.1.0/1.1.2 vs 1.0.7

Post by Rodeo » Sun Nov 11, 2018 1:00 pm

Topic split.

flcowboy7
Posts: 4
Joined: Sun Nov 11, 2018 3:13 am

Re: Slow libx264 encoding on 1.1.0/1.1.2 vs 1.0.7

Post by flcowboy7 » Sun Nov 11, 2018 6:05 pm

Thanks for the split.

I just started an encode on a file I KNOW I witnessed at only 30fps (a 46 min source file), but it started out running between 80-100fps. I have no idea why some days it's super slow and others it's super fast. About half way through it slowed down to ~30fps, but bounced between 30-50fps. 50fps still feels a bit slow to me.

I went through the logs to try and find one that took much longer to complete and only found ONE that took 64 minutes for a 42 min source file.

Activity log for that one: https://www.dropbox.com/s/zl0en3lzvcjcs ... 6.txt?dl=0

Maybe I'm just going crazy and happen to be glancing at the screen during temporary slow downs? Looked again at the encode I started when I started typing this reply: it's at 80% with avg FPS of 60 and actual FPS of ~40-45. Looks like it will have taken about 19-ish minutes for that 46 min source file. I guess that's pretty good, right? Maybe I'm overthinking it. Maybe if I want it to be faster I just have to tweak the settings and sacrifice a bit more quality? Maybe I'm not understanding some upper limit of what the algorithms can do versus the upper limit of what my hardware can do. It just seems like, with nothing else actively running, a powerful processor and GPU and LOTS of RAM, that processing would be much faster, even given my current settings.

rollin_eng
Veteran User
Posts: 2905
Joined: Wed May 04, 2011 11:06 pm

Re: Slow libx264 encoding on 1.1.0/1.1.2 vs 1.0.7

Post by rollin_eng » Sun Nov 11, 2018 7:22 pm

Where are you read/writing to, local or network?

flcowboy7
Posts: 4
Joined: Sun Nov 11, 2018 3:13 am

Re: Slow libx264 encoding on 1.1.0/1.1.2 vs 1.0.7

Post by flcowboy7 » Sun Nov 11, 2018 8:55 pm

I'm using the "WD - easystore® 8TB External USB 3.0 Hard Drive" from Best Buy. I actually wondered if that was the problem. I used to use a NAS and that was mistake for a number of reasons. I tried copying one of the files from my tests to my internal "Toshiba DT01ACA300" (3TB 7200 RPM 64MB Cache SATA 6.0Gb/s), then processed it from there, but it made zero difference.

flcowboy7
Posts: 4
Joined: Sun Nov 11, 2018 3:13 am

Re: Slow libx264 encoding on 1.1.0/1.1.2 vs 1.0.7

Post by flcowboy7 » Mon Nov 12, 2018 7:50 pm

Here's another one, took 33 min to process a 42 min source file. Every time I checked, it was around 30fps.

https://www.dropbox.com/s/5bndk7mzz9u41 ... 7.txt?dl=0

Locked