CPU Cores and forced cpus

[danhi]

I'm running on a Intel core i7 with 4 cores, running Vista 64 bit. I set the processor cores option on the CLI tag to 3, which is reflected in the activity log. Handbrake detects 8 cores, but more importantly, it continues to use all 4 cores anyway. It also only detects 2 GB of RAM, even though I have 6GB (but I suspect that this is due to the fact that handbrake is still probably 32 bit, so it runs in the compatability box on Vista 64). The activity log is:

### Windows GUI 0.9.3 2008112300
### Running: Microsoft Windows NT 6.0.6001 Service Pack 1
###
### CPU: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz
### Ram: 2038 MB
### Screen: 1680x1050
### Temp Dir: C:\Users\DanHi\AppData\Local\Temp\
### Install Dir: C:\Program Files (x86)\HandBrake
### Data Dir: C:\Users\DanHi\AppData\Roaming\HandBrake\HandBrake\0.9.3.0
#########################################

[15:40:29] hb_init: checking cpu count
[15:40:29] hb_init: starting libhb thread
HandBrake 0.9.3 (2008112300) - http://handbrake.fr/
8 CPUs detected
Forcing 3 CPUs
Opening C:\Downloads\LizR4\FullDisc\ELIZABETHR_4\VIDEO_TS...
[15:40:29] hb_scan: path=C:\Downloads\LizR4\FullDisc\ELIZABETHR_4\VIDEO_TS, title_index=1
[15:40:29] scan: trying to open with libdvdread
[15:40:29] scan: DVD has 4 title(s)
[15:40:29] scan: scanning title 1
[15:40:29] scan: opening IFO for VTS 1
[15:40:29] pgc_id: 1, pgn: 1: pgc: 0x2074420
[15:40:29] scan: vts=1, ttn=1, cells=0->6, blocks=0->793291, 793292 blocks
[15:40:29] scan: duration is 00:44:15 (2655266 ms)
[15:40:29] scan: checking audio 1
[15:40:29] scan: id=80bd, lang=Unknown (AC3), 3cc=und ext=0
[15:40:29] scan: checking subtitle 1
[15:40:29] scan: id=20bd, lang=Unknown, 3cc=und
[15:40:29] scan: title 1 has 7 chapters
[15:40:29] scan: chap 1 c=0->0, b=0->163337 (163338), 566431 ms
[15:40:29] scan: chap 2 c=1->1, b=163338->278259 (114922), 406413 ms
[15:40:29] scan: chap 3 c=2->2, b=278260->394422 (116163), 376429 ms
[15:40:29] scan: chap 4 c=3->3, b=394423->527833 (133411), 466304 ms
[15:40:29] scan: chap 5 c=4->4, b=527834->665436 (137603), 413394 ms
[15:40:29] scan: chap 6 c=5->5, b=665437->793167 (127731), 425292 ms
[15:40:29] scan: chap 7 c=6->6, b=793168->793291 (124), 1000 ms
[15:40:29] scan: aspect = 0
[15:40:29] scan: decoding previews for title 1
[15:40:29] scan: audio 0x80bd: AC-3, rate=48000Hz, bitrate=192000 Unknown (AC3) (2.0 ch)
[15:40:29] scan: 10 previews, 720x480, 29.970 fps, autocrop = 0/0/8/12, aspect 4:3, PAR 8:9
[15:40:29] scan: title (0) job->width:624, job->height:480
[15:40:29] libhb: scan thread found 1 valid title(s)
+ title 1:
+ vts 1, ttn 1, cells 0->6 (793292 blocks)
+ duration: 00:44:15
+ size: 720x480, aspect: 1.33, 29.970 fps
+ autocrop: 0/0/8/12
+ chapters:
+ 1: cells 0->0, 163338 blocks, duration 00:09:26
+ 2: cells 1->1, 114922 blocks, duration 00:06:46
+ 3: cells 2->2, 116163 blocks, duration 00:06:16
+ 4: cells 3->3, 133411 blocks, duration 00:07:46
+ 5: cells 4->4, 137603 blocks, duration 00:06:53
+ 6: cells 5->5, 127731 blocks, duration 00:07:05
+ 7: cells 6->6, 124 blocks, duration 00:00:01
+ audio tracks:
+ 1, Unknown (AC3) (2.0 ch), 48000Hz, 192000bps
+ subtitle tracks:
+ 1, Unknown (iso639-2: und)
Reading chapter markers from file C:\Users\DanHi\AppData\Local\Temp\VIDEO_TS-1-chapters.csv
[15:40:29] 1 job(s) to process
[15:40:29] starting job
[15:40:29] work: sanitizing track 0 mixdown Dolby Pro Logic II to Stereo
[15:40:29] job configuration:
[15:40:29] * source
[15:40:29] + C:\Downloads\LizR4\FullDisc\ELIZABETHR_4\VIDEO_TS
[15:40:29] + title 1, chapter(s) 1 to 7
[15:40:29] * destination
[15:40:29] + C:\Downloads\Elizabeth R - E7.m4v
[15:40:29] + container: MPEG-4 (.mp4 and .m4v)
[15:40:29] + 64-bit formatting
[15:40:29] + chapter markers
[15:40:29] * video track
[15:40:29] + decoder: mpeg2
[15:40:29] + bitrate 9800 kbps
[15:40:29] + frame rate: same as source (around 29.970 fps)
[15:40:29] + loose anamorphic
[15:40:29] + storage dimensions: 720 * 480 -> 704 * 480, crop 0/0/8/12
[15:40:29] + pixel aspect ratio: 159 / 176
[15:40:29] + display dimensions: 636 * 480
[15:40:29] + encoder: x264
[15:40:29] + options: level=30:cabac=0:ref=3:mixed-refs=1:bframes=6:weightb=1:direct=auto:no-fast-pskip=1:me=umh:subq=7:analyse=all
[15:40:29] + bitrate: 1000 kbps, pass: 0
[15:40:29] * audio track 0
[15:40:29] + decoder: Unknown (AC3) (2.0 ch) (track 1, id 80bd)
[15:40:29] + bitrate: 192 kbps, samplerate: 48000 Hz
[15:40:29] + mixdown: Stereo
[15:40:29] + encoder: faac
[15:40:29] + bitrate: 160 kbps, samplerate: 48000 Hz
[15:40:29] reader: first SCR 1835
[15:40:29] encx264: keyint-min: 30, keyint-max: 300
[15:40:29] encx264: encoding with stored aspect 159/176
x264 [info]: using SAR=159/176
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 PHADD SSE4.2
x264 [info]: profile Main, level 3.0
No accelerated IMDCT transform found
[15:40:29] mpeg2: "Chapter 1" (1) at frame 0 time 3003
[15:40:29] sync: expecting 79608 video frames
[15:40:29] sync: first pts is 3003

[s55]

This is the correct behaviour.

Setting the CPU count optimizes fifo sizes etc. It doesn't set the number of threads HandBrake will use. x264 for example uses 1.5* the cpu count for threads, thus, it won't lower your CPU utilization as there are still enough threads running to max our more cores.

user "threads=3" as part of the x264 options to limit x264

I know about the 2GB of ram issue. Probably a oops on my part. I'll eventually get around to looking into it. I guess i'm using the wrong windows API to find the value as it looks like it's coming up against a per program limit for 32bit apps.

[danhi]

I went to the Advanced Tab, and there wasn't a threads option, so I added :threads=3 to the listbox at the bottom, and it still seems to use all four cores, but it doesn't peg them the way it did before I added that option. Does that make sense?

[s55]

Your not going to be able to just completely stop it from using a core from within HB. OS scheduling will distribute the threads across the cores, and given that HB uses many threads, this is why your seeing utilization across the cores. Reduce the thread count if you want to slow it down further.

The Windows Task manager -> Processes tab, allows you to set processor affinity. this, in theory, would prevent HandBrakeCLI.exe from using a core.