Associating crossbars and video capture filters in AVStream

Discussion in 'Windows Vista Drivers' started by mukymuk, Jan 20, 2005.

  1. mukymuk

    mukymuk Guest


    We have a need to obtain the KSFILTER of a crossbar that is connected
    to the video capture input pin during AVStrMiniPinCreate(). I'm at a
    loss as to how this can be done.

    The reason we want to do this is that our hardware's crossbar
    characteristics don't fit into the AVStream definition well. We can
    have multiple, completely independent, crossbars implemented in the
    same hardware.

    At capture pin acquire time, we want to be able to navigate to the
    attached crossbar and query it's settings. This would give us the
    information we need to tell a particular crossbar instance on our
    hardware what it's inputs and outputs are without affecting currently
    running graphs.

    Perhaps there is a better way to solve our problem. Any advice is

    Breakout Software, Inc.
    mukymuk, Jan 20, 2005
    1. Advertisements

  2. mukymuk

    Max Paklin Guest

    Having pin handle you can get parent filter, from which you can get parent
    filter factory and eventually device. From which you can enumerate filter
    factories and for each filter factory enumerate its filters. This is the way
    for you to find an abitrary object in KS hierarchy.
    Check out KsPinGetParentFilter (or KsGetParent in general) and

    I can also suggest what I think more elegant way of achieving your goal.
    Have different crossbars supporting unique media instances. When connecting
    to a crossbar the inpu pin of your capture driver will receive pin medium as
    a part of its connection data. By examining that medium and checking out its
    instance data you will know what kind of crossbar you are being hooked up

    -- Max.
    Max Paklin, Jan 24, 2005
    1. Advertisements

  3. mukymuk

    mukymuk Guest

    Thanks for the response, Max.

    Navigating the hierarchy isn't the problem. Figuring out which one is
    connected to my capture filter is the problem. There's now way to know
    which crossbar instance is connected to your capture filter instance.

    Your second suggestion makes sense and I already went down that path.
    Unfortunately, you can't specify that your capture input pin supports
    more than one media type. I found that out by experiment and a
    co-worker found the fact buried in the DDK doc. If you try, nothing
    will connect. This is true of AVStream abstracted filters. I don't
    know if the same limitation holds true for user-mode capture filters.

    I'm considering creating a user-mode crossbar and seeing how that

    The fundamental problem, I think, is that DirectShow assumes and
    implicitly enforces (by design or accident, I don't know), that
    crossbars be singleton objects on a per-card basis. This is a problem
    because it is possible to have more than one client of the video
    hardware that gets abstracted by the crossbar. Each client needs to be
    able to specify a unique crossbar setting that then gets programmed to
    hardware at acquire time.

    mukymuk, Jan 28, 2005
  4. mukymuk

    Max Paklin Guest

    Navigating the hierarchy isn't the problem. Figuring out which one is
    This should be easy.
    Just get the pin you are connected to. Get parent filter out of that pin and
    browse KSFILTER context. Make sure that you have the same context base for
    all of your crossbar.
    Something like class CBaseXBar { GUID m_Id; }
    class CBar1 : public CBaseXBar {} etc.
    The you can cast KSFILTER::Context into CBaseXBar* and check m_Id to see
    what you are dealing with.

    Really? Can you point me to the docs? I'd be curious to know why...

    The idea of medium is more of a kernel mode thing.

    I see no reason for it to be considered a singleton.
    This problem has got to have a simple solution. Is the one that I gave at
    the beginning of this posting not good?

    -- Max.
    Max Paklin, Jan 29, 2005
  5. mukymuk

    mukymuk Guest

    I think you're making all the same assumptions I did initially. I
    agree that it should work the way you describe, but it doesn't. An
    AVStream crossbar filter doesn't have pins--at least no pins in the
    DirectShow sense. If you try to find out what pin your input capture
    pin is connected to, you'll get null if it's connected to a crossbar
    abstracted by AVStream/ If you load such a crossbar into
    KsStudio, you'll see that it has no pins. If you try to give it pins
    via a descriptor, AVStream simply ignores it. The psuedo-pins on a
    crossbar are specified by the properties of the crossbar filter, not by
    pin descriptors as with the capture filter.

    I didn't read the doc's myself, but according to my co-worker, it
    simply says you can't do it. No explanation. I didn't need the
    documentation to tell me that. I already knew it to be true.

    Right. I'm reaching, I know. I'm trying to use the mechanism for a
    purpose it wasn't desgned to support. That said, I haven't done
    anymore work in this area. It's still a possiblity.

    While you can instantiate multiple crossbar filters, by virtue of the
    fact that you can't know what crossbar you're connected to you have to
    simply pass property sets on to the hardware in a global fashion. That
    makes the properties of the crossbar global, which effectively makes
    the crossbar itself a singleton. I'm using the term "singleton" a bit
    loosely, but I think you can see my point.

    The crux of the problem is being able to navigate from the capture
    input pin to the output of the crossbar. If I can figure out a way to
    do that, then everything works as you would expect. That, or using
    some other mechaism to relate capture filters to crossbar filters in
    the context of an AVStream video capture driver.

    mukymuk, Feb 1, 2005
  6. mukymuk

    Max Paklin Guest

    via a descriptor, AVStream simply ignores it. The psuedo-pins on a
    Oh, yes I forgot about that.

    OK, so it is a limitation of current implementation.
    That's fine. I was curious if there could be a good reason for that, but it
    doesn't sound like that.

    Yes, you are right.

    I can suggest nothing but hacks.

    Let's say that you have a chance to expose some custom format on the output
    pin of your capture filter. Then you would be able to have a plugin for that
    type loaded during pin connection. That plugin would be a user mode thing
    and you could navigate the graph and figure out what xbar filter was
    instantiated and which one you are connected to. From that point on you
    could send some privae IOCTL to the device informing it of xbar type.

    Alternatively you could just expose a real filter (KSProxied) and have the
    plugin to implement IAMCrossbar. All that nonsense is doing
    nothing good, but getting in a way. This shouldn't be too difficult to
    implement, however you would end up implementing a plugin for an interface
    that you do not own (IAMCrossbar). This is a bit dangerous in general, but
    in this particular case I see no reason why there could be a conflict. No
    one in their right mind should be writing the plugin for IAMCrossbar unless
    it's a corner case like yours.

    -- Max.
    Max Paklin, Feb 3, 2005
  7. mukymuk

    Saxon Guest

    Hello Mukymuk,

    I too am facing the same crosbar "Singleton" dilemma. I was wondering if you
    had experienced any epihone's related to a solution. One thing that I was
    noticing was that the generic DirectShow property pages seem to be able to
    gain some knowledge about the crossbar connections, even though I could not
    enumerate them myself. Do you have any idea how DS obtains this knowlege of
    connections and whether we could mimic it to our benefit?

    Any help/update is appreciated.
    Saxon, Feb 14, 2005
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.