Fragile MFEnumDeviceSources

As I mentioned in earlier post, Media Foundation video capture capability is internally using undocumented categories with pretty much the same transforms and enumeration applicable to categories documented.

Without documenting it as public contract, MFEnumDeviceSources enumerates transforms, builds standard implementation for IMFMediaSource on top of available transform and… voila! Media Foundation offers “lightweight” API for video/audio capture. Lightweight presumably stands for “of substandard quality” here. It would be lightweight, if they documented the transforms, the enumeration API, make it extensible, decoupled their media source implementation from the transform, documented the internal communication between the two. However, it seems that there has been no progress in this direction since Windows 7.

The implementation is good in terms that it is implementing the documented promises, however if earlier APIs were developer friendly and well-extensible, here it is just minimal implementation without offering too much to people. Even though it could be extensible, it looks like Microsoft simply decided to not spend effort on pushing it to feature rich state, clean and open to developers.

A simple example: it is still possible to register your own transform into undocumented category. MFEnumDeviceSources implementation does see it, picks it up. Not a hardware transform? No go – we only offer media source functionality for hardware transform (actually for no apparent reason, other than possibly to put a stop to custom extensions). Hardware transform? No go – we cannot accept it for another reason, we only offer media source implementation for hardware transforms we “like”. The most confusing part is that rejection of unsupported transform might cause fatal failure in the enumeration loop: the rejection will make other, supported transforms and devices unavailable to applications. I suppose that once the loop encounters unsupported device, it simply forwards the failure upwards invalidating devices already found and yet to be enumerated. It is not the way the API should be developed, but it is okay – the category remains internal and undocumented.

Leave a Reply