Define Automation Table for AVstream Dynamically

I am writing and AVstream mini driver. I defined the automation table with
the descriptor and the dataRange that specify what formats are supported,
Resolution and FPS.
defining it statically works ok.
however I need to do some run time checks in order to be able to determine
the format and resolution and FPS.

i’m not sure I fully understand the automation table so will appreciate
some explanation about how does it work? and the load order.
at the end all defined structs are used by
//
// CaptureFilterDescriptor:
//
// The filter descriptor for the capture device.
DEFINE_KSFILTER_DESCRIPTOR_TABLE (FilterDescriptors) {
&CaptureFilterDescriptor
};

so is it possible to call this define after driverEntry? if yes what is the
correct way/ time to do so

NtDev mm wrote:

I am writing and AVstream mini driver. I defined the automation table
with the descriptor and the dataRange that specify what formats are
supported, Resolution and FPS.
defining it statically works ok.
however I need to do some run time checks in order to be able to
determine the format and resolution and FPS.

i’m not sure I fully understand the automation table so will
appreciate some explanation about how does it work? and the load order.

The answer is complicated, because AVStream is an extremely flexible
architecture.

The descriptor tables you create get passed to KsCreateFilterFactory.
In the sample drivers, the tables are all defined as const structs, so
they are static data structures. However, there is nothing to stop you
from building all of that on the fly before you call
KsCreateFilterFactory. The KsEdit facility is designed to assist in
that. I have one AVStream driver that drives about 15 different camera
models with different resolution tables; I just build the pin
descriptors on the fly before calling KsCreateFilterFactory.

However, depending on circumstances, you may not even need that much.
The descriptors describe everything your camera could ever do, under any
circumstances. The framework will then call your DataIntersect handler
to figure out which of those formats you can do right now, and finally
the SetFormat handler to figure out how to tweak that format for the
current conditions. So, if you have a situation where you support 16
different formats, but only 4 at any given time, you can put all 16 in
the descriptors, and winnow out the successes during the callbacks.

It’s also possible to create a filter factory with no pins, then call
KsFilterCreatePinFactory later on. I’ve never done that.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.