Hi All,
Right, so what I've found now :
- if you implement KSPROPSETID_MediaSeeking on the driver (probably also any
OUTPUT pin), the ksproxy will send you any IMediaSeeking request, but not
pass it upstream to the rest of the filter chain.
- if you don't implement KSPROPSETID_MediaSeeking, the ksproxy will simply
pass any IMediaSeeking request upstream a la CPosPassThru.
My problem now is that seeing as I'm a WDM renderer, I want to know about
the seeking request but also let upstream filters (principally the source
filter) know about it so that it can handle get_Duration, issue flush
requests etc. What I've tried/ thought of:
- implementing a property set to handle seeking requests, but identified by
a different guid than KSPROPSETID_MediaSeeking. Then implementing a ksproxy
plugin and have that provide IMediaSeeking when it sees my property set guid
on the mini driver. I've tried this and it doesn't work, as the ksproxy must
recognise IMediaSeeking and just not let any plugin provide that interface
for it. Can't say I'm that surprised. As a confirmation, if I change the IID
that gets provided in response to my property set guid by just one byte, I
can see the non-delegating query interface coming my way, so I know it's
plumbed in ok.
- I thought of using the detours stuff from microsoft research web site. My
ksproxy plugin would then find IMediaSeeking on the ksproxy and hook it.
Unfortunately, I don't think this will work as you need to load the dll in a
particular way to safely hook things - so that other processes/threads won't
also get directed to your hook. It's also somewhat complicated by some
non-causal requirements where you need to load the ksproxy in a particular
way before it can aggregate you.
- is there any other way you can hook the outer IMediaSeeking for just this
instance? Thinking of maybe some clever v-table type thingy, but I'm not too
au-fait with layout of vtables in memory etc.
- (nasty) some kind of reverse calling mechanism whereby my ksproxy plugin
registers itself with the minidriver and allows the minidriver to call it to
pass the request upstream.
I'm sure none of this should be necessary, as there really ought to be some
standard MS-provided mechanism for getting the seeking request as well as
passing it upstream.
As ever, I'd be grateful for any help,
Matt
PS. MaxP, thanks for previous response. Sorry I didn't get back to you.
That's exactly what you need to do, but I figured that out before reading
your reply and forgot to check for answers. Thanks again.