Skip navigation
Currently Being Moderated

Can Drive Type Affect Render and Encoding Speed?

Apr 9, 2012 2:18 PM

The title pretty much says it all.

 

A client gave me a G-Drive (FAT32) with the video files on it. I'm using a PC (NTFS) with the G-Drive connected via eSTAT.

 

It seems to be taking a very long time (nearly four hours) to encode a 48-minute video that has no color corrections, no FX, no nuthun. I'm encoding to MP4 360p.

 

Is this normal? Is the G-Drive part of the slowdown?

 
Replies
  • Currently Being Moderated
    Apr 9, 2012 2:20 PM   in reply to Jay Gladwell

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 9, 2012 2:38 PM   in reply to Jay Gladwell

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 9, 2012 2:46 PM   in reply to Jay Gladwell

    Thats definitely a no no. You should save your exported sequence to another drive. The poor thing is probably overwhelmed with those 2 tasks.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 9, 2012 2:47 PM   in reply to Jay Gladwell

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 9, 2012 3:47 PM   in reply to Jay Gladwell

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 10, 2012 12:22 AM   in reply to Jay Gladwell

    Jay,

     

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 10, 2012 3:39 AM   in reply to Jay Gladwell

    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.

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points