![]() I've seen some white papers from Microsoft recommending that you should eschew use of RDTSC for high-precision timing and use QueryPerformanceCounter() instead, for better stability on multicore systems. I wouldn't recommend turning off frame inserts, but turning off frame drops is now reasonable if your video input is stable.Īs usual, contact me by email or the forum if you have problems and suspect an issue with the resampler. Although the video timing correction option will now try to globally change the speed of video to account for a lower or faster than expected frame rate, it will still emit drop/insert commands when it detects holes in the input. (There was a really badly fragmented portion of my hard drive during my tests, so this scenario was well-tested.) However, I did rework the code so that disabling drops or inserts no longer causes a sync error - the timing controllers can now see a video timing error of more than one-half frame. Some are of the opinion that such a resampler should mean no frame aberrations, but the problem is that any timing glitches in the video stream that are not handled by frame drops or inserts must be fixed by correspondingly wonking the audio stream in speed and pitch, which can be equally noticeable. Now, one thing to be aware of with regard to the audio resampling in the capture module is that it does not guarantee zero dropped/inserted frames. ![]() In addition, the default is now to only determine the relative latency from the starting several seconds of the stream, and if that still doesn't work, the relative latency can be manually set. The current build now has a semi-haphazard set of PID controllers and filters to control audio and video timing that would probably make an EE professor cringe, but seems to work better than the old code. Also, the algorithm I was using to determine the relative start offset between the audio and video streams could become progressively unstable over time with regard to noise sensitivity. It turned out that there was a nasty bug in the audio resampler that caused it not to account for a non-zero start time at the beginning of the video stream. This meant that errors during the capture like disk full errors sometimes got reported as internal errors or simply crashes/hangs. One was that I forgot to restore the SEH chain properly in the audio resampler when I borrowed the stack pointer for an eighth register (hey, if I'm going to write assembly language, I might as well go full bore), and the other is that the crash trap I had in the capture callback was trapping C++ exceptions too. Which was a good thing, because I managed to watch a full season's worth of Alias DVDs, and in capturing them off my PS2's output - testing files deleted immediately afterward, of course - I found two huge bugs in the capture module at the last minute. I was about to release this a few days ago, but I decided to do some long-duration capture testing instead. one hour), you can't shuttle the tape or control via timecode, and it only records type-2 DVs, but it's a little better than before, at least. It isn't terribly tested (implementation and testing time approx. Well, as luck would have it, when I visited my older brother John over the holidays I was able to scam^H^H^Hborrow some time with his DV camcorder to develop against and add the code to insert the DV splitter into the graph. Previously this didn't work because DV data comes in as type MEDIATYPE_Interleaved rather than separate MEDIATYPE_Video and MEDIATYPE_Audio streams I don't own a DV camcorder, and the scenery around me is far too boring to warrant me getting one, so I didn't have a way to look at the filter graph and fix this. One notable feature that I snuck into this build is that you can now capture from a DV capture device that uses the MSDV driver through DirectShow. ![]() Because the resynchronizer was quite heavily reworked, and because I sneaked in several features, both capture and non-capture, this build is marked as experimental. Special props go to the users with handles Moitah and i4004 on the forums, who graciously spent a lot of time telling me that my resynchronizer sucked and that giving me hard data as to what was going on. It took a long time primarily because I spent a lot of time reworking the timing logic in the capture module and going back and forth with some users who were willing to test internal builds with varying balances of breakage and functionality. ![]() VirtualDub 1.6.12 has been posted to SourceForge.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |