Softwares and Drivers for Specific Models


ASUS Eee PC Specific	Dell Mini Specific	Lenovo Specific	Acer Aspire Specific	Samsung N Specific	Toshiba Specific	Gigabyte Specific	iiView Specific	MSI Wind Specific

HP Mini Specific	Fujitsu Specific	Sony Vaio Specific	LG Specific	Windows XP Softwares	Advertise Here!	Rss Subscribe	Facebook Page	Follow us @Twitter

VirtualDub 1.9.10 Stable

Ultrabook / Netbook Software Downloads » Audio & Video Softwares » VirtualDub 1.9.10 Stable

Date Added:

Sep 20, 2010 04:02 AM

Publisher's Description:

VirtualDub is a video capture/processing utility for 32-bit and 64-bit Windows platforms (98/ME/NT4/2000/XP/Vista/7), licensed under the GNU General Public License (GPL). It lacks the editing power of a general-purpose editor such as Adobe Premiere, but is streamlined for fast linear operations over video. It has batch-processing capabilities for processing large numbers of files and can be extended with third-party video filters. VirtualDub is mainly geared toward processing AVI files, although it can read (not write) MPEG-1 and also handle sets of BMP images.

I basically started VirtualDub in college to do some quick capture-and-encoding that I wanted done; from there it's basically grown into a more general utility that can trim and clean up video before exporting to tape or processing with another program. I released it on the web and others found it useful, so I've been tinkering around with its code ever since. If you have the time, please download and enjoy.
§ ¶
Live audio playback

My latency woe research continues, this time on how to handle playback. I've managed to write a new basic audio renderer and hook it into the DirectShow graph, but the next issue now is how to handle playback. When playing stored audio/video data, you can read the source at variable rate as necessary, so playback timing is simple: minimize the difference between the audio and video timing. In other words, the user can't really tell that you're buffering two full seconds of audio if the video is also delayed by the same amount. Where this does matter is in seek latency, because then the decoder needs to re-fill that delay before you can restart playback, but even then doing soft start or just having a fast decoder can do the trick.

However, live input -- or specifically in this case, interactive live input -- is a tougher problem. In this case the clock already starts ticking the moment the user hits a button, and therefore you're already late by the time you receive audio. This means that minimizing latency in the entire pipeline is absolutely critical. Unfortunately, as I mentioned before, the recording device I'm using sends 40ms packets, so already by the time I receive the first byte I'm already that much behind and I don't really need another 100ms of latency on the output. This means that in the playback code, the problems are: