VGA card and encoding speed

[Mole]

I read the Athlon64 review at AnandTech:

With our recent move to ATI Radeon 9800 PRO video cards, Intel has taken a substantial lead in encoding performance. This was an area recently dominated by AMD when we were using the nVidia Ti4600 as our standard video card.

To my understanding, are they saying that the VGA card actually makes a difference in encoding performance??

The only thing I can think of the VGA card making any difference at all is maybe if you have preview on. But seriously, anybody half serious about encoding turns off the preview.

Am I misunderstanding that quote or are the folks at AnandTech clueless?

[UGAthecat]

They used x-mpeg, which many people would argue is enough to say that they don't know what they are doing. Last I used x-mpeg was ages ago, so I don't know if there is a preview option or not, and if it is possible to turn the preview off.

I can only think of one thing (video card related) other than preview being turned on that would cause any performance problem, and it is a real long shot to even be possible, much less probable so I won't even bother mentioning it. My bet would be that it is related to how crappy x-mpeg is.
It would be nice if somone that has both an ATI card and an Nvidia card could compare encoding performance difference with each card when using other utilities like virtualdub, but that is a lot of work to go through for very little useful information.

[Mole]

Well, I have a box which I use to do my encodings and it's not even connected to a monitor. I use Remote Desktop Connection in Windows XP to connect to it through LAN, then manage everything from my main computer. The VGA card isn't even enabled when you use remote connection.

I never used xmpeg either. I used flask few years back the first couple of weeks when I just started doing encodes, but quickly moved on when I discovered avisynth.

[Doom9]

I entirely agree with the assessment that a GFX Card should have zero influence on encoding speed. Maybe in the 0.0x% range but that can be discarded as measurement inaccuracies. Unfortunately, I don't have an ATI card to verify this for myself (my primary card is a GF4TI4600 which is close enough to what Anandtech was using). Also, I recall older Anandtech tests where Intel still dominated DivX encoding, despite using an NVIDIA card.
As for Xmpeg, I spoke to a guy running a hardware site once, and he told me that the DivX benchmarking is actually done according to intel's benchmark guidelines. So the completely useless measurement method uses (write down the fps at the last frame) grew in intel's backyard. I'll look up the link to intel's benchmarking guidelines so you can see for yourself.

[Mole]

I'm not sure if this has been suggested before, but perhaps we could make our own benchmark guidelines?

All necessary programs could be made into a download pack.

We could also find a sample .VOB file so the benchmark can be repeatable. We could measure how long time it takes to transcode the .VOB file (with no audio) to XviD for instance.

We could even make a few different AVS scripts with different plugins in action.

I think the numbers should be of interest to many people. Especially people who wonder if their slow encoding speeds are normal or not can have a look at what others are getting.

Most importantly, we could try to suggest this benchmark pack to various hardware sites, so they can do some media encoding benchmarks the real way.
Frankly, current DivX encoding benchmarks available at most sites are quite useless and results between different sites often contradict eachother.

In fact, Doom9, have you ever thought of maybe contact hardware manufacturers and let them send you hardware to do benchmarks?
I think this site is reputable enough and MPEG4 encoding is of interest to more and more people.

I'm sure Asus would milk for what it's worth if benchmarks shows that their motherboards can give faster encoding speeds than competitors boards, for example.

I know of many small hardware sites with a lot less visitors than this site who get sent hardware to review with no problems. Manufacturers are keen to get their latest gears tested and often you get to keep it afterwards too.

[UGAthecat]

The biggest problem with doing benchmarks like this is that it is very time, space, and money consuming.
It usually takes time just due to having to set everything up for the benchmark run.
It is space consuming because if you want to do comparisons of a reasonable array of equipment, you usually end up with 5, 10, or more different PCs running at any given time.
It is also somewhat costly sometimes, because while some hardware vendors will GIVE hardware to a review site, others will only loan the hardware out, making you pay shipping 2 ways just to review something. Of course there are ways around the costs, like using a vendor for a HW mfg instead of the mfg themselves, and offer the vendor free/cheap ad space in exchange for the hardware samples.
I would love to do reviews of various codecs & settings on various hardware just to give people estimations of performance to expect, I just think that by the time i got done with one run of benchmarks I would have to start a whole new set of benchmarks because of how quickly the encoding scene moves sometimes.

Maybe the best way to do this would be to do this would be to start like Mole suggested by coming up with a standard way to test, then just let everyone do their own tests and submit the results to a database accessable through a web server.

[ppera2]

Originally posted by UGAthecat

Maybe the best way to do this would be to do this would be to start like Mole suggested by coming up with a standard way to test, then just let everyone do their own tests and submit the results to a database accessable through a web server.

I absolutely agree.
Now it's on Doom9 to make required steps :D

[Doom9]

I have started just that for divx hardware players: http://forum.doom9.org/showthread.php?s=&threadid=62239. If it turns into something successful, we can start looking into different categories.