Tell us more about the computer you are using....the clips that make up your sequence....
Esata drives could contribute to your problem, but the Mercury Playback engines also relies on your comfputer as well.
Sorry, I should have provide that information to begin with.
Windows Version: 7 64-bit
RAM: 16 GB
Processor: Intel Core 2 Quad Q6600, 2.40 GHz
Video Card: NVIDIA GeForce GTX 470
Video files are MP4 files from BPAV folder from an Sony EX3 camera.
Using the Media Exporter with the Squeeze codecs for MP4 360p.
I am a Mac guy at the moment so I defer to my esteemed collegues from PC land. I bet the esata drive aint helping things, though.
I'm wondering the same thing.
I left all the files on the FAT32 and worked from there, saving everything back to it. So ALL files are being accessed and saves to that drive in PPro.
Thats definitely a no no. You should save your exported sequence to another drive. The poor thing is probably overwhelmed with those 2 tasks.
Yes, drive speed is a factor, as your media has to go through a pipeline and then get written to the disk. The type of connection matters. eSATA is one of the faster external drive interfaces. USB3 is even faster. You'll see a severe bottleneck with USB 1 or 2.
You can likely find a disk speed tester on the web that will tell you how many Mb/s your drive is reading and writing. And you can probably get the spex for how fast the drive should be from the manufacturer's web site.
FAT-32 isn't a good format for video, because it has a 2GB file size limit. I'd reformat it to NTFS (after you back up the files on it), which doesn't have a limit. But, I don't think that will affect the write speed. You may just have a bad cable.
lasvideo, Will do that with the next video (there's 11 in all).
Jim, I can't reformat the drive, it isn't mine.
Jay, if you charge by the hour, and won't miss a deadline, no big deal.
However, if your exported file gets over 2 GB, expect to see an error message once that happens.
I do have to respectfully disagree with my esteemed colleage, lasvideo on this one (Sorry!). I've often worked from and written to the same external drive, although in my case it was usually a FW400 or 800 drive, and the video was DV or XDCam EX. eSATA is a faster protocol than Firewire. MP4 isn't transfer intensive, as compared to say RED, ProRes or DNxHD. MP4 is more processor intensive, due to its highly compressed Long-GOP nature. Going from one highly compressed format to another is going to tax your CPU more than your drive chain.
A way to test this, and know for sure if the drive is the issue would be to remove it from the scenario, and see if your export goes faster to a different drive, especially if it's one that's known not to have bandwidth issues.
Jim, I feel more stupid than ever. I did have it send the rendered/encoded video to another drive on my PC. So it wasn't going back to the G-Drive.
It's still rendering, and the file is at 1.01 GB! The estimated file size was 7 MB!
What the heck have I done? Never run into this before.
An eSATA drive is equally fast as an internal SATA drive, but just as with internal disks, there are large differences in drive performance, for instance the latest Seagate Barracuda ST2000DM disks achieve transfer rates of 150 - 190 MB/s, but older generation disks may achieve only 80 MB/s. So the question is what disk is mounted in that G-drive, that can tell a lot about its speed.
The second thing is that currently it is formatted as FAT32. While this is certainly not as good as NTFS, you may have no choice but to leave it as it is. If that external drive is sometimes attached to a MAC it must be FAT32 formatted, because MAC does not support NTFS without going through serious hoops.
Third, the export size is dependent only on duration and bitrate. Framesize is irrelevant. Size = (number of frames) x (bitrate per frame).
Last, the Q6600 is a pretty slow CPU today. Most of the Q6600 systems in the Benchmark Results are around 10 - 20 times slower than a fast system. If your system takes around 240 minutes to encode a 48 minute timeline, imagine a 10 times faster system requires only 24 minutes. That is two times faster than real time.
I'm not surprised by your results.
Thank you, Harm, for your insightful answer. You have certainly given me a lot to think about..
What I wound up doing was rendering the timeline (the MP4 camera footage) out to a DNxHD file. That took two and a half hours. Then, putting that file in a new timeline, I rendered that out using the H.246 setting (to a MP4 files suitable for Web use) and that took about 45 minutes.
For some reason, this "old" system of mine does not like trying to render files from the timeline where camera-original files are used.
One other thing that may influence your export timings is the use of DNxHD. I may be wrong, but I think that it is handled by the QT Server, which is only 32 bit. Normal H.264 is handled natively and is thus 64 bit. This could also explain the relatively slow exports.