| Date: | February 16, 2005 / year-entry #40 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20050216-00/?p=36433 |
| Comments: | 15 |
| Summary: | The Animation control in the shell common controls library supports only a very limited class of AVI files. The AVI must be non-interleaved. The AVI must have exactly one video stream. The AVI may not have an audio stream. The AVI may not use palette changes. The AVI must be either uncompressed or BI_RLE8-compressed. Why... |
The Animation control in the shell common controls library supports only a very limited class of AVI files.
Why all these restrictions? Because the purpose of the Animation control is to be able to show simple animations. If you have a complex animation, you should be using one of the more advanced animation controls, like the MCIWnd window class. There would be no benefit to adding all the advanced AVI playback features were added to the shell Animation control. The result would just be a pointless clone of MCIWnd. This is something you need to keep in mind when designing a component whose original design goal is to be a simpler version of some other component. You must resist the urge to add features from that other component to your component. If you succumb, then you will end up with a component that does everything the original component did, even though your goal was to be a simpler version. So why did you write it? You spent months writing something that already exists. |
Comments (15)
Comments are closed. |
But where does this leave VBA programmers with no access to the MCIWnd class?
Makes sense–the shell animation control was designed to support the direct needs of the Win95 shell.
An interesting thing that was pointed out on this site: http://ian.winprog.org/archives/000024.html
The control is (or was, as of PDC 2003) being enhanced to play DirectX mesh file animations. The shell was going to display 3D animations; again, the control is designed to support the direct needs of the shell. Will be interesting to see if this feature remains.
Why does the Animation Control of Common Controls 6 (WinXP themed apps) no longer support a seperate thread for displaying the animation? This is a major drawback!
As a result, you can notice that many animations in themed apps no longer run smoothly. For example, you can sometimes even see delays in the File Copy animation in Windows Explorer or the Empty Recycle Bin animation of Outlook 2003 (Outlook versions earlier than 2003 are not themed and thus show no delay).
And here’s where there’s a gap between two groups at Microsoft: there are requirements on the part of the Shell control, and there are properties availible in the Shell, and they don’t match up. I just did a find of all the .AVI files on my machine, and did a "Properties" on the official Microsoft ones. Of the five required properties of an AVI file to show in the control, perhaps two are exposed in the "Properties" pane.
Those two are:
Audio Duration (which even the official Microsoft ‘FileMove’ etc AVI files have: this either means that an AVI file can have Audio and it just doesn’t play or that the results on the Property Pane are wrong)
Video Compression (but the official FileMove.AVI is MS-RLE which doesn’t match the list that Raymond gave)
Upshot: there’s no built-in way to tell if any given AVI file is suitable for the shell control or not.
The Properties page is not for geeks. The requirements for AVIs in the common animation control are geeky. Use a geeky property viewer.
I wish the IE COM control (shdocw.dll) also did remove some of it’s threads. It usually has 6-7 threads running (while displaying a already loaded page).
"Note MCIWnd is not available on 64-bit operating systems."
Looks like our old friend is being put to rest.
Chris: Nope, it’s not good enough to just try it on my machine. Microsoft, like all real companies, upgrades its components regularly. If I want to write code that works on a large number of machines (and usually I do), then I have to keep within the (hopefully documented) confines of the API and not stray into uncharted waters. Ergo, I need to verify that my AVI files match the requirements.
Raymond: A quick web search for "geeky property viewer" comes up with no hits :-) A quick download of several freeware AVI editors shows that none of the ones I downloaded tell me those properties. This includes the "Movie Maker" that comes with XP and the "Media Player".
The property pages for AVI files do show some pretty geeky information (bit rate, encoding, and frames per second spring to mind). They just don’t show the right geeky information.
Don’t forget that of the two properties that are mentioned in the property page, neither is completely correct. The AVI encoding ireported by the Property Page does not match the official list of supported encodings in MSDN and the Property Page mentions an audio track that according to MSDN should make the AVI unusable in the component.
The component is no longer simple because it’s now hard to determine if any particular AVI meets the documented requirements (and it’s also hard to know if the documented requirements are even correct). Now to use the control in any other than toys for my own computer I have to consider agressive testing: will each and every AVI that I ship work with each and every version of Windows I want to support? Or should I just "hope for the best"?
It’s hardly the sort of decision that a "simple" component should make anyone make!
I would expect your AVI creation tool to let you specify interleaving, how many streams to save, what compression format to use, etc.
Peter: "Windows Media Player" and "Windows Movie Maker" aren’t exactly geeky tools either :) Try some of the tools at [1] and you’ll probably get enough information about the video files.
[1] http://www.divx-digest.com/software/index3.html#encoding_edit
@Peter: If you want to play an animation in your program, it’s not really *that* difficult just to test a particular avi file to see if it’s suitable, right?
"If you want to play an animation in your program, it’s not really *that* difficult just to test a particular avi file to see if it’s suitable, right?"
Alternatively, you shouldn’t be playing other people’s AVIs in your app anyway, so you should be able design your own to match the requirements ;)
"The AVI must be non-interleaved. The AVI must have exactly one video stream. The AVI may not have an audio stream."
I’d say that it doesn’t actually support AVI files at all — the A in AVI is for audio and the I is for interleaved so it can actually only play V files. (Sorry, I’ll get my coat… :)
@Dean Harding: My comment came out more snarky than I wanted it to, sorry.
@Peter: You’ll notice that I never suggested that you *only* try it on your machine. What I suggested was that if you are worried about whether or not a particular AVI file will play, test it out (on ALL platforms you will be supporting). What’s that? You don’t test your program on all the platforms you will be supporting? Wow, that’s unfortunate for your users.
As for API updates, do you recall seeing any of Raymond’s posts about backward compatibility? If you try your AVIs out on base installs of all the operating systems you want to support, I doubt Microsoft is going to break them with an update.
As for generating the AVI correctly in the first place, follow the docs, if it doesn’t work, try reducing the complexity of the AVI. I mean, putting a few video frames into an AVI file is not that difficult (especially with the API).
@Dean Harding:
>Alternatively, you shouldn’t be playing other people’s AVIs in your app anyway, so you should be able design your own to match the requirements
Uh, where did I suggest that he should use somebody else’s AVIs in his own program. ???