POST A COMMENT

34 Comments

Back to Article

  • mediaconvert - Wednesday, January 28, 2009 - link

    I record a lot of tele on my computer and am always wanting faster ways to convert and compress my videos. When I heard about ati producing an equivilant of badaboom I was really excited and thought I could finally justify spending £150+ on a graphics card especially when it would be faster than the cpu. I have a ati 3450 and man was I dissapointed. I tried to compress a 120mb mpeg2 file and ended up with a 150 mb file. Also if the reviews are right it doesn't use the gpu. whats the point in having a gpu converter that doesn't use the gpu??? I can only speak for myself but if amd/ati comes out with a serious way of quickly converting/compressing the mpeg2 files (perhaps also with a batch processing mode) then they have a sale here especially if it allows me to play the latest video games.

    Currently I have been looking at video cards and I have to say there are two things pushing me to nvidia one is badaboom and the other nvidias hybridpower (use of an nvidia motherboard integrated graphics to reduce gpu usage and hence gpu fan noise when gpu is not needed)

    I recon ati/amd needs to get creative here and really commit to gpu video conversion. ( or even gpu + cpu video conversion ) If they can produce real world speed benefits then people will buy it.
    Reply
  • Focher - Wednesday, December 17, 2008 - link

    I have a 3-way SLI of 280s with a QX9650 CPU. I have both Badaboom and TMPG Xpress, both of which support GPU encoding. In my experience, I can actually encode video a bit faster with just the CPU. Badaboom apparently supports multi-GPU configurations now, but only to split encoding when you have queued multiple files. TMPG Xpress is definitely the more powerful and capable tool, but doesn't support multiple GPUs. Also, Badaboom apparently just released 1.1 that adds quite a few features but I have not yet tried it. Reply
  • Rainman200 - Wednesday, December 17, 2008 - link

    Just assign resources to help the developers of x264 to make use of GPU's through OpenCL and that will do more good than any of these waste of time apps.

    Anand I'd definitely say the x264 is sharper vs Badaboom in the two pictures you posted, also please use Ribot264 or AutoMKV as they use the latest builds of x264, Handbrake trails development of x264 because of its Apple Mac focus so important features added to x264 which improve its image quality are left out months behind other x264 encoders.
    Reply
  • dryloch - Wednesday, December 17, 2008 - link

    I had a few ATI cards years ago but have been using Nvidia recently. I decided to try a 4800 series ATI card this time around partly because I hoped the number of stream processors would be useful for stuff like this. I have been looking forward to this driver for months and now they release something that doesn't work. My time is valuable to me ATI, don't waste it trying to make somthing work that you know is broken. I don't care what happens with the speed of the next gen cards I am going back to Nvidia. Reply
  • toyotabedzrock - Tuesday, December 16, 2008 - link

    http://www.pcper.com/article.php?aid=647">http://www.pcper.com/article.php?aid=647
    This review seems to have gotten it to work better. Althought still not flawless.
    Reply
  • talmholt - Tuesday, December 16, 2008 - link

    Anand,

    I think some of your issues are coming from Vista. I have used the converter on a WinXP32 machine with good results. It converts a 2 hour movie (MPEG2 640x480 3GB initial size) to an iPod file (320x240 500MB final size) in 8 minutes and the result is flawless!

    I have also tried converting HDTV (OTA) content to a DVD format and that worked great too.

    PS, my system is only a Intel Core 2 E6420 with a AMD 4850 (everything at stock speeds). Please try again Anand.

    Thomas
    Reply
  • Chris Simmo - Tuesday, December 16, 2008 - link

    I use handbrake, but noticed something wierd. I had a 9800GT in the system, using handbrakes default movie options x264 and I would get about 150 turbo first pass, 48fps second pass on my overclocked q9400@3.5. I changed the graphics over to a HD4850, and saw an option for VP3. I selected it, the CLI crashed, the handbrake UI was still running though, changed back to x264, and then it was 290 turbo first pass and over 150 second pass. This is running vista 64 with the 8.12 drivers. During this time the GPU temp went up 2 degrees, all four cores were at 100%. I really need some one else to have a play and see what they get. I put in a 4870 to try, but I hadn't worked out the VP3 thing yet, so it didn't change form the standard 48fps Reply
  • Chris Simmo - Tuesday, December 16, 2008 - link

    Sorry, that was 'Shaun of the dead' DVD to MKV, Reply
  • niuniu2012 - Wednesday, March 10, 2010 - link

    You can use http://www.dvdtomp3converter.com/">http://www.dvdtomp3converter.com/ to select target subtitle and audio track according at your will. DVD to MP3 Converter also provides you with fruitful options to set audio properties of audio bitrate, Sample Rate and so on. Reply
  • piroroadkill - Tuesday, December 16, 2008 - link

    "Last year, NVIDIA introduced it's CUDA"

    it is CUDA!
    Reply
  • SkullOne - Tuesday, December 16, 2008 - link

    GPU encoding is not supported by Vista 64-bit at this time. So if Vista 64-bit is being used that would explain why it was CPU based.

    This is straight from the 8.12 release notes: "The ATI Avivo video transcoder does not currently use GPU acceleration under Windows Vista 64-bit edition."

    Now with that said under Vista x64 I do not get nearly the same amount of corruption as seen on the review but I do get it. Hopefully those bugs are worked out in the future.

    I can successfully encode any VCD/SVCD MPEG to iPod size without a single issue. DivX files encode down to iPod size with some video corruption although it appears that the better the DivX encode the less corruption I get the in the iPod file. Xvid files just dump out audio with no video. I can't even try to covert an h.264/x264 based MKV file as Avivo doesn't recognize the container.

    Hopefully ATI addresses these issues quickly.
    Reply
  • DigitalFreak - Tuesday, December 16, 2008 - link

    Wow, good catch. There was some mention of using Vista 32bit on a few encodes, but I have to wonder if they were using Vista 64bit during the timed run. Reply
  • DerekWilson - Tuesday, December 16, 2008 - link

    We used 32-bit for everything but those 64-bit stills. AMD didn't tell us about the issues with 64-bit until we brought them up with them, so we switched half way through.

    All the performance tests were done on 32-bit vista.
    Reply
  • DigitalFreak - Tuesday, December 16, 2008 - link

    Thanks for the clarification, Derek. Reply
  • nissen - Tuesday, December 16, 2008 - link

    Is it Badaboom 1.0 you are using when talking about cpu usage? because here on my duo e6600/gtx280 badaboom eats just between 10-20% of the cpu depending on input ( ~15 for 1080i h264, ~20 for dvd ) , definatly something wrong.
    Reply
  • MojaMonkey - Tuesday, December 16, 2008 - link

    On page 7 you have the 9800 GTX+ outperforming the GTX 260 is this correct or have you got the labels wrong?

    I'd expect the GTX 260 to perform better than a GTX+
    Reply
  • dvinnen - Tuesday, December 16, 2008 - link

    "And since when is video transcoding not a deterministic process?"

    Cool product from AMD and I'm sure it will get better over the coming months, but how do you manage to do that? Weird.
    Reply
  • The Preacher - Saturday, December 20, 2008 - link

    Ever heard of dithering? If you use that and seed the random generator using system time (not really a bright idea) you could get slightly different results each time (I doubt you could actually SEE the difference).
    http://en.wikipedia.org/wiki/Dithering">http://en.wikipedia.org/wiki/Dithering
    Reply
  • plonk420 - Tuesday, December 16, 2008 - link

    this review is irksome... no mention of x264 version, no mention of resolution or bitrate used on the chart. as a previous comment says, the PQ on the x264 encode looks like the resize was screwed up... the comparison to a software solution was pretty poor. Reply
  • plonk420 - Tuesday, December 16, 2008 - link

    http://plonkmedia.org/demo/test.html">http://plonkmedia.org/demo/test.html <-low resolution stream (zoomed 2x)
    http://www.megaupload.com/?d=ECOIUXQL">http://www.megaupload.com/?d=ECOIUXQL <-low resolution download
    http://www.megaupload.com/?d=TPJVM0Y6">http://www.megaupload.com/?d=TPJVM0Y6 <-high resolution
    http://www.viddler.com/explore/plonk420/videos/1/">http://www.viddler.com/explore/plonk420/videos/1/ <-what i'm assuming is a transcode (but same site that Anandtech used)
    Reply
  • plonk420 - Tuesday, December 16, 2008 - link

    quick and dirty tests... (emphesis on dirty; i have Opera with 30+ tabs open, uTorrent, VNC Viewer, handful of other programs open)
    source: Star Wars 4 VTS_02_4, 18 mins
    low res: 320x128 took 310 seconds (±10 sec), processor use was ~30-40%
    high res: 640x272 took 325 seconds (±10 sec), processor use was 60-70%
    bicubic resizing, no cropping to exactly 2.39:1; couldn't be arsed. just used MeGUI's default iPod encoding settings, but set Quant 19. did SubME 2, 4, 5, and one test with 6 (the high res). it didn't seem to change the time it took to encode.

    i'm sure you could up quality, significantly, too with better resizing options (i ususally use Lanczos4), other iPod compatible switches, at minimal speed cost. i don't usually encode for low bitrate/PMPs, but settings to do so are a google away.

    but this pq looks decent to me. no issues the hardware encode had. using x264 has a BIT of a learning curve, but can be as fast as these hardware solutions (and possibly excede PQ with the proper options). recent builds have Peryn, i7, and even Phenom optimizations (that weren't utilized in one of the other site's i7 x264 tests).

    my tests were encoded on a "mere" Phenom 9550 @ 2.2ghz on Vista x64 SP1, drives fragmented to hell.

    options were --qp 19 --level 3 --nf --no-cabac --partitions none --merange 12 --threads auto --thread-input --progress --no-psnr --no-ssim (with --level being 1.3 for low or 3 for high, and --subme being 2, 4, 5, 6). build was 1051 (a few builds out of date; 1055 has better CAVLC PQ according to changelog)
    Reply
  • mvrx - Monday, December 15, 2008 - link

    I've been grumpy about this for years. Most all the commercial video editing packages have treated mananging and encoding 1080p as a pro-only, or "coming next year" feature.. 1080p isn't pro folks. It's consumer level.

    I have to use StaxRip with x264.exe encoder to do what I really want, as most commericial packages still have issues with 1080p. Everything should be ready for any resolution, including super high def. Don't try to charge customers more just because they are ready for what will be considered common in another year or two.

    I'd also like to see the upconverting technolologies that HD dvd/BR players do in real time mature for software converters. I'd like to take my home movies and DVDs and convert them to 1080p, then encode to h.264. I know that doesn't give me true native quality content, I just like the idea of standardizing all my media to 1080p.
    Reply
  • MadMan007 - Monday, December 15, 2008 - link

    Thanks for keeping up with these articles. GPGPU's killer app for most consumers is video encoding. One thing that's missing from this article as was alluded to by an earlier comment is a reasonable price comparison - I'd like to see how the GPGPU encoders stack up to a dual core CPU since adding a video card is a much easier upgrade and lots of people have dual core CPU systems already. Reply
  • psychobriggsy - Monday, December 15, 2008 - link

    It's interesting comparing this review to the Avivo vs Badaboom article I read elsewhere earlier this month (using the leaked pre-release Catalyst) where they achieved significant performance improvements over using a CPU (i.e., it was actually encoding on the GPU in that review, whereas the conclusion here is that it isn't). They didn't use a Core i7 however. Still, when it comes to using a $200 video card with a $200 CPU, or a $1000 CPU to achieve the same thing, the choice is obvious (well, when the quality is sorted out).

    Regardless AMD really shouldn't have released Avivo in that state, or they could have at least just called it a preview. What's wrong with AMD/ATI's developers? Don't they have any pride in their work?
    Reply
  • bobsm1 - Tuesday, December 16, 2008 - link

    Looks like Anand is actually reviewing the products instead of taking the marketing crap that is being provided and just posting it. Takes a bit more work but the result is more interesting Reply
  • daletkine - Tuesday, December 16, 2008 - link

    I used my Sapphire Toxic 4870 to convert the MPEG2 recording of Lost in Space VCR tape, to DivX using Avivo Video converter. My size went from 5.10GB to 3.48GB, from 720x480 (12Mbps) to 640x480 (converter doesn't give res options). Speed wasn't drammatic, like around 40min for 2h10min movie, on an Athlon 64 X2 @ 3.23GHz. CPU was utilized 100% and GPU was utilized (can be seen with RivaTuner) around 8-10%. Video quality was great, nothing to complain, no artifacts like anand pointed out, looks fine. So, seems to have worked for me, but not what I expected. The bad: WMV displays artifacting just like anand showed, Catalyst 8.12 drivers have issue with Xvid stuttering playback, so I saw that in WMP when playing my converted file (solved by using VLC player), no compression that I can see taking place (I used max quality setting, but medium only gives savings of 500MB, don't know about low), and it still needs a quad core.
    The good: it actually works for me, free, simple, good quality (when works).
    This on Vista 64, 8GB ram, Athlon 64 X2 5000+ @ 3.23GHz.
    Reply
  • Jovec - Monday, December 15, 2008 - link

    8.12 Avivio just creates a 0 byte file when trying to transcode my Xvid (AutoGK) videos. Ah well... Reply
  • Etsp - Monday, December 15, 2008 - link

    Man, that's some high level of compression. Careful with that, it may just have made an information black-hole on your hard-drive. :) Reply
  • LtGoonRush - Monday, December 15, 2008 - link

    I noticed that the x264 example image is suffering from artifacts due to nearest-neighbor resizing, it looks like it was encoded at a substantially lower resolution, or at the very least not resampled correctly for playback. You might want to verify that the settings used were correct, as it should look substantially better than the BadaBoom results. Reply
  • Griswold - Monday, December 15, 2008 - link

    I was thinking the same. That just doesnt look right. Reply
  • gpuguy - Monday, December 15, 2008 - link

    Doom9 forum posts analyzed the quality for Baseline H.264 and decided with the same x264 settings to emulate Badaboom quality was a push. Really curious to see what they say about main profile. Reply
  • niuniu2012 - Wednesday, March 10, 2010 - link

    You can use http://www.dvdtomp3converter.com/">http://www.dvdtomp3converter.com/ to select target subtitle and audio track according at your will. DVD to MP3 Converter also provides you with fruitful options to set audio properties of audio bitrate, Sample Rate and so on. Reply
  • gwolfman - Monday, December 15, 2008 - link

    What if you transcode your video using badaboom and then mux in the original audio source, how much file size savings are we looking at? Reply
  • fitten - Monday, December 15, 2008 - link

    Elemental's Badaboom 1.0: The Redemption, I get a broken image link to the performance graph. Reply

Log in

Don't have an account? Sign up now