Video Transcoding Examined: AMD, Intel, And Nvidia In-Depth

Page 2 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
Toggle sidebar Toggle sidebar
Status
Not open for further replies.
Thanks andrew for posting the images at zumodrive! I ended up finishing the article and looking at the comparisons; definitely a very informative read; thanks for writing it up
 
[citation][nom]spammit[/nom]Thanks andrew for posting the images at zumodrive! I ended up finishing the article and looking at the comparisons; definitely a very informative read; thanks for writing it up[/citation]

You betcha! I didn't want to spoil the conclusion, but it kind of makes the comparisons on the previous pages kind of moot given there is almost no definitive way to declare a winner. 😛
 
I tried almost every media converter out there and found that some very overlooked programs can do way better than some of the big names in the business, in regard to good combination between quality, file size, and speed.
 


They would be using software encoders though. This is about GPGPU.
 
[citation][nom]amien[/nom]Thanks very much for that info, I'll be using Premiere Pro cs5, so i'm not sure if that supports Quick Sync? Out of interest, what card was used (if any) in the cpu benchmarks at[/citation]

Premiere pro CS5 does not support quick sync. There may be some performance boost it can take advantage of, but they will need to re-write their exporter for full support. However, CS5 suite has excellent support for CUDA (nVidia) cards, which makes it a moot point as it will use CUDA for software encoding/editing instead of the CPU anyways.
Also note that the presence of a GPU will by default disable the on-board video anyways. So the review of this process is mostly for the benefit of laptop users who do not have nice add-in cards and need to take overhead off of their CPU.
Lastly, Premiere Pro is a great editor, but not an encoder or cleaner. I am 2 gen behind you on software, but even with my friend's CS5 premiere the export (when transcoding) is relatively slow, and not best quality even with the best codecs. You should export to whatever format you are editing in, and then use a script based program such as AVS/AVSp combined with Virtural Dub for your final compression to AVI, or just use quiktime Pro for .mov or h.264 compression. AVS will give you extreme amounts of control over your file size, quality, and post-production cleanup, as well as give you faster export times for most compressors (obviously this depends greatly on how much cleanup you do, as a lot of cleanup in post will take time).
Obviously, never edit in a compressed format as the lack of key-frames can mess with your cues and transitions. You can use fully key-frameable compressors (such as h.264 which can be fully key-framed, lagarith, or others) which will save some space, but will give excellent quality without degradation on editing. This will also allow a near instant export because only transitions need to be rendered, then use AVS for your final encoding/transcoding. Again, not the simplest software to use, but it can give that nice pro result without the cost of a pro exporter.
 
Thanks for a great article! I was wondering how these new GPGPU processes would stack up, and it looks like they will do well. Still seems like it isnt much advantage for those doing more in-depth editing and cleanup for poorly encoded DVDs (lol, is there a poorly encoded Blueray? They are all so pretty!), but it will make short work for those just interested in making digital copies of their libraries with good quality!
Thankyou also for not joining the muck of last weeks hardware quality playback test. Nobody uses their hardware for playback for a reason, but at least there is now a good option for encoding on laptops!
 
Clearly a lot of work has gone into this, two major issues though both can be summed up that you need a control group on your experiment

1) where are the original frames? you talk about one solution producing better colour saturation or a more pleasing image but surly what you want is an image that visual indistinguishable from the original? only if that cant be achieved at the bit rate your using does how nice it look relay matter, the producer might want parts t appear washed out.

2) where is x264, its generally considered the best quality encoder, I know the article is about quality/speed of hardware accelerated, but what's the point if you don't have a reference about what you can do with CPU only.
 
[citation][nom]timmyag[/nom]Clearly a lot of work has gone into this, two major issues though both can be summed up that you need a control group on your experiment1) where are the original frames? you talk about one solution producing better colour saturation or a more pleasing image but surly what you want is an image that visual indistinguishable from the original? only if that cant be achieved at the bit rate your using does how nice it look relay matter, the producer might want parts t appear washed out.2) where is x264, its generally considered the best quality encoder, I know the article is about quality/speed of hardware accelerated, but what's the point if you don't have a reference about what you can do with CPU only.[/citation]

Technically there is no baseline. If you read the devil's advocate page then you know there is no way to isolate the decoder and renderer out of the image quality comparison. The very act of pressing play skews testing methodology. Once we introduce x264 we introduce other variables such as the software title. This has long been known by people within the industry. And if you read the whole article then you also know we did CPU software encoding. The article has been divided up into decoder and encoder because there are two steps in the transcoding process. Both affect output.
 
[citation][nom]intelx[/nom]first thanks for the article i been looking for this, but your gallery really sucks, i mean it takes me good 5 mins just to get 3 pics next to each other to compare , the gallery should be updated to something else for fast viewing.[/citation]
[citation][nom]_Pez_[/nom]Ups ! for tom's hardware's web page , Fix your links. !. And I agree with them; spoiled1 and spammit.[/citation]
[citation][nom]intelx[/nom]first thanks for the article i been looking for this, but your gallery really sucks, i mean it takes me good 5 mins just to get 3 pics next to each other to compare , the gallery should be updated to something else for fast viewing.[/citation]
[citation][nom]cpy[/nom]THW have worst image presentation ever, you can't even load multiple images so you can compare them in different tabs, could you do direct links to images instead of this bad design?[/citation]
[citation][nom]spammit[/nom]omgf, ^^^this^^^.I signed up just to agree with this. I've been reading this site for over 5 years and I have hoped and hoped that this site would change to accommodate the user, but, clearly, that's not going to happen. Not to mention all the spelling and grammar mistakes in the recent year. (Don't know about this article, didn't read it all).I didn't even finish reading the article and looking at the comparisons because of the problem sploiled1 mentioned. I don't want to click on a single image 4 times to see it fullsize, and I certainly don't want to do it 4 times (mind you, you'd have to open the article 4 separate times) in order to compare the images side by side (alt-tab, etc).Just abysmal.[/citation]
[citation][nom]spoiled1[/nom]Tom, You have been around for over a decade, and you still haven't figured out the basics of web interfaces.When I want to open an image in a new tab using Ctrl+Click, that's what I want to do, I do not want to move away from my current page.Please fix your links.Thanks[/citation]
^THESE +1

Here's a link to the feedback article related to this complaint:
http://feedbacks.tomshardware.com/forums/16334-article-ideas/suggestions/183788-redesign-the-picture-galleries
 
So ... In a nutshell ... For CS5 workflow ... With down-convert to 720P output ...
... Roll your eyes, cross your fingers, flip a coin, and shrug your shoulders.

... I'll be sure and pass that along to my customers. Thanks !!

At least, now, I can explain the differences, with absolute clarity !
... So glad that I will no longer appear to be a clueless dolt, when it comes to recommending X58, rather than waiting for SB Pro Graphics Solutions (not to mention nVidia vs. AMD) ... or ... Quadro vs. GTX/FERMI ...

Really nothing I can get any sort of traction with, here ... at ... all.

I guess the best thing to do is to recommend nVidia + CPU-core-count + massive RAM and SSDs ... and just hope the situation will improve, thru the evolution of drivers, apps, codecs and libraries.

Onward, thru the fog !

http://www.tomshardware.com/forum/300314-31-high-personal-workstation-guidance


.
 
[citation][nom]Alvin Smith[/nom]Roll your eyes, cross your fingers, flip a coin, and shrug your shoulders. [/citation]

That is almost the start of a good Jack Handey quote. :)

http://software.intel.com/en-us/articles/adobe-premiere-propremiere-elements-encoder-plug-in-using-intel-media-sdk-and-intel-quick-sync-video-technology/

That is a prototype plug-in published by Intel in order to use Quick Sync with Premiere Pro. I haven't tried it myself, but it looks interesting.


 
OpenCL ... As much as I hate that Apple holds the copyright for the name and logo, it is the best alternative in my opinion. I don't care if CUDA is 5% faster, the fact that it can be parallel-ized across AMD, Intel, IBM, and several other architectures as well as function equally well on Windows and *nix (Linux and OSX) makes up for it and eliminates vendor lock-in, which you are familiar with if you have EVER purchased an Apple product.

As for the article, you should check out the Linux transcoding apps. I actually have my blu-ray ripping/decrypting scripted up to almost no user interaction. :)

 
Thank you for the article. Video encoding has been somewhat overlooked on here since 3D performance is such a driver in the industry. For me personally, video encoding performance is more important than 3D performance when choosing hardware.
 
I fully agree with Miharu. Most of us readers here in fact currently use with X264 or MainConcept software encoders. They are the de facto standards, precisely because they provide excellent quality and good speed. Any review of encoder quality that doesn't include them is incomplete. Not all software encoders are alike.

Another suggestion - you should include objective quality comparisons as well as subjective ones. You can add objective quality comparisons by using the MSU Video Quality Measurement tool. It works very well. The two most widely used metrics are SSIM and PSNR. Take a look at their annual encoder quality comparisons as well for some ideas, as well as to understand why X264 and MainConcept are the de facto standards.
 


Please read the entire article. We established within the article that all software encoders and decoders are not alike. We actually have screenshots that show this. Furthermore, we also went over why PSNR is itself subjective. The annual encoder quality comparison (assuming you and I are talking about the same study), is a 9 month long study. We did this in 1.5 weeks. And this was not about x264 or MainConcept. This is about GPGPU.

If you are a stickler for quality, there is no way you are even considering CUDA, Quick Sync, or APP. We established that as well. This is a well known within AVS, makemkv, doom9, and the videohelp forums. Additionally, comparing against those two encoders skews the scientific process as we were already isolating renders, scalers, and software. As Chris says, sorry but princess is in another castle.
 
This test really hurts heavily the reviewer who wrote this seems to actually have only half the knowledge of what he actually does here, as he should know that the Decoder alone (not important if Software or Hardware) in case of H.264 shouldn't show any quality differences @ all or it's not Spec Compliant. I highly doubt the differences here shown are coming from the Decoders but more of the used Frameworks and there the Reviewer seems to have no idea how they actually work and what they do 😉
Just wait for some better tests who really look deep inside this on some sources you can trust like Doom9 for example :)
 
[citation][nom]Kolosos[/nom]This test really hurts heavily the reviewer who wrote this seems to actually have only half the knowledge of what he actually does here, as he should know that the Decoder alone (not important if Software or Hardware) in case of H.264 shouldn't show any quality differences @ all or it's not Spec Compliant. I highly doubt the differences here shown are coming from the Decoders but more of the used Frameworks and there the Reviewer seems to have no idea how they actually work and what they do Just wait for some better tests who really look deep inside this on some sources you can trust like Doom9 for example[/citation]

If you browse Doom9, there are plenty of experts who confirm that decoders are not all created equal. While the framework for a decoder will differ, it is the end quality that is effected regardless of spec. Again, if you had read the entire article then you would have know we covered that.

I'm actually quite familiar with the decoding process. If you ask Sam Blackwell or any of the experts out at MainConcept, they would confirm our statement (which we actually did). Remember decoders are more than just spec, decoders themselves include code to correct bit rate fall off. Because of that, its harder to isolate differences in transcoding output. Unless you have a research industry grade decoder, everything in the article applies to you.
 


You seem to have no problem mocking people who consider quality an issue, thought. The mislead photographers, calibrating their displays, who cares about that, all you need to do is tick "auto". Calibrating HDTVs should be standard service offered by shops - After all if someone buys a 2000euro TV, they do not get 15min calibration done by a 200 euro calibrator included in the cost? :sarcastic: Buying aforementioned 200 euro calibrator is less sensible option, tho, given you only need to do it once every few years at outset.

The main issue WRT x264 vs GPGPU encoding, which you keep on sidestepping whether it does produce superior results with smaller bitrate and/or faster encoding with approximately equal cost of hardware. One year ago badaboom and their ilk were not even in the running with x264 matching quality at less than half bitrate.

You seem to have the answer to that, given how much you like to tell us the gpgpu quality is 99% of software encoding at 4x the speed (and equivalent bitrate) or if it isn't, it will be in 2 months and anyone who could notice the missing 1% is a sad person who should get a life.
 
You kids are freaking retarded

MPC-HC supports hardware acceleration. Can't believe you children have never heard of it.

http://imouto.my/watching-h264-videos-using-dxva/

 
[citation][nom]johnsmithhatesvlc[/nom]You kids are freaking retardedMPC-HC supports hardware acceleration. Can't believe you children have never heard of it.http://imouto.my/watching-h264-videos-using-dxva/[/citation]
Did you eat paint chips as a kid?
 
Status
Not open for further replies.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom