Re: more on wdm mediaseeking ...
From: Max Paklin (mpaklin_at_hotmail.com)
Date: 03/04/04
- Next message: Stephan Wolf: "Re: NDIS test failed on MiniportHalt"
- Previous message: Heba: "USB serial number"
- In reply to: Matt Vinall: "Re: more on wdm mediaseeking ..."
- Next in thread: Matt Vinall: "Re: more on wdm mediaseeking ..."
- Reply: Matt Vinall: "Re: more on wdm mediaseeking ..."
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 4 Mar 2004 12:07:55 -0800
May be I am wrong, but my understanding of any renderer functionality is
that it is supposed to play out frames coming its way based on presentation
time stamps.
If you don't want it to render frames, either don't send them or put
appropriate time stamps on them. Nothing else.
What you are trying to do, falls out of the picture and therefore is not
supported. It does not preclude you from doing what you want if you feel
that there is a good reason for that. However there is no easy way to
achieve your goal.
-- Max.
"Matt Vinall" <sorry.nospam@nospam.com> wrote in message
news:OTDDQUfAEHA.2448@TK2MSFTNGP12.phx.gbl...
> What I'm trying to do ...
>
> - have the renderer know about any current/ stop time updates so that it
can
> pause on the appropriate frame.
> - also pass the seek request upstream so that I can be sent a flush
request
> as required. If the seek point is before the current point, I'll need
> something to flush me - and the source filter will need to know to start
> sending data earlier from earlier in the source file.
>
> I don't think this is really that strange?
> Guess it's the reverse call scenario that wins.
>
> Thanks again.
> Matt
>
> "Max Paklin" <mpaklin@hotmail.com> wrote in message
> news:#xOtwFWAEHA.2660@TK2MSFTNGP10.phx.gbl...
> > I don't know what you are trying to do, but it looks quite strange to
me.
> I
> > think seeking interfaces are intentionally made in such a way that only
> one
> > filter in the graph is able to do seeking. How can you have two sources
> > (media) in the graph that can be seeked at the same time? I can imagine
no
> > reasonable usage scenario for that.
> >
> > As for getting done what you need to get done (whatever the reason is),
> you
> > can indeed write a plugin and have your minidriver to do a reverse call
> and
> > have plugin do upstream request propagation. This might look a bit
> > cumbersome, but it is clean (certainly not nasty) and much better than
any
> > vtable hooking.
> >
> > -- Max.
> >
> >
> >
> > "Matt Vinall" <sorry.nospam@nospam.com> wrote in message
> > news:uGIYvFQAEHA.580@TK2MSFTNGP11.phx.gbl...
> > > 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.
> > >
> > >
> >
> >
>
>
- Next message: Stephan Wolf: "Re: NDIS test failed on MiniportHalt"
- Previous message: Heba: "USB serial number"
- In reply to: Matt Vinall: "Re: more on wdm mediaseeking ..."
- Next in thread: Matt Vinall: "Re: more on wdm mediaseeking ..."
- Reply: Matt Vinall: "Re: more on wdm mediaseeking ..."
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
