Fast CPU for video transcoding? Xeon?

Joined
Jan 14, 2002
Messages
1,877
Location
44.8, -91.5
My i5 3570 is feeling a little pokey trancoding video. Will I get much improvement using a newer CPU? Would a Xeon be worth it? I would want to run it stock and not OC it. Would prefer to spend <$500 on a new motherboard and CPU, and I already have 32 GB of DDR3-1600 RAM I'd want to recycle.
 
What are you encoding to? and what software are you using?

For example, if targetting h.264, then nVidia cards can do GPU accelerated encoding via "nvenc" (uses CUDA)...

Xeon's won't really help (unless you want to go socket2011, where the E5 can offer more cores/cache) but than depends on the software you are using. If your encoder is single threaded, then the fastest i7 will be about it...
 
You need to provide more details. What sort of transcoding are you doing? What software are you using? How long does it currently take? How long would you like it to take?

My initial suggestion would be add cores (real and virtual), but that could be totally wrong depending on the SW you're using.
 
Handbrake. DVDs to h.264. Onboard video, presume it's all CPU-based. Maxes out my 3570s 4 cores. Takes 30 minutes now. Would be great it it could take half that time.
 
The right answer is probably still "it depends" but more and faster cores definitely help it. If you're seriously bottle necked in your workflow by your CPU, moving to an LGA2011 system with 6/12 cores would be a start. In my case, I found the biggest problem was having to wait an hour for 30GB of M2TS files to come off a Blu-Ray disc, but it's actually fairly easy to distribute the workload to multiple PCs if you've got them.
There are also encoding products that can take advantage of GPU transcoding, but Handbrake really doesn't do anything meaningful with it.
IIRC, when I was testing encoding tools, I couldn't find one with GPU encoding support that also offered to let me keep audio tracks in an unmolested state and I found that to be a deal-breaker.
 
Handbrake uses x264 which scales pretty well with CPU usage unless you're using a speed / quality preset that doesn't saturate all the cores. A 6 core Intel i7 processor (with HT) is probably the best way to proceed.
 
It looks like the cheapest 6-core LGA2011 CPU is an E5-2620 Sandy Bridge-EP, for around $400. Does this seem right?

Handbrake using x264 definitely saturates all 4 (physical) cores of my 3570. IIRC, doesn't the newer chips use AVX or some other extensions to speed h264 encoding? Not sure it matters, but I'm doing my ripping and transcoding on Linux. If anybody knows of a faster program to transcode, I'm all ears. For most of my stuff (kids stuff, where I don't want them handling the DVDs), quality isn't a paramount concern.
 
Would VT-d and transactional memory (in the new Devil's Canyon chips, like the 4790) be of any benefit on my encoding machine that might also run some virtual machines?
 
Any reason my old Asrock Z77 motherboard couldn't use the newer Devil's Canyon chips like the 4790? Wondering if the simplest solution is just to drop in a new chip. Is hyperthreading helpful for video transcoding?[h=2][/h]
 
Handbrake. DVDs to h.264. Onboard video, presume it's all CPU-based. Maxes out my 3570s 4 cores. Takes 30 minutes now. Would be great it it could take half that time.

I can handbrake a DVD to h.264 in 15 minutes on an i5 750... of course, that's using one of the profiles optimized for an iPad. Your encoding settings will have a big result on speed. It may be more cost effective to look at the 'constant quality' (quality vs bitrate trade-off) setting or the x264 preset (quality vs speed trade-off). Point being that you can save yourself hours of encoding by sacrificing a few MB of storage: set the quality a notch higher (lower number) and choose the faster encoding preset.

--Blake
 
Wondering if the simplest solution is just to drop in a new chip. Is hyperthreading helpful for video transcoding?[h=2][/h]
Yes, HT helps to the tune of 15-20% or so. What do you have against overclocking? A overclocked Haswell i7 with HT will be pretty fast. Devil's Canyon is only compatible with 9 and 8 series chipsets and the 8 series chipsets require a BIOS update to make that happen.
 
I did kind of play around with running handbrake on 2 -3 4CPU Hyper-V guest instances on my big home server vs. my 3770k, but only with 5 minute test clips. I wasn't doing anything too serious, but the 8 cores of relatively new i7 about 20% faster for doing the same work than two 4 core VMs on an older SMP Xeon. Running 3 instances, the VMs won out.

I have to ask: How much stuff are you planning to encode that you're thinking of buying a PC and devoting the time to doing this?
 
Not planning on encoding that much, but this is becoming a bigger piece of my computing life so I was basing my next computer build around this type of workload. I just don't game anymore.
 
Handbrake supports a work queue and it's highly scriptable (the GUI is just a front-end to the CLI anyway; it even shows you the command it's going to run). You can spend hours copying source files off disks, but it only takes minutes to set up a job queue of 10 movies, and you can process the queue whenever you damned well please. I wanted it to happen quickly because I had a deadline associated with the number of discs-by-mail service I belonged to. Even if I specify ridiculous quality settings, any single job I feed to a modern i7 is going to be done in a few hours at most.
 
So would you rip the DVD to disk and then later transcode it? Anybody have a favorite ripping program for Linux?
 
So would you rip the DVD to disk and then later transcode it? Anybody have a favorite ripping program for Linux?

Personally, I normally just rip direct from disk (via ffmepg or mencoder cli), but on occassion have used ddrescue to extract the disk to an ISO, and perform a normal conversion based on the ISO...

(ddrescue is like a regular dd, but has options for skipping and retrying bad blocks, which is useful for some "protected" disks).
 
No idea. Speed isn't really an issue for me. I just have a bank of USB BluRay readers (same number of readers as simultaneous disks in my NetFlix Sub, coincidentally). So timing isn't really an issue. Takes longer to name them and pack them.
 
Save yourself a bunch of time.....get yourself a Tweaknews account & download most of the pre-encoded MKV's you want from Usenet via SSL for free.
 
Save yourself a bunch of time.....get yourself a Tweaknews account & download most of the pre-encoded MKV's you want from Usenet via SSL for free.

You can get the same stuff from lots and lots of different sources, but there's still something to be said for encoding the stuff yourself so you can preserve soundtracks and grab extras from a disc if you want.
 
I've been playing with Handbrake's HEVC encoding options on a Linux VM. If I specify the usual bit rate for a BD encode (4000kb/s), I get a file that's about 20% smaller than x.264 but an encode that takes about 40% longer. I can't see a quality difference. I must be missing a library to enable encoding under Windows, because the option isn't present in Windows nightlies.
20% space savings on a 5.5GB file is definitely nothing to sneeze at, but I was expecting more than I got.
 
Is Handbrake using x265 as its HEVC encoder? Most of the folks on the doom9 forum are unhappy with x265 if they're after a high quality transparent encode. They say x264 has better image quality that x265 can't match no matter the bitrate or settings you use. However, if you want something that looks acceptable at lower bitrates, but isn't necessarily faithful to the source it does quite well at bitrates x264 can't match.
 
It certainly doesn't look BAD. My test encode was the Zeffarelli production of Turandot, which has a crap-ton going on on-screen. Lots of blacks, lots of difficult to compress complexity. I can see small differences side by side on frozen frames, but it's nothing to complain about, though I may have been too generous with bit rate to be able to make a comparison.

Sounds like x.265 might work better for things like episodic TV content, but I typically don't bother to rip that stuff myself.
 
x265 is still pretty new relatively speaking, so it should get better with more tuning and tweaking. But people who are using it instead of x264 for high quality Blu-ray rips are likely doing themselves a disservice.
 
Hopefully you will be able to make use of your nvidia maxwell series GPU for H.265 encoding in the near future. Their NVENC SDK version 5.0 shows support for multiple simultaneous encoding streams. As of right now I haven't done enough Google searching to see if anyone has written code to use it yet (like a handbrake plugin). This doc has some performance benchmark numbers in FPS for encoding H.264/H.265.
 
I haven't found anything that supports hardware encoding to that degree. Handbrake has limited support for it during a small part of the overall process, but their docs say that it doesn't help on fast CPUs and I've never bothered to turn it on. In the past, the software I found with full hardware encoding support did not allow me to retain source audio or had some other game-breaking compromise, which is why I've stuck with Handbrake for as long as I have.
A lot of the commercial applications I've found seem to want to write everything into an MP4 container. I know I can strip video from that and audio from the source and write a proper MKV if I really need to (for example, to maintain a DTS-HD soundtrack) but that's too damned much work to do by hand and if I want to automate it's WAY more work than I want to do.
 
Back
Top