ATI Avivo and h.264 hardware encode

[kensystem]

I recently got one of these (the x1800 specifically). It is true that is is blazing fast on h264 encodes. And the quality seems very near (though not quite as good) as x264 (I can provide examples).

I've been doing encode tests in graphedit, with the ffdshow filter in front of it. In my tests I've gone one step further resized some old DV (ntsc 720x480) *up* to 1440x1080, and, the encoder still seems to encode it at well over 2 or 3 times real time. Stunning.

But there is one gotcha - ATI has limited the max h264 bitrate in their filter controls to 8mbps. Good for SD but not for HD. I'm focusing on trying to "change" atidvcr.dll (the encoder/filter) to raise this limit (I presume it not a limit built into their GPU).

Or -- I'd be happy just getting hold of someone at ATI where I could *buy* a better control from.. but its been impossible to get a contact at their software lab that created this thing.

Anyone know someone there (can also mail me contact offline), or is there anyone good with debuggers/modified DLLs? :)

##EDIT - throughout this thread folks have repeatedly stated 1 or 2 arguments again and again:
1) "the ATI card provides no hardware acceleration whatsoever"
2) "the quality of the encodes is bad"

To these I say:
1) "for me it does, allot. try it for yourself and ye shall know"
2) "compare the clips I encoded below, or just encode your own"

Enough said, undecided users make up their own minds.

[Devinator]

Wish I could help. I have an X1900GT and I tried out this program and was very disapointed with the visual quality. From what I understand, it doesn't even need an ATI video card to run/seems to not actually be avivo accelerated at all.

[Selur]

got an X1800 over here and as far as I can tell it isn't even using the gpu (for encoding), afaik it's speed is thanks to not so precise calculations and yeah, quality wasn't so good for me too.

Cu Selur

[foxyshadis]

At 8mbps you're halfway to lossless rate anyway (for SD), it doesn't matter what you use. Xvid gives better results than AVIVO generally, that's how bad it is, but it doesn't matter at those rates. You could probably get good results out of Indeo 3.

x264 and Ateme can be sped up to around the same speed by cutting off most of their stronger calculations, and have no such bitrate restrictions. They can also both pack 1080p into 8mbps and still look good, but probably not at top speed.

[kensystem]

Guys, I'll happily encode some samples for you to compare if you give me some short AVIs etc. I found it was very near to x264 -- if you use a good *filter* in front of it for deinterlace - I found that its not the always codec but the pre-filtering that really matters and people miss entirely in comparisons. When you use ffmpeg+x264 for example, it use a known-to-be really good deinterlacer. The ATI software provides the encoder but no good preprocessing (in my case I only need a good deinterlacer in front to of the encoder).

As for speed, I'd say its most definitely done in hardware. (For near the same quality) it encodes 720x480 @ 5 times realtime, whereas my ffmpeg+x264 runs at 1/2 real time tops.

Send me your source clips to encode, and your preferred h264 output, for a quality comparison, I think that would be interesting.

[Sharktooth]

No, it's not in hardware since there is a "cracked" avivio encoder that runs on EVERY video card...

[kensystem]

Here are some clips for you to judge:
(1 pass, 320x240 @ 500kbps)
http://onnet.cc/compare3.avi (DV source)
http://onnet.cc/compare3.mp4 (x264: ffmpeg -threads 2 -y -i compare3.avi -acodec aac -ab 64 -aq 100 -vcodec h264 -b 300 -maxrate 300 -ar 48000 -bufsize 5000 -mbd 2 -coder 1 -cmp 2 -subcmp 2 -aspect 4:3 -deinterlace -s 320x240 -g 300 -f mp4 -flags loop -trellis 2 -partitions parti4x4+parti8x8+partp4x4+partp8x8+partb8x8 compare3.mp4)
http://onnet.cc/ATI.MP4 (avivo via graphedit and ffdshow with linear interp deinterlace, and bicubic resize)

I don't have my 720x480 @ 2Mbps clips handy but will post those tonight.

[kensystem]

Here are some full SD encodes @ 2mbps:

http://onnet.cc/x264_2mbps.mp4
ffmpeg -threads 4 -y -i 9oct.avi -acodec aac -ab 64 -aq 100 -vcodec h264 -qmax 33 -ar 48000 -mbd 2 -coder 1 -cmp 2 -subcmp 2 -s 720x480 -aspect 4:3 -top 0 -
g 150 -f mp4 -flags loop -trellis 2 -partitions parti4x4+parti8x8+partp4x4+partp8x8+partb8x8 9oct2.mp4

http://onnet.cc/ati_2mbps.mpg
(only ffdshow's linear interpolater deinterlacer)

http://onnet.cc/ati_2mbps_2.mpg
(this one has a GOP of 150 like the x264 encode)

[kensystem]

No, it's not in hardware since there is a "cracked" avivio encoder that runs on EVERY video card...

I didn't say it's ONLY in hardware. I said it IS in hardware when I test. So someone cracked a version of it to bypass the hardware chain.. I dont care, that version doesn't buy me anything since I have the hardware to accelerate it.

Or did you mean to imply that this speed difference between one of the fastest 264 encoders (x264), vs what a user gets from this card, could be a factor of at least 5, and that they both are running only in the CPU??

[Jay Bee]

Which one looks better to you? :)

The ATI file looks better. But you should probably try again, using the same deinterlacers for both files. ;)

[lucassp]

well, tomshardware also confirms that there's no AVIVO Hardware Accelerated Encoding:

http://www.tomshardware.com/2007/01/09/avivo-vs-purevideo/page13.html

[kensystem]

[QUOTE=lucassp;943561]well, tomshardware also confirms that there's no AVIVO Hardware Accelerated Encoding:

Then it seems that Tom also is asserting that ATI somehow came out with a software based encode that is around 5 times faster than other software encoders... hmm, I just don't think anyone's that good a mathematician to write a software codec so much faster than the others. Or that review is base don the original/beta avivo which was known to not have hardware assist.

[nm]

http://onnet.cc/x264_2mbps.mp4
ffmpeg -threads 4 -y -i 9oct.avi -acodec aac -ab 64 -aq 100 -vcodec h264 -qmax 33 -ar 48000 -mbd 2 -coder 1 -cmp 2 -subcmp 2 -s 720x480 -aspect 4:3 -top 0 -
g 150 -f mp4 -flags loop -trellis 2 -partitions parti4x4+parti8x8+partp4x4+partp8x8+partb8x8 9oct2.mp4

You forgot to deinterlace this sample.

[kensystem]

The ATI file looks better. But you should probably try again, using the same deinterlacers for both files. ;)

I agree, although its hard to get a level playing field in the deinterlacer:

-x264 doesn't not have a directshow interface, which I'm using to achieve the ati encode, and:
-ffmpeg doesn't have (or I am not familiar enough) choices for its deinterlacer args - on the other hand I think ffmpeg's default deinterlacer is pretty much as good as you can get - it preserves detail and there are very few others I've seen that beat it. But that's a subjective stmt.

Are you saying that it seems like the ffmpeg deinterlacer is blurring the material's detail, or something artifact? Just so I can try to correspondingly level the deinterlacer (ffdshow) that I'm using for the ati (I'm not using any sharpening at all in that deinterlace file btw)

[kensystem]

You forgot to deinterlace this sample.

Cr*p, Sorry!! Embarrassing. I pull these cmd lines out of my notepad. I forgot to add the deinterlace since I normally would try to preserve that. I'll reencode with -deinterlace and upload it shortly....

[kensystem]

Deinterlacer applied to x264, sorry about the mess up:
http://onnet.cc/x264_2mbps.mp4
ffmpeg -threads 4 -y -i 9oct.avi -acodec aac -ab 64 -aq 100 -vcodec h264 -qmax 31 -ar 48000 -mbd 2 -coder 1 -cmp 2 -subcmp 2 -s 720x480 -aspect 4:3 -deinterlace -top 0 -
g 150 -f mp4 -flags loop -trellis 2 -partitions parti4x4+parti8x8+partp4x4+partp8x8+partb8x8 9oct2.mp4

http://onnet.cc/ati_2mbps.mpg
(only ffdshow's linear interpolater deinterlacer)

[nm]

I agree, although its hard to get a level playing field in the deinterlacer
You could use the ffmpeg deinterlacer in ffdshow, although I'm not sure if it is implemented in exactly the same way as in ffmpeg itself.

You can also first deinterlace the source to a losslessly encoded file, which you then feed to both x264 and Avivo encoders.

[lucassp]

Then it seems that Tom also is asserting that ATI somehow came out with a software based encode that is around 5 times faster than other software encoders... hmm, I just don't think anyone's that good a mathematician to write a software codec so much faster than the others. Or that review is base don the original/beta avivo which was known to not have hardware assist.

http://img77.imageshack.us/img77/7024/avivo4jx.th.png (http://img77.imageshack.us/my.php?image=avivo4jx.png)

that's on my 7600GS with AVIVO Xcode 1.0.0.1. I don't know for sure if this is a beta version.

[kensystem]

You could use the ffmpeg deinterlacer in ffdshow, although I'm not sure if it is implemented in exactly the same way as in ffmpeg itself.

I did that. For some reason it blurred the heck out of the source. It seems like that is not in fact the same deinterlacer as current ffmpeg builds. My guess. Only the linear interp seems on par with ffmpeg's current one.

You can also first deinterlace the source to a losslessly encoded file, which you then feed to both x264 and Avivo encoders.

I though of that, and youre right, it would be more objective for a test. But the source is already DV and re-compressing it (at least in a form where folks could download it) just adds layered artifacts. I figure I'm using a near equivalent ffdshow deint. to ffmpeg's and that should be okay... as it stands there are bigger issues, like the apparent incorrect 0->16 & 255->235 normalization, that will have more of an impact on the contrast and compressibility.

But what I'm most interested in (aside from speed and quality topics which folks can judge for themselves) is my orig point of somehow raising the bitrate ceiling they impose.

[kensystem]

http://img77.imageshack.us/img77/7024/avivo4jx.th.png (http://img77.imageshack.us/my.php?image=avivo4jx.png)

that's on my 7600GS with AVIVO Xcode 1.0.0.1. I don't know for sure if this is a beta version.

Two points:

-YES a hacked version can run on any video card. (I never said it wouldn't) Will it run as fast as it will on a x1xxx series card???...You tell me. I'm only interested in this software since/when it has hardware accel (hence the subject line), so I think 'runs on other cards' is a tad off topic.

-You're using their grandma's interface that they provide. If you try using the filter in graphedit you get more codec controls.

[lucassp]

Two points:

-YES a hacked version can run on any video card. (I never said it wouldn't) Will it run as fast as it will on a x1xxx series card???...You tell me. I'm only interested in this software since/when it has hardware accel (hence the subject line), so I think 'runs on other cards' is a tad off topic.

-You're using their grandma's interface that they provide. If you try using the filter in graphedit you get more codec controls.

I believe you own a X1k card, that's why I'm very curious if the card does accelerate or does not. btw, The Tom's Hardware test is from the 9th of January 2007 and they used the Catalyst 6.11 driver.

The sequence that I encoded was a 40sec BBC HD AVC Transport Stream 1440x1080@25fps. The encoding took (including the mod16 resize to 1440x1072) 1m13s on my A64 3000+@2400MHz, while x264 does it with 1,2fps.

:confused:

[kensystem]

The sequence that I encoded was a 40sec BBC HD AVC Transport Stream 1440x1080@25fps. The encoding took (including the mod16 resize to 1440x1072) 1m13s on my A64 3000+@2400MHz, while x264 does it with 1,2fps.

You mean you transcoded an existing AVC to another? I'm guess not sure what you're asking me test or verify.

As I mentioned in my OP, I did try up-res-ing a SD clip to 1440x1080 and encoding h264 with the ati card it still was faster than real time... blew my mind.

[lucassp]

i don't have an ATi card but the encoding, using Xcode or the ATi Filters(B-Frames 2, High Quality, 8mbps), is still way faster than x264. then where's the hardware accelerated encoding??

[Sirber]

Encoding with AVI AVIVO (HW or SW) produce lower quality than x264. That's why it's so faster ;)

[lucassp]

Encoding with AVI AVIVO (HW or SW) produce lower quality than x264. That's why it's so faster ;)

no doubt about it :D

[foxyshadis]

You're honestly comparing encoding speed between the two, while using trellis and rate-distortion? You're using slow, high quality options and comparing to a fast, medium quality encoder.

To make an accurate comparison, control for something. It's easiest to control for speed, so strip options down until it's fast enough.

Try something like,
ffmpeg -threads 4 -y -i 9oct.avi -an -aq 100 -vcodec h264 -qmax 31 -mbd bits -coder vlc -cmp sad -subcmp sad -s 720x480 -aspect 4:3 -top 0 -g 150 -f mp4 -flags loop -me x1 -trellis 0 -partitions parti4x4 9oct2.mp4
and see how fast it runs. This is why real testers try lots of different options in looking for speed/quality tradeoffs.

Also, if you think that's the best deinterlacing, you haven't seen the best that avisynth and purevideo can do, but then again if speed is your only goal that isn't important.

A good reason to compare with pre-deinterlacing is that you aren't also measuring the deinterlacer's speed, which is rather slow in both, plus you can be sure of working from the same source. You can do something like this simply by using ffmpeg:
ffmpeg -deinterlace -i orig.avi -vcodec huffyuv deint.avi
And feed deint.avi to both. (As long as you have huffyuv decoding enabled in ffdshow.) It's big, but you should have the space.

(Personally I hate ffmpeg's outdated documentation and would much rather use avisynth+x264 cli, so I'm not terribly familiar with what all ffmpeg options do, let alone what defaults are, and that makes a huge difference in speed. I can tell you that the difference between max speed and slowest settings on mine is over 10x difference - from 1.5x realtime to .15x. A moderate setting is about 4x slower than the fastest.)

Edit: Testing reveals that even the fastest ffmpeg command-line I could find is 4 times slower than the fastest x264 one, without much visual difference. Either ffmpeg is simply slower for no reason, or it's just impossible to speed up entirely. Ah, it was the resize, now it's only about half the speed of x264 cli.

[kensystem]

http://www.tomshardware.com/2007/01/09/avivo-vs-purevideo/page13.html

I just read this, and his statements about the GPU not performing any heavy lifting during video encodes just don't apply, at least to the ATI version I'm using... or perhaps he was doing WM or some other codec encodes -- I did notice these seemed to run *slower* than my h264 encode test... but that was only one, quick test on my part, since I'm only interested in h264 encodes.

There's no doubt about it, my current setup with h264 encodes are amazingly fast (almost like those little battery powered chips Sony and others are putting into their AVCHD cameras ;)

[Jay Bee]

Just looked at your new version. ATI still looks slightly better to me, less blurry.

[kensystem]

i don't have an ATi card but the encoding, using Xcode or the ATi Filters(B-Frames 2, High Quality, 8mbps), is still way faster than x264. then where's the hardware accelerated encoding??

I'd bet your CPU is pegged. Is it?

Mine isn't (it runs at 50% (A64 x2 4200) - mostly disk IO bootlenexk on the DV stream I think.

And I also suspect you're not getting the same ~5x real time that I am.

[foxyshadis]

The easy way to tell: Encode normally, lift your card out, get a hacked version of the latest release, and encode with just integrated video. (Or even easier, compare with an x1300 against a x1900, that's where it helps to be Tom's Hardware.) Then you can conclusively say whether it's using the card or not.

Technically 50% is pegged for a single-threaded app on a dual-cpu system. Disk I/O doesn't incur much cpu today, though the decoding might. Still, it does sound as if it is at least partially using the card.

[kensystem]

You're honestly comparing encoding speed between the two, while using trellis and rate-distortion?

Here is with your suggested (audio-less) encode:
http://onnet.cc/x264_2mbps_2.mp4

C:\>ffmpeg -threads 4 -y -i 9oct.avi -an -aq 100 -vcodec h264 -qmax 34 -mbd bits -coder vlc -cmp sad -subcmp sad -s 20x480 -aspect 4:3 -top 0 -g 150 -f mp4 -flags loop -me x1 -trellis 0 -partitions parti4x4+partp8x8+partb8x8 9oct2.mp4

The only thing I changed was the qmax to get the same bitrate to since it appeared to be harder to compress (with qmax=31 the file came out to 25MB). And yours is still slighty larger file size. It ran at between 1/2 and 1/3 realtime.

EDIT: oops I need to add the deinterlace to your cmd line, re-encoding it now....
EDIT2: this sample now had the deinterlace, and qmax restored to 31.

[kensystem]

Technically 50% is pegged for a single-threaded app on a dual-cpu system. Disk I/O doesn't incur much cpu today, though the decoding might. Still, it does sound as if it is at least partially using the card.

My CPU was about even across both cores (i.e both average ~50%). Which implies multi threading or just the burden of the DV decode (at 5x realtime no less) plus ddshow and the pipeline using one of the cores.

Disk light is on non near 100 duty cycle, which implies that the disk is the bottleneck. Esp since were reading a DV stream at 5x, and write buffers are prob small enough to cause frequent read-then-write repositioning.

[Yong]

...
C:\>ffmpeg -threads 4 -y -i 9oct.avi -an -aq 100 -vcodec h264 -qmax 34 -mbd bits -coder vlc -cmp sad -subcmp sad -s 20x480 -aspect 4:3 -top 0 -g 150 -f mp4 -flags loop -me x1 -trellis 0 -partitions parti4x4+partp8x8+partb8x8 9oct2.mp4


i dont think some of these options will work with x264, eg -subcmp, -mbd and -me x1, because ffmpeg will skip it silently... :p

Unlike the original x264 and mencoder, many x264 options in ffmpeg doesnt have default value,
so we have to adjust the options manually in order to get better encoding/speed result.

[squid_80]

My CPU was about even across both cores (i.e both average ~50%). Which implies multi threading or just the burden of the DV decode (at 5x realtime no less) plus ddshow and the pipeline using one of the cores.

Disk light is on non near 100 duty cycle, which implies that the disk is the bottleneck. Esp since were reading a DV stream at 5x, and write buffers are prob small enough to cause frequent read-then-write repositioning.

If the disk were the bottleneck, your cpu wouldn't be at ~50% on each core (which is multithreading, but not parallel processing, there's several threads but they're all dependant on each other hence they run serially).
Also x264 does have a directshow interface - ffdshow.

[Sharktooth]

There are other review of the ATI encoder and all shown no preformance gain when switching to more powerfull video card models.
The only gain you can get is on the DECODING/DEINTERLACING/FILTERING stage, expecially if you re-encode a h.264 video. The ENCODING stage is not hardware assisted at all.

[kensystem]

If the disk were the bottleneck, your cpu wouldn't be at ~50% on each core (which is multithreading, but not parallel processing, there's several threads but they're all dependant on each other hence they run serially).

I think that depends on the app (how/if it slices tasks among threads and what core they're running in). In any case I get roughly 50% on each core (neither is saturated), and, I get lots of disk light :)


Also x264 does have a directshow interface - ffdshow.

I'm using ffdshow (ffdshow_rev760_20070110) -- to do the deinterlace in fact. But I dont have x264 as a codec option (I believe this is a famous discussion elsewhere on doom9). So is x264 in another build somwhere, or just a recent (re)addition?

[kensystem]

There are other review of the ATI encoder and all shown no preformance gain when switching to more powerfull video card models.
The only gain you can get is on the DECODING/DEINTERLACING/FILTERING stage, expecially if you re-encode a h.264 video. The ENCODING stage is not hardware assisted at all.

Then this software-based encoder has some real afterbuner balls :) And it does it without saturating the CPU to boot.

That, or maybe those other reviews are outdated, not doing the same tests I am (AVC encoding), or they're just deeply biased (and can squirm all day AFAIC) :D

I'll just say to the undecided readers... if you'd rather have fast AVC encodes (say to archive *hundereds* of DV tapes to DVD-5 like I am), go out and buy one of these and if it doesn't accelerate encodes or meet your quality expectations (you HAVE to use filter gaphs to access the codec controls, not their 'Encode' app)...... take it back! Simple.

[nm]

I encoded a few more samples from kensystem's source to see how Avivo compares to MPEG-4 ASP. Seems that it really doesn't do too well although it is fast for an AVC implementation.

Here's a sample encoded with the libavcodec MPEG-4 encoder and the linear interpolating deinterlacing filter (-vf pp=li in MEncoder): http://files-upload.com/files/93146/lavc_30fps_li.avi.html
The encoding command line was:
mencoder -aspect 4/3 -noskip -vf pp=li -ovc lavc -lavcopts vcodec=mpeg4:mbd=0:vqscale=10:autoaspect:psnr -nosound input.avi -o output.avi
These are pretty much the lowest settings one would use with libavcodec and yet I prefer this encode to the Avivo sample (much sharper without playback postprocessing, better overall quality with postprocessing enabled). The bitrate is 10% higher though since I aimed at kensystem's x264 sample bitrate and just now noticed that the Avivo sample had lower average bitrate. My ASP sample encoded at 50 fps on a 3 GHz Pentium 4, but with a dual core CPU and multithreaded XviD, you'd get speeds of at least 4 times realtime.

I also tried libavcodec's MPEG-2 encoder with the same minimal settings and the result was only slightly worse than the Avivo sample. So, instead of using Avivo for archival purposes, I think one would be much better off with a good MPEG-2 codec. Then the files could be authored directly to DVDs if necessary at some point.

As to Avivo vs x264 on this source, I got similar overall quality with ~25% lower bitrate by using high-quality x264 settings. Here's a sample: http://files-upload.com/files/93168/x264_30fps_li.mp4.html
The encoding speed will be much lower; I got 7 fps with the Pentium 4. The command line I used was:
mencoder -aspect 4/3 -noskip -vf pp=li -ovc x264 -x264encopts crf=28:frameref=3:bframes=6:b_adapt:b_pyramid:weight_b:bime:brdo:trellis=1:subq=6:8x8dct:nofast_pskip:mixed_refs:direct_pred=auto:psnr:ssim -of rawvideo -nosound input.avi -o output.264

Last but not least, a 60 fps sample encoded with x264 and yadif+mcdeint deinterlacing. This encoded at 3 fps (3 interlaced source frames per second) on the Pentium 4:
http://files-upload.com/files/93178/x264_60fps_mcdeint.mp4.html
Command-line:
mencoder -aspect 4/3 -fps 30000/1001 -ofps 60000/1001 -noskip -vf yadif=3:1,mcdeint=0:1:10 -ovc x264 -x264encopts crf=28:threads=1:frameref=4:bframes=4:b_adapt:b_pyramid:weight_b:trellis=1:subq=6:8x8dct:direct_pred=auto:psnr:ssim -of rawvideo -nosound input.avi -o output.264
A good deinterlacing filter can be so heavy that the encoder performance is no longer that important (here I used the fastest settings for mcdeint). Avivo could be much more interesting choice if it used the hardware for good full-framerate deinterlacing and other preprocessing while also having the option for using 3rd-party encoders.

[giandrea]

I am pretty confident that you should use "framestep=2" to halve the number of frames of your encode after "yadif,mcdeint". You can read it in the comments at the bottom of this page (http://guru.multimedia.cx/deinterlacing-filters/) (from the author of yadif and mcdeint).

It is pointless to make a 60 fps video from a 30 fps interlaced one... then you better have a 60 fps video with half the vertical resolution using "tfields" to separate the fields, and then correct the aspect ratio... really... :D

[nm]

No, I didn't want to halve the framerate, but use the full 60 fps as I said. It makes sense if you wan't to use a better deinterlacing method than what you could use in realtime when decoding interlaced content. Personally I prefer the fluidity of 60 or 50 fps and currently the interlaced encoding in x264 is IMO not much more efficient than deinterlacing to the full 60 fps and encoding that.

[Theliel]

Well, I'm doing some newer test with AVIVO. In my case i'd tryed a x1900 and x1600.

I sorry, but is true. Avivo dont have any hard support for encoding in this time. Yes, all serie x1000 have hadr support for decoding, but not for encoding. tomshardware are right, its posible monitoring temp and video memory. AVIVO converter are only a soft encoder.

In theory is posible and "easy" make a encoder (or convert x264 code for example) that it can use hard support through DX9 or OGL2. In time, some forum user make a preliminary version with CG.

Anyway, and On-topic again, Avivo currently are only soft encoder :). The latest Avivo cenverter version( that I'd "tweaked") run equal in performance with my 7600GT. Yes, is faster than other codec, but it have the worse IQ too.

No all is bad, sometimes is prefer have a fast encoder than the best IQ possible.

No hard support :)

[lucassp]

only akupenguin (and other developers) can tell us how hard it is to write a video encoder for ATi/nVidia/Cell.

[kensystem]

I sorry, but is true. Avivo dont have any hard support for encoding in this time.

That flies in the face of the fact that, on my machine at least... the two cpu cores average around 50%, YET the encode churns out well faster than realtime. Even though the quaility isn't specatular, that level of CPU usage simply CANNOT happen at faster than realtime (it it could then surely x264 could be that as fast with 50% CPU).

Hmm, maybe what i'll do is post a video of my machine to PROVE that the CPU is low and the speed is fast... :)

If you tell us what version of softwares (windows, directx, ati software) that you are using, that might gives clues as to why you can't get (the frame rate) up.

BTW I looked at the xvid encodes the other poster recently did. Those are VERY impressive, they seem to be very near or equal to x264 in quality. I'd not believed others who'd stated in other threads that mpeg4 could compete with part 10 for quality, but now I have to think a little harder about that. At the same time h264 still deserves time to be optimized like mpeg2 and mpeg4 have had.

The good thing about this clip is that it stresses the codec more than most, the xvid encode holds up really well.

[kensystem]

hey Theliel, what CPU (32 / 62 and Intel / AMD) and chipset do you have? I dont know if this is the issue, but it would be VERY intesreting if the hardware encode was designed to only work on in conjunction with AMD chips (if only for vendor handcapping of Intels), or x64. Mine is a AMD Ax2 64 chips.....

[foxyshadis]

ken, just btw, I could get 120fps on my 2.1GHz core 2 duo with your sample at 320x240, and 45 fps at 720x480, by calling x264 directly with the commandline I posted below. (Deinterlacing done beforehand.) Quality is surprisingly decent, somewhere around xvid-quality, but not comparable to higher settings. I didn't post because I thought the thread was dead. With deinterlacing, the fps is all over the map depending on the method I choose. I haven't tested the speed with AVIVO yet - something I'd really like to have is AVIVO deinterlacing + x264 encoding, but I haven't quite coerced ffdshow into giving me that yet.

Why is it so hard to believe that they can write a fast cpu-based encoder? I mean, xvid is quite fast on moderate settings, and AVIVO was shown to have lower quality (probably less complex) than moderate-high xvid encodings.

x264 --bitrate 1000 --bframes 3 --weightb --analyse p8x8,b8x8,i4x4,p4x4 --vbv-maxrate 25000 --threads auto --thread-input --progress --no-psnr --no-ssim --output "test.mp4" "preview3.avs"

[kensystem]

Its not hard to believe that a fast software encoder can be made, I just havent seen one as fast. I'm sure that your x264 encode pegged your CPU, am I right?

And, 45 frames a second isnt as fast as 60-90, even though your CPU is on par with mine, and I *was* deinterlacing (via ffdshow btw).

The very fastest I could ever get x264 was, I'll just say, under 30 fps, and it wasnt looking any better than the avivo encode IMO. The HQ-est settings I tried gave better results than the avivo but as well under 10 fps, and anything faster becomes marginally better.

Seems like there's people either defending x264, or at least just making blanket statements that avivo cannot *possibly* be hardware encoding). I'd argue that stance isn't needed (unless you hate ATI or AMD or some kidstuff).. x264 is a 9 or 10 for an h264 encoder (only missing PAFF interlace I think). Like someone said, the OS guys could eventually hack the avivo API to use their hardware DCT, ME, etc. x264 would be even more bitchen if it had hardware encoding.. knocking ATI will *never* help that happen.

May favorite h264 encoder is my HDR-SR1, its realtime, and at 15Mpbs at least, looks sweet.

[Theliel]

hey Theliel, what CPU (32 / 62 and Intel / AMD) and chipset do you have? I dont know if this is the issue, but it would be VERY intesreting if the hardware encode was designed to only work on in conjunction with AMD chips (if only for vendor handcapping of Intels), or x64. Mine is a AMD Ax2 64 chips.....

Of course my friend. I tested in 3 different machines:

Friend's PC:

AMD 64 X2
Chip VIA (I dont know exact model, sorry)
ATI X1600
Catalyst 7.1
DX9C December 2006
XP pro

My brother:

Intel P4 660 With HT Enable
Intel 925XE
ATI X1900
Catalyst 7.1
DX9C
XP pro

My PC:

Intel Core 2 Duo E6600
Nforce 590
ATI X1900, X1600, Nvidia 7600GT, Nvidia 8800GTX
Catalyst 7.1, ForceWare 97.92
DX9C February 2007/DX10
XP x64 and Vista


The only 50% CPU use I believe that its no real becouse I'd had the same problems with other programs, in this case, only with AMD X2 and Intel P4 with HT. In this cases, (with megui for example) each core only take me about 50%. I Dont know why.


About fast Vs IQ... I say the same one more time. Yes, Avivo is faster than other codec, but IQ are poor.

only akupenguin (and other developers) can tell us how hard it is to write a video encoder for ATi/nVidia/Cell.]

Of course.


well, I dont know other ppl said, but my own test tell me that Avivo are only soft encoder.
I invite you to make your own test, you can view perfectly that is true. No videoMemory is used, No GPU temp is changed, No extra performance with any other ATI card, no nothing. please, try and see :)

[kensystem]

The only 50% CPU use I believe that its no real becouse I'd had the same problems with other programs, in this case, only with AMD X2 and Intel P4 with HT. In this cases, (with megui for example) each core only take me about 50%. I Dont know why.

On a high bitrate (i.e low compression like hufyuv) input where the disk is bottleneck, I can see this being the case. But DV streams which I'm using as sources are not, and I have never, EVER seen another codec use less than 90-100 CPU during file-transcodes from DV, unless you intentionally turn down the process priority or have other IO bottleneck.

When the CPU is running at sub-90% it can ONLY be because it is waiting on something else (say disk or the avivo number-cruncher), or because the software has built-in, or kernel-imposed, sleep()/wait or yield() interrupts -- or because of poor IO (uncompressed input for exmaple).

But when its running at 50% AND the encode runs at 3x realtime AND the quality isn't horrible... then I think you probably must be to attributing that to some mathematical genius software-only codec writers that ATI has.. or do you think the samples I put up make the ATI look abysmal and that wholly explains the 3x-realtime/50%-cpu on a 720x480 clip???

It's one or the other I think. :D

[kensystem]

BTW Theliel, to answer to your hardware configs, clearly if you don't see any acceleration on any of those boxes then it seems not to be a vendor discrimination issue based on chipset.

I can say, that I'm running 2 different HP machines, I don't know the chipset except that the CPUs are AMD 3800 64 x2 and the other a 4200, and XP with latest directx and ATI Catalyst version 7.1...

[nm]

When the CPU is running at sub-90% it can ONLY be because it is waiting on something else (say disk or the avivo number-cruncher), or because the software has built-in, or kernel-imposed, sleep()/wait or yield() interrupts -- or because of poor IO (uncompressed input for exmaple).
Or because of thread synchronization issues like squid_80 explained. If you see the same 50% usage on both the 3800+ and the faster 4200+ dual core CPUs with the same GPUs, then that is clearly the case. The encoder is essentially running like a single-threaded program although it has threads running on both cores.

It would be interesting to see how fast the MEncoder/libavcodec MPEG-4 ASP command line that I used in my sample would run on your machine. It should also use 50% of your CPU (by maxing out one of the cores) since the libavcodec MPEG-4 encoder is not multithreaded unless you specify the threads=x option.