none
What's the best base for a custom DS video renderer implementation?

    Question

  • I have developed a custom video renderer implementation, based on the latest SDK "baseclasses" library (with some minor tweaks).

    However, the "baseclasses" seem to be quite old, so I'm wondering if there is something else that might be ... a "more solid foundation" :)

    I realize that I could write everything from scratch, but given that I don't have that much experience with DirectShow, and given that it's not a trivial matter by far, and given that the kind of multithreading that goes on in a DirectShow filter graph kind-of scares me, I'd rather not.

    Aside from the scary DirectShow stuff, the renderer filter is pretty simple though. It just copies the frame data into a custom frame queue that I implemented. So that the application can then later scan the queue, select the most appropriate video frame for the GUI frame that's currently being rendered, upload to a D3D9 texture and render it.

    If you're interested, the reasons why I want to use a custom video renderer...

    • Our application uses Direct3D9 to render our GUI, and the video is rendered "inside" that GUI.
    • Refreshing our GUI with the video refresh rate is no option, we need the GUI to run at full FPS (60Hz), whereas the videos we play only have 24...30 FPS.
    • In most setups, our application actually uses two Direct3D9 devices on two distinct monitors to display stuff - and the same video stream needs to be rendered on both displays.
    • If possible, we'd like to switch to exclusive full screen mode soon (should be possible on two monitors at the same time, given that we use the same focus window for both D3D9 devices).
    • As a bonus it'd be nice if we could control the A/V delay. And since we have two different monitors (with possibly very different video latencies), we'd need to control it by delaying the video stream.

    Currently we're using two EVR instances connected to the same video decoder via an "infinite pin T filter". Which has all kinds of drawbacks and requires all kinds of scary workarounds.

    Wednesday, May 4, 2016 7:54 PM

Answers

  • What do you mean by "quite old"?  The miracle of DirectShow is that, even though it was written in 1995, that original code still supports the many wild and varied multimedia formats that have been developed since.  The latest baseclasses update I'm aware of is from 2009, in the Windows 7 SDK, but even that has only minor modifications from the original release.

    In other words, it has not been grossly updated because gross updates have not been needed.  There is no more solid foundation than the base classes.


    Tim Roberts, Driver MVP Providenza & Boekelheide, Inc.

    • Marked as answer by Paul Groke Tuesday, May 10, 2016 9:24 AM
    Saturday, May 7, 2016 12:05 AM

All replies

  • \Samples\C++\DirectShow\Filters\SampVid sample in old DirectX SDK (yet not even Platform/Windows SDK) is perhaps the closest sample.

    Still mentioned here, was removed from samples at some point. There was nothing newer.


    http://alax.info/blog/tag/directshow


    Thursday, May 5, 2016 5:17 AM
  • What do you mean by "quite old"?  The miracle of DirectShow is that, even though it was written in 1995, that original code still supports the many wild and varied multimedia formats that have been developed since.  The latest baseclasses update I'm aware of is from 2009, in the Windows 7 SDK, but even that has only minor modifications from the original release.

    In other words, it has not been grossly updated because gross updates have not been needed.  There is no more solid foundation than the base classes.


    Tim Roberts, Driver MVP Providenza & Boekelheide, Inc.

    • Marked as answer by Paul Groke Tuesday, May 10, 2016 9:24 AM
    Saturday, May 7, 2016 12:05 AM
  • @Tim Roberts

    I'm using the version from the "Microsoft Windows SDK for Windows 7 and .NET Framework 4", which is the latest version that I could find. Also the changes in the latest SDKs are not really relevant (e.g. addition of PREFAST/SAL macros). I.e. there have not been relevant changes for a very long time. That's what I mean by "quite old".

    Also I'm not talking about gross updates. Over a period of 7-10 years I just would expect the occasional bug fix. Unless of course MS has stopped supporting/caring for the project. Which would be a bad sign - it would mean that there could potentially be a huge number of bugs in the library.

    Like the one in the implementation of the EVR DirectShow wrapper that I described here. Or some strange VMR9 behavior that I had to write workarounds for (e.g. VMR9 not recovering in some cases after a monitor has been plugged in/unplugged). I just mention them because, if a project still has bugs like that, its reasonable to assume that it doesn't receive much love from MS, and that other parts of the project might be in a very bad state as well. And there is no place where MS officially accepts bug reports for DirectShow (or any Windows component/base library for that matter). Which is also a very bad sign.

    So even if one accepts the design of the DirectShow interfaces as a miracle (I don't, I would just call it good software design combined with a good portion of luck), that doesn't mean that the implementation of a base-library that's provided in the SDK is of especially high quality. I don't even know if MS is using that library for their own filters.

    @Roman Ryltsov

    Yes, thanks :)

    That's the sample I started from (combined with the slightly newer version of the baseclasses library from the Win7/Net4 SDK).

    Monday, May 9, 2016 1:55 PM
  • >>> Also I'm not talking about gross updates. Over a period of 7-10 years I just would expect the occasional bug fix.

    But remember, even 7 years ago, DirectShow was already 15 years old.  The baseclasses were released in source form from the start.  They've had more than 2 decades of attention paid by programmers who care.  The problems were ironed out a long time ago.

    >>> Like the one in the implementation of the EVR DirectShow wrapper that I describedhere. Or some strange VMR9 behavior that I had to write workarounds for (e.g. VMR9 not recovering in some cases after a monitor has been plugged in/unplugged). 

    I do not claim that there are no problems in the components where source code has NOT been released (like VMR and EVR), but the baseclasses are pretty much a solved problem.

    Now, having said all that, it's true that the folks in Redmond consider DirectShow to be a dead technology.  They've moved on to Media Foundation, for reasons that utterly escape me.  I have YET to find a problem that Media Foundation solves better than DirectShow.  Its inherent limitations mean that there are problems it simply cannot solve.  I will never understand why they chose to start over, instead of patching whatever they didn't like in DShow.  The fundamental concepts are absolutely identical, although the vocabulary is different.  It's just a waste of resources.


    Tim Roberts, Driver MVP Providenza & Boekelheide, Inc.

    Tuesday, May 10, 2016 7:48 AM
  • Maybe you're right. I just find the baseclasses code ... scary. Especially some of the comments and naming errors that are repeated over and over.

    E.g. CBaseRenderer has two critical sections, m_InterfaceLock and m_RendererLock. So far no problem. But when I see stuff like CAutoLock cRendererLock(&m_InterfaceLock); repeated over and over again... *shiver* That's a mistake that could have been fixed in like minutes. The naming doesn't affect the function of course, but it seriously scares and confuses the uninitiated reader.

    Or stuff like CBaseVideoRenderer::Notify where there's an explicit comment "We are NOT getting any locks here." (which is true), and then I see a plain write access to a just-as-plain variable. No volatile, no interlocked, no barriers, no nothing. Scary :)

    So when you say "2 decades of attention paid by programmers who care" - well ... maybe. But they certainly don't look it.

    Anyway, thanks for your answers. They helped to put my mind at ease. A little :)

    Tuesday, May 10, 2016 9:47 AM
  • BaseClasses are perhaps not perfect. And the source code could have been improved in many ways, including for example better support for exceptions, elimination of out-of-date COM base and use standard ATL, standard C++ library instead. Certain classes could be shipped as a part of API narrowing need of using BaseClasses for those who want to use top level API only without going too deep.

    Still BaseClasses remain relevant and they are what is backing DirectShow API components nowadays, and what is offered as a base for new DirectShow development.


    http://alax.info/blog/tag/directshow

    Tuesday, May 10, 2016 10:07 AM