VirtualDub 1.5.10

12/2/2003 News: VirtualDub 1.5.10 released
VirtualDub 1.5.10 is out -- it fixes a couple of critical crashes, one of them being the VideoCD crash, and the other being a stability issue on Windows 95/98 systems. Full props go to "fccHandler" for finding the bug in the source code that caused the latter problem. This version also fixes a few random problems I happened to identify on the way. Work is still progressing on the experimental version, which I hope to get to releasable — major-embarrassment-free — status in the near future.

1.5.10 contains a workaround for a rather sticky problem with certain filters, such as Deflicker. Basically, some filters that rely on separate analysis and render passes make a slightly invalid assumption — that once the analysis pass finishes, the next startProc call received will be the user starting the render pass. Well, this isn't actually guaranteed in the spec and recent 1.5.x versions break such filters when they refresh the output pane after the analysis. The result is that the filter dumps its analysis data and builds a one-frame trace before the render starts. Whoops. This problem actually exists in all versions of VirtualDub, but in earlier versions you have to explicitly step the current frame position in order for the filter chain to restart, whereas 1.5.9 will do it any time the output pane needs to be refreshed and the filter chain is idle. A possible workaround is to disable the output pane before doing the analysis pass, although I haven't actually tried this.

Video codecs that support multi-pass modes, such as DivX, are not affected by the problem as they are not fed frames except during an actual render to disk. They do receive extra start/end notifications in the video compression dialog, but anyone who has tried testing a multi-pass codec against VirtualDub has probably discovered this long ago. (It's a workaround for some early codecs that accept formats in ICCompressQuery(), but then reject them in ICCompressBegin().)

The change in 1.5.10 is that the FilterStateInfo structure contains an extra field indicating whether a preview is active. Unfortunately, filter authors will have to add a check for this structure field and recompile their filter against the filter.h header from the 1.5.10 source to take advantage to this. I have bumped the API version so that this can be done without breaking compatibility with earlier hosts.

Backwards compatibility, while desirable, is a huge pain.

I had an interesting encounter this weekend while playing Final Fantasy XI. While in Selbina I partied up with a few Japanese people who mostly didn't speak English — and, of course, I don't speak Japanese. I can read some Hiragana and Katakana glyphs, so I could mostly figure out who they were addressing and simple questions like "are you ok?". Beyond that, though, the most I ended up with was making an idiot out of myself by typing token phrases in romanji that I learned from anime. (Perhaps the most embarrassing was that one of them asked in romanji if I understood romanji, and I answered "iie" without thinking.) Trying to communicate across the language barrier is kind of fun, especially since in this case the worst that happens is that you end up lost in Vana'diel or perhaps virtually die a couple of times, and because words aren't necessary to convey "I'm getting whaled on." I do feel a bit ashamed, though, that my Japanese party members did know some English, while the only other languages I'm fluent in are C/C++ and assembly. I've always wanted to learn Japanese, but it's very difficult to do so without (a) serious time and effort placed into learning it, (b) an immersive environment, and (c) a real dictionary.

P.S. The "automatic translation" ability in the game is rather useless, as you have to choose from an incomplete list of phrases, and the menus that display the phrases are far too small so they all ellipsize ("Are you...").

P.P.S. A game that leaves your character stranded in the world because you hit the Windows key or Alt-Tab, and then displays an error dialog saying "Final Fantasy XI quit because the app lost full screen mode" is lame. This has little to do with the language barrier but it's so stupid I had to mention it. I tried using my own custom WinKey blocker which uses the Windows NT low-level keyboard hook, but for some reason it failed when FFXI was running (DirectInput?).

Current build (1.5.10, stable):
[features added]
* Removed "accept partial streams" from MPEG-1 options
and made it enabled by default; added warning.
* Filters are now notified whether a render is for
preview or output purposes.

[bugs fixed]
* Fixed a stall condition at end of render when advanced
audio pipeline is active.
* Fixed "frame not found" errors when processing
truncated MPEG-1 streams.
* BMP reader can now handle BITMAPCOREHEADER type
headers (fixes incompatibility with ZSNES
screenshots).
* Filters were receiving garbage frame timings in
capture mode.

[regressions fixed]
* Fixed instability in application when parsing VideoCD
streams.
* Fixed crash on exit on Windows 9x systems.
* Fixed visual errors in input pane when decoding
Microsoft Video 1 to a 565 16-bit display.

Homepage
 
Top