It may not reduce your encoding time at all, having to make two separate files, but Windows Media Encoder is a free Microsoft product that will convert pretty much any video file to wmv. You might get better results by exporting them to whatever is the "best settings to match the timeline" (getting fast exports) and then using WME to convert them to the settings you need. Just do a google search for Windows Media Encoder.
Also, I don't believe upgrading your card would help you with your encoding in any way, especially if you're not using any gpu effects or transitions.
ok forgive me if I sound a bit dense here but is AME not using the Windows Media Encoder already to produce the output files? If so, then surely adding another step is only going to slow the process down rather than speeding it up.
If it's not using the wmvencod.dll then what is AME using (or how do I figure out what it is using) since without those dlls present on the machine I don't even get wmv as an output option.
Thanks for confirming my suspicions on the graphics card. So the CUDA processing would not provide any real benefit for pure conform?
I should add that I am not averse to hardware changes that will improve the encoding speed, so a graphics card upgrade is not out of the question IF it will provide the improvements that I am after but so far the hardware changes I have experimented with have produced negligible gains.
I couldn't tell you whether or not it uses the same dlls as the Microsoft program... that's getting deeper under the hood than I usually go! :-) If it is, then you're correct in that going to an intermediate and using WME isn't going to speed up your process.
For more info on hardware, go to www.ppbm5.com and look at the test results page... see what folks were using who got the higher results. IIRC, your specific processor (even in its dual form) is a rather poor performer with this kind of stuff, and the Core i7 line is much better.
Out of my own curiosity, I'm running a test on my system to see if I can reproduce the similarly long encode times with WMV versus h.264. I've got a 4:23 AVCHD clip which I'm rendering first using h.264 MainConcept to PAL DV Widescreen HQ (the only reason I'm using PAL here isbecause that's what you're using, and I wondered if it would go differently than NTSC... I've never used PAL before). The full encoding time for that in h.264 was about 1:45, so a little better than double real time. The same clip, rendered with WMV using PAL Widescreen source to HQ Download is taking about 3:15, so pretty much double the h.264 clip's time, but still better than realtime, and nowhere near the results you're getting.
I don't remember what you said your HD setup was like, but make sure you've got multiple hard drives, preferably a RAID for your data disk. I learned that having a good disk configuration can really make a lot of difference, all other things being equal!
@ the OP
I dont think that you said how long your encode times to wmv actually were?
About 16 minutes, I believe... he stated that his clips were about 4 minutes, and it was taking about 4x real-time...
That is correct, I am seeing roughly 4 times real time. In fact, 4 times slower than real time is the fastest encoding time I get when encoding to wmv.
The reason I believe that AME is using the wmencod.dll (and associated dlls) is that prior to these being present on the system wmv was not available as an output format in AME. The dlls were installed on the system by installing Media Player (as in Windows Media Player).
As far as hdd setup is concerned the box has two 15000rpm 72Gb drives using Raid 1. I appreciate that using fast disks with Raid 0 might improve encoding times (regardless of codec), although at present in my work flow the project files, hires media and output files are all using network storage.
Yesterday I tried a side by side comparison of QT wrapped H264 and wmv, using as close as possible to the same bitrate and other settings on a 1 minute HD file. The h264 took just over 3 minutes to encode, the wmv just over 4 minutes. In this test I used local storage to write the output files.
Clearly the h264 was faster and if the results extrapolate out to a 4 minute file I would be saving about 4minutes per encode.
Message was edited by: tim_campbell