Backing up DVDs is an important topic for many people. Transferring the DVD to a portable format isn’t easy though and can take a lot of time. My daughter is away this weekend and I thought it would be nice for her to be able to watch some of her DVDs on her PC while she’s away. Her netbook, tablet and smartphone don’t have DVD drives (although the netbook has a DVD playback license) so there’s only one thing possible – transfer them to a portable digital format. I’ve tested three generations of Ultrabook with a very simple DVD backup process and the results are below.
The legalities of DVD backups are very country dependant and I believe that the process below could be illegal in my home country if used to back-up a complete DVD. I’m doing the research, doing the testing and leaving it up to you to decide for yourself what to do. During this test I’ve only run the process partially to measure the performance. I haven’t backed up a complete DVD in this test. Again, copying commercial DVDs for backup or transfer purposes could be illegal in your country. Never share copied commercially protected DVD content.
The tool of choice for decoding and encoding is Handbrake, the well-known, open-source video conversion tool. It doesn’t natively support ripping DVDs (the DeCSS process to be exact) but if you’re interested in ‘Fixing Handbrake’ to achieve that, you won’t need to Google search too far to find out about ‘Fixing Handbrake.’ Got it?
Handbrake beta software now supports Intel Quick Sync.
The set-up I’m using here is based around a Samsung SE208 Slim USB 2.0 DVD Writer. (Review) which should be able to read a commercial DVD at 8x speed. It’s connected to the USB3.0 port on the test Ultrabooks. All the Ultrabooks are running Windows 8 without the Media Center pack. Windows 8 and Windows 8 Pro don’t support DVD playback. The Media Center pack, €9.99, adds the required codec for media playback.
Ultrabooks in this DVD rip test:
- Ultrabook 1 – 1st Generation (Sandy Bridge Core i5-2557M 1.7-2.7Ghz, HD3000 media engine.) Toshiba Z830.
- Ultrabook 2 – 2nd Generation (Ivy Bridge i7-3667U 2.0Ghz-3.2Ghz, HD4000 media engine.) Intel Developer Ultrabook.
- Ultrabook 3 – 3rd Generation (Haswell, i5-4350U 1.4Ghz-2.9Ghz HD5000 media engine.) Intel Developer Ultrabook.
Test DVD: Commercial (CSS encrypted.) Fresh from packaging.
Handbrake software in test: http://sourceforge.net/projects/handbrake/files/Betas/QSV/HandBrake-svn5671_x86_64-Win_GUI.exe/download
(The current Intel Quick-Sync-enabled Beta from this download page)
The Handbrake build has been changed to decrypt CSS as detailed in other web pages. (Search Google for ‘Fixing Handbrake’ and look for links to libdvdcss-2.dll from Videolan.)
Handbrake settings.
- Test 1 settings (left image above) – Default ‘QuickSync’ profile.
- Test 2 settings (right image above, without Intel QS) – Default ‘Normal’ profile
The process was left to run for 5 minutes before taking the average FPS reading. 3 minutes ‘cool down’ was left between tests. Ultrabooks were powered by mains with ‘balanced’ energy profile. (Haswell device in use is Connected Standby-capable and therefore has no power profiles.)
Handbrake DVD encoding speed results, with and without Intel Quick Sync hardware.
| Ultrabook in test. (details above.) | Test 1 (Quick Sync enabled) Average frame rate and system CPU utilisation. |
Test 2 (Quick Sync disabled) Average Frame Rate and system CPU utilisation. |
| Ultrabook 1 Sandy Bridge, HD3000 |
105.9 (CPU: 22-30%, No Turbo Boost, No Fan) | 98.2 (CPU: 100%, Turbo Boost active, Fan active.) |
| Ultrabook 2 Ivy Bridge, HD4000 |
107.6 (CPU: 15-23%, No Turbo Boost, No Fan) | 107.4 (CPU: 75-100%, Turbo Boost used, Fan active.) |
| Ultrabook 3 Haswell, HD5000 |
107.3 (CPU: 12-17%, No Turbo Boost, No Fan) | 108.0 (CPU: 55-100%, Turbo Boost used, Fan active.) |
Removing the DVD as a bottleneck
Following a suggestion, I took a direct copy of the DVD video and audio TS folders and placed them onto the local SSD of the Haswell Ultrabook. From there I repeated the process.
| Ultrabook 3 Haswell, HD5000 |
338.0 (CPU: 50-60%, Turbo Boost, Fan) | 148.4 (CPU: 55-100%, Turbo Boost used, Fan active.) |
Clearly the DVD read speed is a bottleneck in the process but the results also show the limit of CPU-based, software codecs and the advantage of using the Intel Quick Sync process, approximately 2X in speed with the Haswell-based Ultrabook and over 3X speed over a software codec on the Sandy Bridge Ultrabook.
Note that the combined time of copying the DVD to the SSD and then running Handbrake is longer than a slower-speed Handbrake-only process. The answer here is to use a faster external DVD.
Important note: I haven’t inspected the results for quality. I’m looking for ‘acceptable’ audio and video from a consumer perspective and I believe that both the Quick Sync and software codecs reach that level of quality. Quality may be an issue for those looking for the highest quality encode.
RipLock, Slow Starts and Queuing
It’s worth mentioning that these tests only include a 5-minute ‘rip’ test. DVD ripping always speeds up as the process progresses as long as the PC can keep up with it. For example, at 40% into the process, I see peak rip rates of 156 FPS and rising. Due to this slow-start effect the DVD-based test results here aren’t showing the true average speed. Also note that Riplock is a ‘feature’ that could limit read speeds of your DVD drive. Damaged disks, incorrect region and other DVD protection features can also slow down the process.
For those doing multiple ‘rips’ it could be better to copy DVDs to ISO’s on a hard drive first and then queue the conversion process in Handbrake to run automatically and unattended. The overall time is longer but the time needed changing discs would be less.
Summary of DVD rip speed results.
The Ultrabook is highly capable of a fast decode/encode process and with Quick Sync enabled in this version of Handbrake it can be much faster, quieter, cooler and more efficient. DVD read speed is the bottleneck in this test setup though.
The Handbrake software encoder often hits a bottleneck with CPU power whereas the Quick-Sync tests show a lot of headroom in the CPU power.
The Haswell Ultrabook running a software encoder was the fastest Handbrake-only (direct from DVD) result by a very small margin although the fan noise and CPU utilisation (which affects battery life) must be considered. The only setup that showed limits in the CPU processing was software encoding on the Sandy Bridge Ultrabook.
The disk-based 300+ FPS speeds seen here are impressive and show the real power of a modern Ultrabook using Intel Quick Sync.
Final note: Copying commercial DVDs for backup or transfer purposes could be illegal in your country. Never share copied commercially protected DVD content.
Let us know about your experiences in the comments below.
Do you use different software? Different hardware? What DVD rip-rate rates do you get?
I hear there’s a regression in Quick Sync encode quality from Ivy Bridge to Haswell. Probably doesn’t matter for non-archiving purposes though.
What are the differences in file size of the encoded videos? Does interfacing with Quick Sync on Core based CPUs mean that it will also work on Clover Trail even though the underlying graphics core is completely different (too bad there isn’t a 32-bit build of Handbrake yet)?
According to this review: http://www.missingremote.com/review/intel-quick-sync-examining-haswell-performance quality mostly improved at the cost of encode time especially when using the “quality” Target Usage 1 setting. TU1 was 1.7x slower on Haswell than Ivy Bridge.
However, they did find a quality regression on 2 video samples which Intel themselves used for their whitepaper.
Even though lookahead wasn’t used, the quality for TU1 showed to be slightly better than x264.
Target usage presets from Haswell and Ivy Bridge are not comparable anymore. It means TU1 on Haswell isn’t comparable to TU1 Ivy Bridge becasue of the higher quality oriented presets on Haswell. TU4 on Haswell runs faster and looks better than TU1 on Ivy Bridge. The test you have linked is also a bit outdated. No lookahead and no mbbrc on Haswell.
Do you have any tests that fairly compares Ivy Bridge and Haswell Quick Sync and x264? I’d like to see some real current numbers.
I’ve read this too, but was unable to reproduce it in my testing (using SSIM to compare frames in several test files). In most cases Haswell was better than Ivy Bridge, and even more surprising better than x264 using CPQ16 (suitable for archiving) & CPQ10.
The tool I used (QSTranscode) is 32-bit.
Does QSTranscode support embedded SRT and SSA subtitles in the in source? If so does it support burning them into the transcoded video? Thanks!
Burning subs into the output is not currently supported. It would be a good feature to add though.
There is no quality regress, it was a Handbrake issue which is fixed in the latest version. The new Handbrake version still use suboptimal default encoding options though. With Haswell for example Balanced preset/Target usage 4 makes much more sense than the much slower quality preset, gop-ref-dist should be set to 0 (SDK default) and lookahead must be enabled via commandline in Handbrake.
The regression was reported by AnandTech using CyberLink Media Espresso as well as HandBrake.
NM, AnandTech’s tests weren’t very well done.
Please provide a link to your results. Thanks.
I forgot gop-pic-size….in most cases SDK default is better than the Handbrake default.
MediaEspresso or any one-click tool in general has a mediocre quality for Quickync due to bad implementation. The first Handbrake Beta suffered from very bad gop values which caused a big quality regression on Haswell. It’s fixed in the new beta, albeit not perfect. Also there wasn’t Lookahead support in the older Beta until now.
Is this only a Windows thing or are the HandBrake devs working on Linux support as well? I have a Linux HTPC that doubles as a transcoding box automated via Bash scripts or manually run via SSH.
As far as I know there is no QSV Linux version of Handbrake in the works. My best guess is that they first try to finish QSV for windows.
I hope they put more focus on getting Quick Sync working on Linux. I, too, automate my encodes using Bash scripts. I also SSH into my PC from my phone to download a TV episode or use a video in my library and transcode it. I then download or stream the smaller video to my phone. Using Quick Sync would hopefully make this faster.
I do the same thing from my phone too. Bash scripts and SSH makes automating things pretty easy. I’ve been putting off replacing my Core 2 Quad based server I slapped together in 2009 until Quick Sync support comes to Linux. Right now, I use the “veryfast” preset which gets similar speeds and quality (just eyeballed) to Quick Sync when it comes to transcoding videos for non-archiving purposes.
When Linux support comes and if the quality and video size becomes pretty close to x264 (ie. not noticeable when viewing on a HDTV from more than 6 feet away) then I may upgrade to fanless dual core server.
I did my own tests, I haven’t seen up to date tests in the public and I doubt anyone did. The problem is that Intel haven’t released an official driver with lookahead support (API 1.7) yet and also Handbrake is in a Beta state. I plan to do a new test once Intel released a new driver. From what I have seen regarding quality Haswell Quicksync TU4 with Lookahead is overall comparabe to some of the faster x264 presets (my tests were all done in 1080p ~5 Mbps). I would say very fast preset is the best match. It depends on the source video of course but overall I currently would place it there.
So if you need the best possible quality x264 medium preset or higher is still recommended, however for the mass the quality of HSW QS should be more than good enough especially for lower resolution videos.
I don’t agree with this especially when looking at TU1 (best). The goal of any comparison is to understand the relative trade-offs b/w items. If HSW TU4 is better than IVB TU1 it would be valid to extend a comparison to include backing for that.
AFAIK, the driver enabling lookahead is not available so it’s hard to say with validity that the results are outdated.
That said, QSTranscode supports MBBRC & lookahead (when it drops).