ATI GPU transcoding app?

Those are business-related right? Yes I've seen nVidia hasn't turned in very good numbers recently, and Intel hasn't exactly done well last quarter.
But I'm not a business man, I'm a technology man. I don't have a lot to say about business, it's not my area of interest, nor my area of expertise. Look at my post history. In all these years I've rarely engaged in such topics, regardless of the manufacturer at hand.
This however is right up my alley, as I've worked on MPG/JPG encoding/decoding in the past.

 

There's two parts to transcoding - currently AVIVO Transcode focuses on the encode part of the process by offloading one of the intensive and parallelisable parts of the process, being motion estimation.

The other part of the process that needs to happen is, of course, the decode process. Decoding on UVD is currently not done as part of the core library that AVIVO Transcode uses, hence the CPU utilization. There are future updates to include UVD decode.

Comments earlier in thread concerning support for G80 based cards on some transcode app's highlight where the main differences in CPU utilization come from.

 

From the thread that was referenced by Arnold Beckenbauer :

http://forum.doom9.org/showthread.php?t=144168

NVidia's (not Badaboom it seems) and Cyberlink's resulting encodes are there to download in post 9 - if you can play these m2ts files, then prepare to hold on to your sides

Jawed

 

Er, only if you count the impact of failing miserably throughout 2008 to execute on implementing 55nm GPUs.

With posts like this:

Apparently you didn't know that NVidia would continue to remain out of touch on pricing. But anyway, that's another thread.

Hence I was wondering why you were keeping so quiet on the Badaboom "analysis"...

Jawed

 

So why is AVIVO Transcode fastest when NVidia hardware is installed with no ATI GPU present? Are you suggesting that NVidia hardware's superior decoding is allowing AVIVO Transcode to perform more quickly?

Jawed

 

I don't care for this discussion at all.
I'll criticize nVidia when I feel the need, and I'll compliment AMD/ATi when I feel the need.
I don't think anyone can currently deny that while neither Badaboom nor Avivo are perfect, Avivo has far more things to criticize at this moment.
Badaboom only has two 'problems':
1) The conversion options are rather limited.
2) The quality isn't quite as good as with the better software encoders.
That doesn't stop it from being a useful tool, does it?

Oh yes, and the 55 nm thing is business as far as I'm concerned. nVidia tried to remain competitive with pricing towards consumers. I think it's pretty obvious that it would have been better for everyone if they went to 55 nm sooner. But that's about all you can say about that, because it is indeed THAT obvious. I'll tell you something else that's obvious: the sooner nVidia goes 40 nm, the better (Ironically enough it's how AMD has always done business in the CPU market... always a process behind, trying to keep down prices, and as a result rarely turning in good business profits... but we've never heard people complain about that).

 

Having seen a variety of results, it appear quality isn't a parameter of these encoders. It seems speed and a vague resemblance to one's memory of the video is all that's desired by the vendors of these encoders.

Jawed

 

Well I feel bad in that I chose a test that had little chance of showing how Badaboom can be useful. Going from an already compressed, by way of h264, video to an an even more compressed sample is not what the program is about.

If in my comparison I'd used hand-held resolutions then it would have shown something of what it could do. Even then, the source material would remain a tough job.

I'd post a sample of what it can do for the average person, say a TV capture reduced to hand-held size, but I feel constrained by the legalities. The review sites don't seem bound by that, lol, but I think here we are.

I do have a movie* that is very old (1939) and its copyright restrictions expired.

It's called His Girl Friday (Cary Grant, Rosalind Russell). It's in black and white and the movie is 3.06 GB in size (mpeg2).

Let me run that through Badaboom.

http://www.archive.org/details/moviesandfilms

http://www.archive.org/details/his_girl_friday

On second thought, I'll use this. http://www.archive.org/details/dick_van_dyke_show_34_bank_book_6565696

If someone official can tell me it's ok to post the results, I will.

 

Perhaps, but there seems to be a clear difference in quality between Badaboom and Avivo.
Avivo loses more details at the same bitrate, and actually has errors in the resulting videos in some cases. At least, that's what I gathered from reviews such as the one on Anandtech. Add to that the above mentioned findings on CPU and GPU scaling, and how it apparently manages to run even on GeForce systems with no support for Steam at all, while actually performing better... and something really smells.
At least with Badaboom there's no doubt that it actually does use Cuda for at least a considerable part of the encoding... and it actually gets acceptable results from it. Not as good as software perhaps, but still quite useful.

 

Yep, Avivo Transcode appears to have spent ~3 years as prototype software and gone nowhere fast.

Jawed

 

So then you agree with me that Avivo deserves more criticism than Badaboom at this point.

I'd also like to comment on this: "No, you think they're premature, but you have no way of knowing what I know."

This was in response to someone saying I made premature assumptions/conclusions.
I was just pointing out that he cannot judge whether I actually know these details or not, therefore he cannot judge whether my assumptions or conclusions are premature.
They were in fact not, because I based them on facts that I already knew, yet he seemed to assume that I didn't.

 

Yeah, particularly as they've been working on it for years. CUDA wasn't even around when they started.

Jawed

 

Then why did you make that comment about where I was earlier in this thread?

 

Actually it is, as "transcoding" is the normal mode for a lot of people.

At hand-held resolutions (640x480? 320x240?) a CPU is going to be very nippy too. Particularly when using a quick'n'dirty profile.

If you want to make any comparisons with RipBot, then use a quick'n'dirty profile.

I looked at:

http://forum.doom9.org/showthread.php?t=127611

where it says

If you have installed codec packs like K-Lite , CCCP , Vista Codec Packs or similar UNINSTALL THEM IMEDIATELLY!

That's me, so I won't be un-installing stuff to run RipBot.

As a matter of interest I created a quick'n'dirty profile here that runs at 18.69fps - 2m10s encode, 23290KB. It looks worse, in places than Badaboom, but better in others...

Code:

--crf 27 --no-cabac --subme 1 --partitions i8x8 --8x8dct --qpmin 17 --vbv-maxrate 29400 --me dia --merange 4  --aq-mode 0 

That's on my A64 3800X2 at 2GHz. What's your CPU and GPU?

Jawed

 

I was curious why you'd made no comment on the "quality analysis" of Badaboom.

Jawed

 

I didn't have anything to add.

 

I don't know about assessing the user base's encoding tastes. I'd guess mpeg2 is what they would be starting with much of the time. That's DVD and US TV broadcasts.

I have a 8800 GT and an Intel Quad Core. Q6600, 2.4, 8MB, Core Duo Kentsfield, G0. It's a Dell system.

If it was me, I'd probably encode to two profiles. One for handhelds and one for PC storage. For PC storage I'd go for 1280 x 720p at around 1/3 to 1/4 the file size of the high-def TV capture. For a handheld I'd go to its native display and with a generous bitrate. But I'm not that big on storing stuff, once I've seen a TV show I usually don't care about reviewing it. SF shows the exception.

CPU's and GPU's will get more powerful and software to use them for encoding will evolve. A few years down the road all of this is going to just be a point and click affair for all but the most demanding users. Even now there are applications that are like that. It's just that they require patience for the bigger projects.

I like what Badaboom is about. I don't mind supporting it and I keep it around, in part, to get a hands on feel for the possibilities of GPU encoding. It's hard to say where it is going but I get the sense it has support from nVidia and that it is going to get some decent improvements over its product life.

What we all want, of course, is for GPU encoding to soon evolve to the point where any application can exploit it to the same level, that the cpu is, for encoding. I don't know if the current hardware has that potential but I look forward to finding out. Exciting times we live in.

 

Yes and No. Avivo is free, while Badaboom costs money.

 

MPEG2 is also a compressed format. With poor quality per bit, too.

Ouch, the RipBot profile you used achieved about 8.69fps overall. My CPU ran at 6.18fps. Seems like it was an overkill profile as your CPU is around 3x the performance of mine... And if you take my quick'n'dirty profile, it should run around 55fps.

Why a generous bitrate? Is that to compensate for the poor quality of Badaboom?

Well it seems your RipBot encode fell foul of an unnecessarily complex profile which is slow - though as I never do 2-pass encodes I don't know how much slower it is to do 2-passes for a given file size instead of 1-pass. Obviously the "difficulty" of using RipBot is an issue here, let alone the myriad options that x264 offers.

What I see is a disregard for quality in order to be able to advertise products as "10x faster" or "2x real-time 1080p encoding" etc. The "convenience" of the user interface appears to be where most of the value lies.

If it was half the speed, or one quarter the speed (with some kind of uplift in quality) because it was capable of more than cursory use of the IQ-enhancing features of h.264 these things would get some respect.

Jawed

 

Well both are worth the asking price so it's a wash isn't it?