A useable sample grabber. If you create your own video renderer (based on the sampvid video renderer), then you'll have problems getting it to work on a cross-OS basis. Alternatively, if you take the sample grabber alternative, you'll find yourself needlessly connecting pins.

Said in other words, the IMultimediaStream interfacew were great because they allowed to get you up to speed without having to first understand the ins and outs of pins which, as many people have said in many newsgroups, are not enough documented (especially when it comes to troubleshooting the connection with existing directshow filters).

Also of interest would be an easy activation of a tracing mode of internals media samples getting through the filters, even when you are in release mode. This would help a lot.

A set of interfaces that hide that you are hiding DirectShow filters or Windows media codecs as part of the rendering graph, especially in those situations where all you need is render your stuff.

A fixed graph editor (or the source code for it). A fixed graph editor would greatly help preparing your filters before you write the equivalent code. More often than not, your graph of filters will work, while the equivalent code won't, for non obvious reasons. Typical things that go hidden are the async clocks (audio, ...).

Bonus, generate code in the language of your choice from an existing graph, all within the graph editor. (of course, generating MSIL should be enough). This would give the box flow sequences a more "media orchestration" meaning.

Using GraphEdit, I'm building a graph that renders a Type-2 DV AVI out to the camera. During playback, I'd like to be able to seek the stream to any position. If I build this filter for a Type-1 DV AVI, I can seek using the drag-bar at the top of GraphEdit just fine:

Async File --> AVI Splitter --> Output Device

However, if I build this filter for Type-2 DV AVI, suddenly the drag bar is useless!

Async File --> AVI Splitter --> DV Mux --> Output Device

Apparently, DVMux's IMediaSeeking only supports CanPlayBackwards. Can you please extend the built-in DV Mux filter so it supports positioning via IMediaSeeking?! I don't see why it shouldn't...?

I use the DirectShow Editing Services (DES) API extensively, for a software project at a HUGE company.

I'm concerned it won't be supported in future releases of Microsoft operating systems. Is there any news on that?

How about making it work in the first place?

I searched with Google and found more than 10 posts in news groups, let alone websites concerning IMediaSeeking::SetPositions(), especially with AM_SEEKING_SeekToKeyFrame set. Everything seems to return S_OK yet the seek is done to the frame specified in pCurrent if AbsolutePositioning is set or not at all if not.

Yet, noone can shed any light on the issue. I would say that instead of adding features MS should sanitise DirectShow a little because many thngs including the one I just posted makes any sense, not according to the documents anyway. While i'm at it, the keyframe flag of ISample is rarely set correctly.

Some of this is indeed error of the codec/filter/whatever but this means that the knowledgebase is broken! The documents have insufficient information and the samples inconsistent. Some of them even use improper code. Does MS have a validation process for the documentation/samples? They should.

A frustrated programmer.

Does anybody know why in directshow editing services video playback
quality is so much degraded?

chad, where are you

PingBack from http://backyardshed.info/story.php?title=chad-gibson-s-weblog-how-do-you-use-directshow