VirtualDub is really awesome. I have used it extensively for video capture and transcoding. It's also the best tool I've found for repairing AVIs, and, by extension, for previewing partially downloaded AVIs.
Unfortunately, it's a little slow at re-indexing AVIs with gaps in them. During re-indexing, it performs many seeks and reads and it often reads an order of magnitude more data than the size of the file being re-indexed.
My hack replaces a bunch of code in the File64 class so that instead of making lots of seek and read calls, it memory-maps 8MB (could be made configurable) blocks of the file and replaces reads with memory copy operations.
I performed two benchmarks, both under the same conditions: right after reboot with nothing else running in the background.
For my input, I had a 606MB torrent of which I had downloaded 276Mb (44.5%). Since it's a torrent, the distribution of data and gaps is more or less uniform across the entire file. There is enough data present at the beginning of the file for VirtualDub to be able to work out the video metadata (i.e. resolution, frame rate, which codecs are in use) otherwise it would refuse to open it. I cut off exactly the first 100MB of the file and this was the data used in the benchmark. This is representative of the data I usually process.
Using canonical VirtualDub 1.5.10:
Using my hacked VirtualDub 1.5.10+mmap:
I ran the mmap benchmark a second time. It took 12.5sec real time, 12sec CPU time. There was no noticeable HDD access since the 100MB input fits entirely into physical memory.
Running a second benchmark using canonical VirtualDub causes loads of HDD thrashing, as if no caching happened at all. Also, compare the CPU times. Unpatched VirtualDub makes a much larger number of system calls so it accumulates more CPU time.
The patch is fine, functionally, but I think it could be cleaner.
Valid XHTML 1.1
copyright © 2004 Emil Mikulic
$Date: 2006/04/22 07:06:56 $