Currently we are telling users that transcodes generally take as long as watching the video in real time, so if the user uploaded a 2 hour movie, our goal is to transcode it into 4 streamable mp4s in 2 hours or less.
To accomplish this, we've ordered up a 'massive' server from Softlayer
Quad Intel Xeon E7-4850v2 (12 core / 24 thread 2.3Ghz). When I cat /proc/cpuinfo it shows 96 CPUs. The system also has 512GB DDR3 2133, and 4 x 800GB SSD's in RAID10.
We're running CentOS 6.7 64-bit on the system: 2.6.32-573.12.1.el6.x86_64 #1 SMP Tue Dec 15 21:19:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
I just compiled the latest version of HandBrake from github, 0.10.3. When compiling, I did ./configure --launch --disable-gtk
Everything compiled fine. But I did notice when running ./configure it said CPU count was 32...
Here are the commandlines we are currently using to create our proxies: (please note, i didn't come up with these, so I dont know if they are the best options to use... again our goal is to create Web Optimized mp4s for streaming with Wowza...
Code: Select all
/usr/local/bin/HandBrakeCLI -i '/root/4k.mp4' -o ~/4k-360p.mp4 --encoder x264 -O --decomb="fast" --loose-anamorphic --modulus 2 --vfr --x264-preset=medium --x264-profile=main -w 640 -q 22
/usr/local/bin/HandBrakeCLI -i '/root/4k.mp4' -o ~/4k-480p.mp4 --encoder x264 -O --decomb="fast" --loose-anamorphic --modulus 2 --vfr --x264-preset=medium --x264-profile=main -w 853 -q 22
/usr/local/bin/HandBrakeCLI -i '/root/4k.mp4' -o ~/4k-720p.mp4 --encoder x264 -O --decomb="fast" --loose-anamorphic --modulus 2 --vfr --x264-preset=medium --x264-profile=main -w 1280 -q 22
/usr/local/bin/HandBrakeCLI -i '/root/4k.mp4' -o ~/4k-1080p.mp4 --encoder x264 -O --decomb="fast" --loose-anamorphic --modulus 2 --vfr --x264-preset=medium --x264-profile=main -w 1920 -q 22
Here is a snapshot of atop during the transcoding:
As you can see, we are not redlining the CPU as I had expected... doing this on other servers we tested always sent the CPU to 100%. On this machine it looks like it's about 35% CPU usage...
Speed is our key factor we're going for here... Users spend a long time waiting for their upload to complete, then they submit them for transcoding and have to wait "in the dark" for the transcodes to complete. We don't currently have a way to display the transcode progress to them, so they just have to wait for completion. We are hoping to reduce our customer's wait times as much as possible.
Here's a few Benchmarks
1080p source video 10 minutes long 189MB transcoded all 4 proxies in 3 minutes and 10 seconds... This was great!
2160p source video 68 minutes long 7.8GB transcoded all 4 proxies in 74 minutes... this is great compared to all our previous transcodes, but still not under our target, and based on the results of the 1080p test, i was hoping this one would have completed in about 25 minutes or so, but that wasn't the case...
Some other thoughts... during these bench marks the files were read and written to the SSD drives which benchmark at about 1.5GB/sec so I dont think disk IO speed is a factor here...
Activity Log: http://pastebin.com/CsDX6an5
Only one question arises from that log: It says CPU count is 64... Should be 96.
OK all the information is out on the table, does anyone have any suggestion on how we could reduce our transcode times either by tweaking our ./configure commandline or our ./HandBrakeCLI command line?
Thanks in advance!
Russ Purinton
RushTera