Current version

v1.10.4 (stable)


Main page
Archived news
Plugin SDK
Knowledge base
Contact info
Other projects



« April 2021
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  


01 Dec - 31 Dec 2013
01 Oct - 31 Oct 2013
01 Aug - 31 Aug 2013
01 May - 31 May 2013
01 Mar - 31 Mar 2013
01 Feb - 29 Feb 2013
01 Dec - 31 Dec 2012
01 Nov - 30 Nov 2012
01 Oct - 31 Oct 2012
01 Sep - 30 Sep 2012
01 Aug - 31 Aug 2012
01 June - 30 June 2012
01 May - 31 May 2012
01 Apr - 30 Apr 2012
01 Dec - 31 Dec 2011
01 Nov - 30 Nov 2011
01 Oct - 31 Oct 2011
01 Sep - 30 Sep 2011
01 Aug - 31 Aug 2011
01 Jul - 31 Jul 2011
01 June - 30 June 2011
01 May - 31 May 2011
01 Apr - 30 Apr 2011
01 Mar - 31 Mar 2011
01 Feb - 29 Feb 2011
01 Jan - 31 Jan 2011
01 Dec - 31 Dec 2010
01 Nov - 30 Nov 2010
01 Oct - 31 Oct 2010
01 Sep - 30 Sep 2010
01 Aug - 31 Aug 2010
01 Jul - 31 Jul 2010
01 June - 30 June 2010
01 May - 31 May 2010
01 Apr - 30 Apr 2010
01 Mar - 31 Mar 2010
01 Feb - 29 Feb 2010
01 Jan - 31 Jan 2010
01 Dec - 31 Dec 2009
01 Nov - 30 Nov 2009
01 Oct - 31 Oct 2009
01 Sep - 30 Sep 2009
01 Aug - 31 Aug 2009
01 Jul - 31 Jul 2009
01 June - 30 June 2009
01 May - 31 May 2009
01 Apr - 30 Apr 2009
01 Mar - 31 Mar 2009
01 Feb - 29 Feb 2009
01 Jan - 31 Jan 2009
01 Dec - 31 Dec 2008
01 Nov - 30 Nov 2008
01 Oct - 31 Oct 2008
01 Sep - 30 Sep 2008
01 Aug - 31 Aug 2008
01 Jul - 31 Jul 2008
01 June - 30 June 2008
01 May - 31 May 2008
01 Apr - 30 Apr 2008
01 Mar - 31 Mar 2008
01 Feb - 29 Feb 2008
01 Jan - 31 Jan 2008
01 Dec - 31 Dec 2007
01 Nov - 30 Nov 2007
01 Oct - 31 Oct 2007
01 Sep - 30 Sep 2007
01 Aug - 31 Aug 2007
01 Jul - 31 Jul 2007
01 June - 30 June 2007
01 May - 31 May 2007
01 Apr - 30 Apr 2007
01 Mar - 31 Mar 2007
01 Feb - 29 Feb 2007
01 Jan - 31 Jan 2007
01 Dec - 31 Dec 2006
01 Nov - 30 Nov 2006
01 Oct - 31 Oct 2006
01 Sep - 30 Sep 2006
01 Aug - 31 Aug 2006
01 Jul - 31 Jul 2006
01 June - 30 June 2006
01 May - 31 May 2006
01 Apr - 30 Apr 2006
01 Mar - 31 Mar 2006
01 Feb - 29 Feb 2006
01 Jan - 31 Jan 2006
01 Dec - 31 Dec 2005
01 Nov - 30 Nov 2005
01 Oct - 31 Oct 2005
01 Sep - 30 Sep 2005
01 Aug - 31 Aug 2005
01 Jul - 31 Jul 2005
01 June - 30 June 2005
01 May - 31 May 2005
01 Apr - 30 Apr 2005
01 Mar - 31 Mar 2005
01 Feb - 29 Feb 2005
01 Jan - 31 Jan 2005
01 Dec - 31 Dec 2004
01 Nov - 30 Nov 2004
01 Oct - 31 Oct 2004
01 Sep - 30 Sep 2004
01 Aug - 31 Aug 2004


Powered by Pivot  
XML: RSS feed 
XML: Atom feed 

§ Alright, who forgot to send WM_SETFONT?

One of the features I like from Windows 7 is the Win+P shortcut, which brings up dual-monitor settings:

[Windows projector mode dialog with System font]

I like this because otherwise I have to use the Fn+F8 shortcut to cycle through multi-mon modes, and it takes several seconds for the displays to reinit every time I cycle to a different mode. Any UI procedure that involves me having to wait seconds for something to happen multiple times sucks. This way, I only take the mode switch hit once.

There's only one problem with it, though: it's using the default System font, which on the ugly scale is eclipsed only by Chicago and Topaz.

Admittedly I'm asking for it by using the Classic theme -- it looks fine with Aero -- but it's one of those small things that catches my eye, kind of like dialog buttons that don't line up. I'm guessing someone didn't bother to send the WM_SETFONT message, which is normally how you end up with this situation. The System font is the default font you get when you create a Win32 button control manually, and you have to change it manually to GetStockObject(DEFAULT_GUI_FONT) or some other UI font. Fortunately, dialogs do this automatically, so most of the time this isn't a problem, except when you're doing something tricky like dynamically creating layouts.

(Inevitably whenever I've posted something like this, someone immediately posts a snarky comment pointing out where I've forgotten to do the same thing myself. Bring it on!!!)

(Read more....)

§ Conflict between VS2010 beta 2 and old DirectX SDKs

I've just started evaluating Visual Studio 2010 beta 2, and pretty quickly ran into this problem:

------ Build started: Project: system, Configuration: Debug Win32 ------
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\objidl.h(11280): error C2061: syntax error : identifier '__RPC__out_xcount_part'
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\objidl.h(11281): error C2059: syntax error : ')'
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\objidl.h(11281): fatal error C1903: unable to recover from previous error(s); stopping compilation

Turning on /showIncludes reveals the cause. It turns out that this is caused by a conflict between older versions of the DirectX SDK and the Windows 7 SDK that ships with VS2010 beta 2. Unfortunately, Microsoft put rpcsal.h into both SDKs, which causes disaster:

Note: including file: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\vfw.h
Note: including file: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\mmsystem.h
Note: including file: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\pshpack1.h
Note: including file: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\poppack.h
Note: including file: c:\program files (x86)\microsoft sdks\windows\v7.0a\include\pshpack8.h
Note: including file: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\mmreg.h
Note: including file: c:\program files (x86)\microsoft sdks\windows\v7.0a\include\pshpack1.h
Note: including file: c:\program files (x86)\microsoft sdks\windows\v7.0a\include\poppack.h
Note: including file: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\ole2.h
Note: including file: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\pshpack8.h
Note: including file: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\objbase.h
Note: including file: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\rpc.h
Note: including file: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\rpcdce.h
Note: including file: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\rpcdcep.h
Note: including file: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\rpcnsi.h
Note: including file: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\rpcnterr.h
Note: including file: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\rpcasync.h
Note: including file: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\rpcndr.h
Note: including file: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\pshpack8.h
Note: including file: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\rpcnsip.h
Note: including file: I:\dx9sdk2\include\rpcsal.h
Note: including file: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\poppack.h
Note: including file: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\pshpack8.h
Note: including file: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wtypes.h
Note: including file: c:\program files (x86)\microsoft sdks\windows\v7.0a\include\guiddef.h
Note: including file: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\unknwn.h
Note: including file: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\objidl.h

Switching to a newer version of the DirectX SDK fixes the problem.

(Read more....)

§ VirtualDub 1.9.7 released

VirtualDub 1.9.7 is now out, and is another stable release containing only bug fixes for reported problems.

The most important fix in this version is a change to the code that reads AVI hierarchical indices. Normally these indices are only two levels deep, with a master index in the header and subindex blocks covering no more than 4GB. If you're wondering whether deeper indices are possible, the answer is an emphatic yes. It turns out there's at least one hardware/software editing solution that produces AVI files with deep index trees, because it links all of the subindex blocks with internal nodes arranged in a degenerate tree. The trace I received of a 46GB capture showed a tree more than 20 levels deep. This was causing a crash in 1.9.6 because of some changes that I made a while back to fix slow index reading speed problems over a network; in doing so I had increased the size of an I/O buffer on the stack and this was causing a stack overflow. 1.9.7's index read routine has much lower stack usage and should be able to read AVI files with deeply nested indices again.

I've been spending some time in the dev branch trying to add new raw video formats to the blitter library, and I think I've spent so much time in Scilab staring at YCbCr matrices that they're all starting to blur together. Nevertheless, the blitter autotests are finally passing again (although at a slower rate, since the test matrix is now 37x37 instead of 17x17), and I think I'm finally making some progress here. The next step would be to add support for the new formats to the video source and display paths, which should finally get some of these new formats into a usable path. Some optimization would be needed after that since all of the new formats are currently leveraging a lot of unvectorized C++ code, but we'll see how that turns out.

(Read more....)

§ Exploring hardware overlay support in Windows 7

I finally got around to trying out the new hardware overlay support in Windows 7:

Hardware overlays are a quirk of video hardware that have survived in spite of their lack of evolution. They're essentially a secondary display scan out path in the video chip and are intended for video display, so that a video in a window can use a more optimized display format instead of the rest of the desktop for better playback performance. The biggest advantages of a hardware overlay are hardware accelerated scaling and color conversion from YCbCr to RGB, formerly very expensive operations; in some cases, you also got primitive deinterlacing and some additional TV-out support. Unfortunately, they were often also buggy in drivers. Windows Vista appeared to be the end of the line for overlays, as they were not supported in desktop composition mode, but guess what... they're back in Windows 7. As it turns out, hardware overlays are still valuable for a couple of reasons, one being that you can flip them faster and asynchronously from the composited desktop (good for performance) and because you can't capture their image in a screen grab operation (good for the paranoid). And this time, they have a few improvements, too.

The way you get to overlays is a bit different in Windows 7. In older versions, they were a feature of DirectDraw, and that meant you basically couldn't do anything other than lock-and-load -- DirectDraw couldn't even do color conversion, other than what the hardware overlay itself supported. This time, they're hooked up to Direct3D, which makes them a lot more useful since you can process video through DXVA and shader hardware and push the result into the overlay. The color space is now better defined, as there are flags for whether RGB output is computer RGB (0-255) or studio RGB (16-235), and whether YCbCr output is Rec.601/709 or xvYcc. So far, so good -- time to try it!

(Read more....)

§ Dear moron who's been manually spamming my blog for three days, please stop

Dear moron,

Stop spamming my blog with bogus comments linking to your stupid web development website. I'm tired of having to manually clean out your phony posts that pitifully attempt to look like real posts and continually add more IP blocks to my block filter. It's been three days and more than three dozen posts and this is getting really old.

Pissed off,
Avery Lee, pissed off webmaster of

(Read more....)

§ The whole reason of FOURCC codes is to prevent this mess

I really hate it when people overload four-character (FOURCC) codes for video formats they weren't intended to handle. Why?

Because it creates a mess that the user has to clean up manually.

The whole point of FOURCC codes and format structures is to unambiguously identify the format and color space of image data. When you overload an existing FOURCC with a new meaning, it creates ambiguity that causes conversion errors throughout a video processing pipeline that can be hard to track down. One common transgression is writing full range YCbCr data into the YUY2 FOURCC instead of 16-235 luma range. This creates all sorts of situations where video ends up either 14% higher or lower in contrast because two modules disagree on what range is being used, and they can't autonegotiate because the same code has been overloaded. Ditto for Rec. 601 vs. Rec. 709 coefficients, or interlaced vs. noninterlaced.

One solution that is often suggested is to make it a user choice. Well, that's one way to "solve" the problem, but it propagates the mess, and it also assumes that the user knows the answer to the question. Do your users whether the video codec you are using uses full-range luma or not? Does the vendor who makes the video codec document that? Probably not. It gets worse, though, when you consider that there may be hidden conversions in the pipeline. You can argue that hidden conversions are bad, and in general it's better to avoid them for performance and quality reasons. However, they're sometimes unavoidable, particularly for display. What would you do if you saw this dialog:

[Absurd warning]

...followed by more for the video compressor and for the video driver. Heck, at this point, why bother having FOURCCs at all? Just make the user enter in the color space and chroma subsampling information too.

I've also heard the suggestion to make the determination based on whether the frame size is SD or HD. That's not really any better. So now you can't resize video temporarily across the SD/HD boundary without incurring a color conversion... yuck.

An additional reason I've heard to put in options is to recover blacker than black (BTB) and whiter than white (WTW) areas. Well, yes, you can do that via changing the color space, but that's not really what you're trying to do -- you need some sort of conversion to map those values in range, but the full range YCbCr color space is unlikely to be the one you want, and by changing the color space you're also whacking chroma as well as luma. What you really need is a custom color conversion matrix or at least to remap the luma range. Otherwise, you're likely reducing contrast more than necessary or introducing slight color shifts into your video.

At this point, I've resigned myself to having to eventually add some of these options to VirtualDub, because I see far too many cases where people have broken color conversions in their pipeline and they need to be able to compensate for codecs and players that use the wrong conversion formula. However, I fully intend to put a big "THIS IS NON-STANDARD" flag on the options, because I do not want to further the idea that this is the way that FOURCCs are supposed to work. Doing this is a big change to the blitter and display libraries, too, so I have no idea when this would be implemented.

(Read more....)

§ Why the #&* did you put those commands next to each other

Through a convoluted series of weblinks, I ended up on this page, which describes the Windows User Experience Interaction Guidelines for ribbons:

From my experience, there's a pretty high chance that either you absolute adore the ribbon or you think it is the devil spawn of UI controls. I haven't decided yet, only having used ribbon-based applications for a short time, and while I didn't find it an especially amazing experience, I didn't despise it either. I figure that it isn't a bad idea to read through the guidelines and see what generally applicable wisdom is in the ribbon's design.

This particular sentence had me cheering:

Avoid placing destructive commands next to frequently used commands. A command is considered destructive if its effect is widespread and either it cannot be easily undone or the effect isn't immediately noticeable.

Don't know what I mean? Here's one example, from the Windows common file dialog:

[file dialog]

See the first icon with a yellow folder on it? That's the "go up to parent" button. See the icon next to it with another yellow folder? That's the new folder button. I can't tell you how many times I've accidentally created a new folder while trying to go up. Even worse, if you hit the Escape key to abort the new folder, it just leaves a folder called New Folder that you have to manually delete. Argh!!!!

Here's another example, this time from the P4Win application, which is used to interact with a Perforce source code control depot. This is the context menu you get when right-clicking on a file in a pending changelist:

[P4Win changelist context menu]

One of the things I do very frequently is integrate files between branches, and before doing so I often diff the changes, especially if the merge is involved. I'd like to know who decided to put the "Reopen for Edit" command right next to the Diff command. As you can probably guess, I have a habit of accidentally re-opening branched files for edit. Unlike the New Folder case with the file dialog, there's no easy way to undo this; if you're a purist and want to keep the integration changelist clean, you have to revert the file and re-branch it. Sigh.

So, basically, putting some separation between one command that the user might use a lot and another that has annoying effects seems like a good idea even if you're not using a ribbon.

P.S. I found this portion of the ribbon UI guidelines ironic, given how it was received when it first appeared in Microsoft Office:

Avoid marketing-based placement. Marketing objectives around the promotion of new features tend to change over time. Consider future versions of your product and how much frustration a constantly changing organization will cause.
(Read more....)