Media Foundation MPEG-4 Property Handler might report incorrect Video Frame Rate

To follow up previous post with Media Foundation bug, here goes another one related to property handler for MPEG-4 files (.MP4) and specific property PKEY_Video_FrameRate which reports frame rate for given media file.

This is the object responsible for filling columns in explorer, or otherwise visually the bug might look like this:


The values of the properties are also accessible programmatically using IPropertyStore::GetValue API, in which case they are:

  • PKEY_Video_FrameWidth1280 (VT_UI4) // 1,280
  • PKEY_Video_FrameHeight720 (VT_UI4) // 720
  • PKEY_Video_FrameRate1091345 (VT_UI4) // 1,091,345
  • PKEY_Video_Compression{34363248-0000-0010-8000-00AA00389B71} (VT_LPWSTR) // FourCC H264
  • PKEY_Video_FourCC875967048 (VT_UI4) // 875,967,048
  • PKEY_Video_HorizontalAspectRatio1 (VT_UI4) // 1
  • PKEY_Video_VerticalAspectRatio1 (VT_UI4) // 1
  • PKEY_Video_StreamNumber2 (VT_UI4) // 2
  • PKEY_Video_TotalBitrate12123288 (VT_UI4) // 12,123,288

The actual frame rate of the file is 50 fps. The file is playable well in every media player, so the problem is the reporting itself. Let us look inside the file to possibly identify the cause. The mdhd box for the video track shows the following information:


Let us do some math now:

  • Time Scale: 10,000,000
  • Duration: 4,501,200,000 (around 7.5 minutes)
  • Video Sample Count: 22,506

This makes the correct fps of 50 (frames per scaled duration). However the duration number itself is a pretty big one and looks exceeding the 32-bit range. Now let us try this one:

22506 / (4501200000 & ((1 << 32) – 1)) * 10000000

And we get 1,091. Bingo! Arithmetic overflow in the property handler then…

See also:

Bonus tool: FilePropertyStore application which reads properties of the file you drag and drop onto it, Win32 and x64 versions.


Windows Shell integration and Windows Live Messenger: things that should have never been done

If you drag a file over Windows Live Messenger‘s My Sharing Folders shell name space item, it would immediately interrupt dragging with an error message box, even if you never planned to drop onto this folder:

Windows Live Messenger

This should definitely be rather implemented a different way. If you ever tried to drag something using slow PC touchpad, you probably have an idea of how annoying such an interruption could be.

Windows Live Messenger was pre-installed. To disable shared folders feature, I wanted to find a proper setting in options, but it did not appear to be easy enough: Help button, Show the menu bar, Tools, Options, Sharing Folders on the left, oops! it was not helpful.

Going another way of finding DLL that hosts the shell extension revealed file named: C:\Program Files\Windows Live\Messenger\fsshext.8.5.1302.1018.dll. Once unregistered, the folder went away from the shell (process restart needed, typically logoff/logon):

C:\>regsvr32 /u "C:\Program Files\Windows Live\Messenger\fsshext.8.5.1302.1018.dll"

Yet another time about FFDShow

While new NTFS Links propery page is looking for contained junction points, it shows an animated picture to indicate opertation in progress. The picture is a stock resource and is taken from shell32.dll resource type “AVI” name 150. It is an Audio Video Interleave (AVI) file embedded into binary resources as is.

Alax.Info NTFS Links Junction Points Property Page in Operation

What is however interesting is that being saved as a file and double-clicked, it appeared to be crashing the player process. What might go wrong with a stock resource, is it FFDShow again? This was the first guess and yes, it was FFDShow again. This is a “video only” file with video encoded with MS-RLE compression, FOURCC ‘RLE ‘. Microsoft provides a VCM codec for the format through msrle32.dll.

However, as already discovered, FFDShow register itself under extremely high merit and for this reason is preferred as a video decoder and attempts to handle the decompression itself. But it fails, and miserably enough to crash the hosting process.

FFDShow Crash

The registration under unfairly high merit defeats the purpose of DirectShow’s powerful Intelligent Connect approach. “Why do you need a video decoder? You have FFDShow Video Decoder, forget about the others. Oops, sorry, I don’t like your file.”

Is there any way to stop the villain? Of course, there is.


NTFS Links: List junction points under certain directory

While NTFS junction points are powerful to relink files without duplicating data and/or moving between disks, they are treated as regular directories by most of software and it may unexpectedly result in conversion of a junction point into a regular directory with implied duplication of data and disk space waste.

This is a quick fix for the NTFS Links shell extension that allows to quickly list created junction points under certain directory, and delete if necessary. The update adds a property page Junction Points to NTFS non-UNC directory properties:

Directory Junction Points Property Page

This is a quick update, so be aware (also my TO DO list):

  • no Russian localization, sorry
  • context menu should also be given another item Open Containing Directory
  • does not work for root directories
  • list items should be OLE draggable
  • there should be a junction point validation feature that checks availability of substitution path and indicates result by an icon
  • I should remove the mess between “soft link” and”junction point” in favor of the latter

Release information:

Two mouse clicks 7-Zip archives for a developer

I have been frequently troubleshooting remote systems and otherwise provide various temporary binary files to remote production sites with fixes or beta versions of new features etc. The software is such that that customer sites have specific combination of hardware, configuration, hardware on LAN, software conflicts and there is a number of things that are very much easier troubleshooted directly on the production server, through remote connection. Typically I am using TightVNC and Windows Remote Desktop, sometimes LogMeIn, RAdmin and more rare alternatives (among such I would like to specially note TeamViewer).

Obviously except for released versions of binaries (which also exist in several versions from different configuration builds), there appear a number of intermediate files, DLLs and EXEs which are addressed to specific problems and fixes. The problem with multitude of different versions of the same DLL is widely known as DLL hell.

It is not actually a big hell since we are trying to follow simple rules:

  • DLLs should be backward compatible, or if the compatibility is ever broken, DLL version mismatch scenario should be handled as gracefully as possible
  • DLLs and other binaries should have VERSIONINFO resource
  • version information file version’s least significant number is incremented with each and every build; in particular this allows to keep privately program databases (PDB) and immediately find the corresponding database by file version
  • newer binaries should always have greated file version than older ones

The problem however has been that the typical process of building a temporary build of a library and uploading it to remote location required too many clicks. Considering a number of times I have been through these operations, an automation and a productivity tool should have appeared long ago. Finally this is solved by a shell extension that compresses binaries into a transferrable archive in two clicks:

Context Menu Shell Extension

Compression formats of 7-Zip (.7z), 7-ZIP SFX (.exe) and ZIP (.zip) are at user’s choice.