I want to create a video from a collection of sequences I took with a light portable camera in 1080p. Because the sequences are quite shaky I used VirtualDub/Deshaker to process the video files and stabilize them. The output from VirtualDub was saved in uncompressed AVI (around 10GB per minute). I thought that it would be better to continue in raw in the video editing software and then to re-compress only once the end result is ready to export.

The problem is that video editing software tools seem to have a lot of trouble playing back my uncompressed video sequences. I tried Movie Maker without success and then thought a more pro tool such as Lightworks would be better. However both tools struggle playing back the video. The PC I use is a high end i7 desktop with 16GB ram but it looks like the bottleneck here is the hard drive.

Is there a better way of keeping the quality of the video between VirtualDub and the editing software, perhaps a lossless video codec ? Or is there something I'm doing wrong here ?


  • In addition to my question I forgot to mention that VLC also had issue playing back the uncompressed video. And I often read that pro video editing should always be done in RAW and compressed only at the end for distribution. Therefore I'm wondering what I don't get here ?
    – jmbouffard
    Sep 13, 2015 at 23:01

3 Answers 3


The limitation is certainly the disk I/O, which at 10GB/min is outside the capabilities of all but very high-end disk subsystems.

It's generally true that you should work at the highest bit rate and bit depth your system is capable of so you have the headroom for processing, but your system simply isn't capable of working at the rates your asking of it.

Determine what you need as the end result and pick a reasonable level above that for editorial. Uncompressed 1080p is way overkill if your target is YouTube, for example. Usually, choose an all I-frame (no interframe compression) format and a bit rate that will allow your system to handle two or three streams at once. If your disks can handle 60MBytes/s random access, it can play 3 80Mbit/s sources for compositing, and so on. That's more than needed for all but the most demanding targets.

  • Thanks for your answer. When you say all I-frame compression do you have a specific codec in mind? And would that be supported by VirtualDub? Probably not out-of-the-box since it does not offer many options but with a plugin perhaps?
    – jmbouffard
    Sep 13, 2015 at 23:48
  • 1
    One common mid-range intraframe codec is MJPEG. It's pretty much what it sounds like: every frame is compressed individually using JPEG compression, using some chosen quality value. At the higher end you have ProRes, which may not be available for free and may not work with VirtualDub.
    – Jim Mack
    Sep 14, 2015 at 0:41
  • Or don't delete the AVIs yet. Download ffmpeg and convert them to H264 baseline profile at a high bitrate (say 30 Mbps or CRF 10-12). Cellphone videos are 15-20 Mbps to begin with. Common DSLR/GoPros record at 30-80 Mbps. So, encoding at 60 Mbps or higher for such sources won't provide any tangible benefit.
    – Gyan
    Sep 14, 2015 at 5:09
  • I tried using the x264fvw encoder (sourceforge.net/projects/x264vfw) with VirtualDub in order to compress my output with the highest possible quality as described in the answer/comments above (I-frame only, baseline, high bitrates), however it does not work and the process stops with errors every time. Then I tried Handbrake to encode my raw output to high quality H264. This works ok but the main drawback is that it is now a 2 steps process.
    – jmbouffard
    Sep 14, 2015 at 12:22
  • @Mulvya As mentioned in my previous comment I used Handbrake to encode to H264. In the video quality options there is a slider that can be moved to lossless (RF 0). Is that solution equivalent to the ffmpeg conversion tool that you proposed?
    – jmbouffard
    Sep 14, 2015 at 12:27

If you have a high-end i7 PC desktop, you probably have the infrastructure to set up a high-performance RAID that can handle your I/O bandwidth requirements. 10GB/min = 167MB/sec, which a really good 3.5" disk can almost deliver. If you stripe 2 such disks together, it's an easy target to hit (as long as there's no other I/O contention). So, have your system disk handle your OS and application house-keeping, a 2-disk RAID as the source for your uncompressed video clips, and the additional disks (or RAIDs) for other video sources and/or rendering destinations. High-performance spinning disks have never been cheaper...

Alternatively, there are good intermediate codecs that compress lightly enough to be good for video editing. Apple ProRes 422 has become a kind of standard (at 1080p24, 422 Proxy = 36Mbps, 422 LT = 82Mbps, 422 = 117Mbps, 422 HQ = 176 Mbps). ProRes 422 HQ is about 1/8th the bandwidth of your uncompressed source. ProRes 4444 is 264Mbps, which is still about 1/5th the bandwidth of your uncompressed source. ProRes 4444 (and even ProRes 422 HQ) are industry standards for source-level editing.

  • Thanks for your answer but it brings new questions. What tools can be used to compress video using these codecs? Anything compatible with VirtualDub? Moreover, I also have concerns about the support for those codecs in video editing software tools. Would Movie Maker support such format or I would need a more professional tool?
    – jmbouffard
    Sep 14, 2015 at 12:12
  • You should be able to use ffmpeg to convert to ProRes: transcoding.wordpress.com/2012/01/29/prores-ffmpeg Sep 14, 2015 at 13:56

you can select the clips, right click and select make proxies under media. this will render low quality versions of your clips to work with. It will take a while with those large files, but after that you can work fast. your playback will be of lower quality, but the export will use the original files (so this will also take quite long).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.