DirectShow is a second class citizen in DirectX 9.0c, what gives???
Howard Swope
forward to all kinds of improvents to add to my video application, but there
have been no improvements. In fact, features have been removed. There is now
no debugging support for DirectShow and the documentation doesn't integrate
with VisualStudio. I do a search for any DirectShow information and all I
get is the WindowsCE DirectShow reference.
What's going on? Is the application I spent so much time working on a
dinosaur now? Is DirectShow disappearing? Is there an alternative technology
for working with video under windows that I should be exploring?
I'm feeling like a second class citizen :-(
--
Howard Swope [howardsnewsATspitzincDOTcom]
Software Engineer
Spitz, Inc [http://www.spitzinc.com]
rod
but they didn't even bother updating it so we can use it with Csharp.
and thats disapointing
Grant
next version of DirectX (DirectX X or DirectX Next) that is to be released
with Longhorn.
DirectShow could never quite get their release schedules to coincide well
with Direct3D which ran on a hyper schedule. So it always lagged behind, for
example using dead DirectDraw interfaces in DX8. And the documentation for
DirectShow has never been too teribly helpful for developers.
What will replace DirectShow hasn't been made clear, if it will be subsumed
in the Platform SDK or there will be a new attempt to integrate with DirectX
or it'll take a completely separate road?
Mark Raishbrook
"Chris P. [MVP]" <ms...@chrisnet.net> wrote in message
news:OOnqtUz...@TK2MSFTNGP11.phx.gbl...
> Grant wrote:
>> I've heard rumors there will be no component known as "DirectShow"
>> in
>> the next version of DirectX (DirectX X or DirectX Next) that is to
>> be
>> released with Longhorn.
>>
>> DirectShow could never quite get their release schedules to
>> coincide
>> well with Direct3D which ran on a hyper schedule. So it always
>> lagged behind, for example using dead DirectDraw interfaces in DX8.
>> And the documentation for DirectShow has never been too teribly
>> helpful for developers.
>>
>> What will replace DirectShow hasn't been made clear, if it will be
>> subsumed in the Platform SDK or there will be a new attempt to
>> integrate with DirectX or it'll take a completely separate road?
>
> DirectShow will exist in Longhorn, there is just far too many apps
> that
> would break if it was removed. I can't comment on anything new at
> the
> moment.
>
> Now is the time to voice your DirectShow opinions so we can take it
> up with
> Microsoft.
>
>
Chuck Walbourn
the DirectX SDK will focus more on games, which DirectShow has mixed success
in supporting, and in part because it is considered more a 'core OS'
component and not part of the Windows Gaming & Graphics team focus. Where
it will end up isn't clear at this moment, but this is why the docs were
separated from the rest of the DirectX documentation in the DX 9.0 Summer
Update 2004 SDK and why in the next release of the DirectX SDK the libs,
headers, and samples will reside in the Extras folder.
DirectMusic and DirectPlay are considered legacy OS components, which is why
they were removed from the DirectX documentation. They will eventually be
moved out of the DirectX SDK as well.
-Chuck Walbourn
SDE, Windows Gaming & Graphics
Martin Danielsson
> the DirectX SDK will focus more on games, which DirectShow has mixed
> success in supporting, and in part because it is considered more a 'core
> OS' component and not part of the Windows Gaming & Graphics team focus.
> Where it will end up isn't clear at this moment, but this is why the docs
> were separated from the rest of the DirectX documentation in the DX 9.0
> Summer Update 2004 SDK and why in the next release of the DirectX SDK the
> libs, headers, and samples will reside in the Extras folder.
But you're not saying that DirectShow is probably being phased out, are you?
That would be horrible! How are you supposed to write stable application
which use Microsoft-standards if they don't remain standards for more than
two or three years? As an example, I wrote an application for the VfW
interface, just before it was deprecated. Super. That forced me into
DirectShow, which, admittedly, was much better than VfW (but a lot harder),
and, after a couple of years, the app runs stable now, you're telling me,
oh, well, that's not what you should use, use the entirely different
SuperMedia(tm) API, which only, oh sorry, supports C# (worst case), while my
application is entirely in C++.
Sorry for being a little bit cynical, and I hope the above is a
worse-than-worst-case scenario... :-) I wouldn't really look forward to
supporting a third video capturing "standard".
> DirectMusic and DirectPlay are considered legacy OS components, which is
> why they were removed from the DirectX documentation. They will
> eventually be moved out of the DirectX SDK as well.
> -Chuck Walbourn
> SDE, Windows Gaming & Graphics
Frustrated,
Martin
Amit
I come from the graphics background( writing graphics drivers) and
especially Video drivers in the graphics world.
I know the Video(display and processing) API( like DxVA, DDraw etc etc) has
been moved into the user mode level D3D component. So there seems to be a
merge with D3D.
But, how is it that DirectShow will be replaced ? I am still dont understand
considering that only DShow based applications can do processing specific to
Video. Is everything being re-written under the DirectX( Direct3D cxomponent)
to merge all this together ? What about the DirectShow base that has been
there for all this time ?
Is there any document that explains how this will be done ?
Thanks.
Chuck Walbourn
> you?
I'm trying to say that DirectShow is being phased out as a gaming video
solution, hence why it seems like a 'second class citizen' on the DirectX
SDK. As a gaming video solution, DirectShow leaves a lot to be desired. It
continues to exist as a more general video media solution on current
Microsoft OSes, and the SDK portion of it will move somewhere else in the
near future.
I do not believe there has been any public information made available about
plans for video media on future Microsoft operating systems.
Chris P. [MVP]
> Sorry to bug you, but I am a bit confused after reading all the
> messages.
> I come from the graphics background( writing graphics drivers) and
> especially Video drivers in the graphics world.
> I know the Video(display and processing) API( like DxVA, DDraw etc
> etc) has been moved into the user mode level D3D component. So there
> seems to be a merge with D3D.
>
> But, how is it that DirectShow will be replaced ? I am still dont
> understand considering that only DShow based applications can do
> processing specific to Video. Is everything being re-written under
> the DirectX( Direct3D cxomponent) to merge all this together ? What
> about the DirectShow base that has been there for all this time ?
>
> Is there any document that explains how this will be done ?
From the gaming perspective? I'll let Chuck answer that.
From the general perspective DirectShow right now is simply being moved to
it's own SDK. For DirectShow developers this is actually a good thing.
Tim Roberts
>
>But you're not saying that DirectShow is probably being phased out, are you?
>That would be horrible! How are you supposed to write stable application
>which use Microsoft-standards if they don't remain standards for more than
>two or three years?
I'm not sure where that came from. DirectShow was originally written in
1995; you can see that in the sample sources. Thus, it was born at
approximately the same time as Windows 95.
However, I have to say that DirectShow is perhaps the best-designed
software subsystem I've ever come across. We can argue about
implementation, but the concept -- the mental model -- is exactly right for
its target application space. The whole filter graph thing, the format
negotiation, the filter/pin separation, property pages, the well-defined
state management; it all provides an incredible flexibility that has uses
well beyond the multimedia market where it is targetted.
I spend a lot of time making fun of Microsoft, but I have to tip my hat in
respect to the folks who created DirectShow. I cannot imagine it will go
anywhere for a while.
--
- Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc
Swen Gerards
I totally agree with Martin!
I have been developing an application that is based on directx. I make use
of the fact that directshow is a part of the directx sdk. Its more than
shortsiighted from microsoft to carve the video support out of the dirctex
sdk. Same goes for the directplay stuff. Does microsoft really thing
people only use directx to programm games??? I mean having a tool at your
hand with which you can do lots of stuff if you are creativ enough, why on
earth should you want to break features of the directx tool? I was hoping
that further directx version even enhance interfaces between the directx
graphics and directshow video part. Just take a look at all those gaming
consoles and their useage of videos and cameras for god sake! They are
using cameras as input devices. With directshow you can do that as well.
Being creative with less and less resources is getting pretty hard.
also very frustated coder,
Swen
--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
Chuck Walbourn
> of the fact that directshow is a part of the directx sdk. Its more than
> shortsiighted from microsoft to carve the video support out of the dirctex
> sdk. Same goes for the directplay stuff. Does microsoft really thing
> people only use directx to programm games???
As I said, it is viewed as an OS component, not something game-specific.
The DirectX SDK has always been primarily targeted at game developers in
terms of audience, samples, documentation, etc. That doesn't mean it is
becoming unavailable, simply that it is on the way out of the DirectX SDK
into some other SDK distribution. Hence, why it appears as a 'second class
citizen' in the DX SDK.
As for DirectPlay, much of the infrastructure it provides was to support a
variety of networking solutions before TCP/IP became ubiquitous:
head-to-head serial, modem, IPX, etc. While there are aspects of
DirectPlay's implementation that still provide value even in a pure TCP/IP
environment, there are a number of security concerns around building
applications with it. Therefore this API has been moved to 'sustained
engineering' status to support application compatibility, but is not
recommended for continued development.
The reasoning behind these decisions may not be obvious or well
communicated, but is a lot of thought that goes into them before they are
made.
Swen Gerards
wrote:
>> I have been developing an application that is based on directx. I make
>> use
>> of the fact that directshow is a part of the directx sdk. Its more than
>> shortsiighted from microsoft to carve the video support out of the
>> dirctex
>> sdk. Same goes for the directplay stuff. Does microsoft really thing
>> people only use directx to programm games???
>
> As I said, it is viewed as an OS component, not something game-specific.
> The DirectX SDK has always been primarily targeted at game developers in
> terms of audience, samples, documentation, etc. That doesn't mean it is
> becoming unavailable, simply that it is on the way out of the DirectX SDK
> into some other SDK distribution.
What about the interfac es between d3d and directshow? I mean there are
certain things where i would say right now there is room for improvement.
My fear is that in the future d3d and directshow might drift further
apart, making it harder to integrate both seamless.
> Hence, why it appears as a 'second class
> citizen' in the DX SDK.
>
> As for DirectPlay, much of the infrastructure it provides was to support
> a
> variety of networking solutions before TCP/IP became ubiquitous:
> head-to-head serial, modem, IPX, etc. While there are aspects of
> DirectPlay's implementation that still provide value even in a pure
> TCP/IP
> environment, there are a number of security concerns around building
> applications with it. Therefore this API has been moved to 'sustained
> engineering' status to support application compatibility, but is not
> recommended for continued development.
Good to know =8)!
>
> The reasoning behind these decisions may not be obvious or well
> communicated, but is a lot of thought that goes into them before they are
> made.
I don not doubt that enough people tortured their brains towards the
future of the difdferent components of the directx sdk. My concerns are
only that when separating stuff, things might wonder into different
directions and it will become harder to build applications from those
different parts. Perhaps i should just provide this bit of information:
when i had to decide which plattform i use for my application, i
considered directx the better choice over OpenGL, cause it looked like
directx being the sdk with the most features at hand. Thats why i wince
every time i hear there are parts of directx taken out of the sdk and been
put into other sdks...
>
> -Chuck Walbourn
> SDE, Windows Gaming & Graphics
>
>
--
Richard Albury
> [...]
>
> As for DirectPlay, much of the infrastructure it provides was to support a
> variety of networking solutions before TCP/IP became ubiquitous:
> head-to-head serial, modem, IPX, etc. While there are aspects of
> DirectPlay's implementation that still provide value even in a pure TCP/IP
> environment, there are a number of security concerns around building
> applications with it. Therefore this API has been moved to 'sustained
> engineering' status to support application compatibility, but is not
> recommended for continued development.
>
> The reasoning behind these decisions may not be obvious or well
> communicated, but is a lot of thought that goes into them before they are
> made.
Thanks for the explanation, Chuck.
Umm, since I obviously missed the memo: when *was* this decision made
and how was it communicated? I'm on the DirectX AV mailing list and I
don't recall seeing anything there...
Thanks,
Richard
Iain
> Umm, since I obviously missed the memo: when *was* this decision made
> and how was it communicated? I'm on the DirectX AV mailing list and I
> don't recall seeing anything there...
Richard, this is all pretty new stuff. I believe that we will be hearing a
more formal exposition of this from the Direct Show guys in the near
future.
But I think we forget that MS is a big company and some aspects move in a
big company way. Like slow.
Iain
Chuck Walbourn [MSFT]
is taking place over several releases. Until there is a firm plan for where
they will end up, we don't have a complete message to communicate publicly
at this time. Hence why you haven't heard much about it.
I'm mainly trying to make clear as to why it appears to be a 'second class
citizen' , which is not in fact true.
--
-Chuck Walbourn
SDE, Windows Gaming & Graphics
This posting is provided "AS IS" with no warranties, and confers no rights.
Jeremy Noring
> it's own SDK. For DirectShow developers this is actually a good thing.
I would welcome such a change, honestly. It really doesn't belong in the
DXSDK. I'd also like to see the entire architecture rethought, revamped,
and redone. A lot of it is pretty good, and a lot of it is really, REALLY
bad. Additional samples, increased WMF support, better integration with
.NET and c# would also be my top requests. Although DShow certainly isn't
bad (and the theory behind it is sound, IMO), the realistic implementation
of it needs a bit of fine tuning.
One thing that's been bugging me lately: what does COM actually do for
DShow? Why do we have a binary standard implemented in our video rendering
sdk? Does that seem a bit weird to anyone else, or am I just entirely off
the beaten path here? To me, COM is just a PITA and dealing with its
complexity is more of a chore than a benefit.
--
Where am I going?
And why am I in this handbasket?
Gabest
> DShow? Why do we have a binary standard implemented in our video
> rendering sdk? Does that seem a bit weird to anyone else, or am I just
> entirely off the beaten path here? To me, COM is just a PITA and dealing
> with its complexity is more of a chore than a benefit.
Not counting the few out-of-proc accessable interface, directshow is purely
in-proc. Which means COM is just cheap way to get rid of memory managment
(used together with CCom(QI)Ptr) in your app. Personally, I really like it.
And I had to learn it not knowing anything about COM. CLSIDs, filter/object
creation and media type association stuff could be replaced with a new
registration format stored in a registry or file or anywhere making dshow
more portable (portable to another OS after recompilation), but why reinvent
the wheel again.
Tim Roberts
>
>One thing that's been bugging me lately: what does COM actually do for
>DShow? Why do we have a binary standard implemented in our video rendering
>sdk? Does that seem a bit weird to anyone else, or am I just entirely off
>the beaten path here? To me, COM is just a PITA and dealing with its
>complexity is more of a chore than a benefit.
What are the alternatives? It could have been made a simple C++ class
library, I suppose, but the usage wouldn't be significantly different from
the COM structure we have now. You'd still want to use virtual functions
so the apps didn't worry about the filter implementations. You'd still
need some central directory for looking up the appropriate filters. If
you're going to invent all of that, you might as well use COM.
apdotnet
I am trying to add video support for a CSharp Win Forms 2.0 app, with
DirectShow moving to a new SDK how do I prepare for this? Should I just
code using the old directshow in C++ was or will there me a managed
DirectShow CLR assemply along with documentation that I can get a jumpstart
on?
Does this mean the managed DirectX will not include DirectShow?
Please explain how I should progress on adding video support to my CSharp
Winforms 2.0 app. Many thanks in advance.
Thore Karlsen [MVP DX]
<apdo...@discussions.microsoft.com> wrote:
>After catching up on this - I need advice.
>
>I am trying to add video support for a CSharp Win Forms 2.0 app, with
>DirectShow moving to a new SDK how do I prepare for this? Should I just
>code using the old directshow in C++ was or will there me a managed
>DirectShow CLR assemply along with documentation that I can get a jumpstart
>on?
I have heard of no plans to support DirectShow in managed languages. In
fact Microsoft has the following statement in the DirectX 9.0c docs:
----------
Will DirectShow ever be accessible through managed code?
There are no current plans to implement a "Managed DirectShow" platform.
The DirectX SDK does provide limited managed playback functionality
through the Audio Video Playback class. You can use COM interop to
create DirectShow client applications in managed code, but creating
filters that depend on the Common Language Runtime (CLR) is not
recommended for performance reasons.
----------
>Does this mean the managed DirectX will not include DirectShow?
Yep.
>Please explain how I should progress on adding video support to my CSharp
>Winforms 2.0 app. Many thanks in advance.
Your best bet is to do the little you can in C# directly, and use C++
for any real DirectShow work. I wouldn't hold my breath hoping for this
situation to change any time soon.
--
New to newsgroups? Read: http://dev.6581.com/newsgroups.html
The March Hare [MVP]
> I am trying to add video support for a CSharp Win Forms 2.0 app, with
> DirectShow moving to a new SDK how do I prepare for this? Should I just
> code using the old directshow in C++ was or will there me a managed
> DirectShow CLR assemply along with documentation that I can get a jumpstart
> on?
> Does this mean the managed DirectX will not include DirectShow?
Besides the AudioVideoPlayback object there are no plans, AFAIK, of managed
dshow capability.
> Please explain how I should progress on adding video support to my CSharp
> Winforms 2.0 app. Many thanks in advance.
One way I have heard here is through COM interop.
--
Please read this before replying:
1. Learn about newsgroups - http://dev.6581.com/newsgroups.html
2. Trim & respond in-line (please don't top post or snip everything)
3. Benefit others - follow up if you are helped or you found a solution
dlb
and the discussion following this blog post -
http://blogs.msdn.com/ericgu/archive/2004/09/20/232027.aspx
I think that Thore's approach is probably the most robust - implement in
managed C++, avoid interop w/ C#.
In this way, your component can present a clean managed interface to the
.NET environment.
Mike Thompson
I've been writing video capture and review applications since the bad
old days of VfW. I'm personally very impressed with the DirectShow
implementation, and would encourage Microsoft to continue developing
it. I've been very confused as to the direction the future is taking,
with DirectShow taking a back seat to the under featured Windows Media
SDK's.
After reading everyone's post on this subject at least I feel I
understand what's happening a bit better now.
Thanks
Mike