Confusion about AVStream Properties

device driver

    Sponsored Links

    Next

  • 1. NDIS driver installation - problem
    Hi, I have used NDIS Filter Driver. I am trying to install it using INetCfg interface. The problem is with installation process. The installation process is very slow. Can you please tell me, Why this process is very slow? Is there any method to solve the problem? Is there any other way to install driver? Regards, SAM

Confusion about AVStream Properties

Postby Tim Roberts » Mon, 08 Nov 2004 13:25:48 GMT

I'm confused about the declaration of properties in an AVStream driver.
The samples and the documentation seem to contradict each other, as do the
code I've found through Google.

Let's take an example.  We're writing, among others, a TV tuner driver.
Looking in the Europa sample, in the analog tuner properties, we find,
among others:

  DEFINE_KSPROPERTY_ITEM
  (
    KSPROPERTY_TUNER_CAPS,
    AnlgTunerCapsGetHandler,
    sizeof(KSPROPERTY_TUNER_CAPS_S),
    sizeof(KSPROPERTY_TUNER_CAPS_S),
    NULL,
    NULL,
    0,
    NULL,
    NULL,
    0
  ),
  DEFINE_KSPROPERTY_ITEM
  (
    KSPROPERTY_TUNER_MODE_CAPS,
    AnlgTunerCapsGetHandler,
    sizeof(KSPROPERTY_TUNER_MODE_CAPS_S),
    sizeof(KSPROPERTY_TUNER_MODE_CAPS_S),
    NULL,
    NULL,
    0,
    NULL,
    NULL,
    0
  ),

Notice the two "sizeof" entries.  According to the documentation, the first
one is supposed to have the minimum size needed to identify the request.
The second one is supposed to have the size of the data being read and
written.  In both of these entries, BOTH sizes are set to the full
structure, which includes both the KSPROPERTY structure that identifies the
property, and the data to be read/written.  I'm conviced the sample is
wrong.  Further, if we look at the docuemntation for KSPROPERTY_TUNER_CAPS
and KSPROPERTY_TUNER_MODE_CAPS, in BOTH cases the return value is
documented as a single ULONG.

When we copy the structures above into our own AVStream analog tuner
driver, KSStudio fails to get the properties.  Single-stepping through the
code, I see that the upper-level drivers are returning
STATUS_BUFFER_TOO_SMALL.

We know that the analog parts of the Europa sample have never been tested,
so I have no reason to believe the code above is actually correct.
Further, I suspect from other property samples that the first size should
actually be sizeof(KSPROPERTY), and the second size should actually be
sizeof(ULONG).

Does anyone within the sound of my voice have a WORKING AVStream tuner
driver?  Can you share with me the definitions of your KSPROPERTY_ITEMS?
-- 
- Tim Roberts,  XXXX@XXXXX.COM 
  Providenza & Boekelheide, Inc

Re: Confusion about AVStream Properties

Postby Max Paklin » Tue, 09 Nov 2004 17:18:48 GMT

gt; DEFINE_KSPROPERTY_ITEM

This is exactly what I have in my working analog driver.
Works fine.



They aren't ULONGs in my DDK docs (Server 2003 DDK). Never been ULONGs.
Always been structures. Both of them, actually all of tuner/xbar properties
take structures.



I never used KSStudio on these drivers so I can't say whether it works or
not.



That's what the docs say, but on the same line they say "at least
sizeof(KSPROPERTY)". This is very confusing. First, they say this is the
minimal size of "property identifier", which I assume is KSPROPERTY. So it
should be sizeof(KSPROPERTY), period. At the same time they say "at least
sizeof(KSPROPERTY)". Go figure.

This is how I understand it.

Typical property handler takes an identifier (pKsIdentifier) and data
(pData).
NTSTATUS ProcessProperty( PIRP pIrp, PKSIDENTIFIER pKsIdentifier, PVOID
pData )

Frequently for both "get" and "set" handlers identifier is KSIDENTIFIER and
pData is the data value (ULONG, for example). This is usual case in BDA.
Sometimes (mostly for legacy cases) however they pass "the whole thing" as
an identifier (for your case it is KSPROPERTY_TUNER_MODE_CAPS_S) while pData
points to the value being set or where to put returned data (also
KSPROPERTY_TUNER_MODE_CAPS_S). Why? To support receive-modify-return cases.
Some of xbar properties fall under this category. There is no way the
property can be modified in-place so what they usually do is to copy
identifier to pData and then modify pData.

All of this is fairly contrived and less than obvious.

Documentation for particuar property is usually very specific what it passes
around as property descriptor and property value.
MS should've made it more straightforward - every property handler receives
KSIDENTIFIER, input buffer and output buffer. Period. Plain and simple. No
special cases. Nothing in KS is plain and simple unfortunately.

-- Max.



Re: Confusion about AVStream Properties

Postby Tim Roberts » Wed, 10 Nov 2004 14:52:30 GMT

Max Paklin" < XXXX@XXXXX.COM > wrote:


Yes, after a day of experimentation, I now believe the second sizeof is
correct, but the first one can be sizeof(KSPROPERTY) in all cases but
TUNER_MODE_CAPS, where the minimum is sizeof(KSPROPERTY)+size(ULONG).

Indeed, our tuner driver works fine in GraphEdt and AmCap, but Media Center
Edition 2005 will not recognize it. Has your analog driver ever been tried
in MCE?


Go look at stream.chm, and look in the index for KSPROPERTY_TUNER_MODE:

--- quote ---
KSPROPERTY_TUNER_MODE
User-mode clients use the KSPROPERTY_TUNER_MODE property to get or set the
tuning mode of a device, such as analog TV, digital TV, FM, AM, or DSS.
This property must be implemented.

Get Set Target Property descriptor type Property value type
Yes Yes Pin KSPROPERTY_TUNER_MODE_S ULONG
--- end quote ---

I now think that the "property value type" in that page is just nuts, but
there are so many ways to interpret the documentation that it's hard to
know exactly what is right. I do know that KSPROPERTY_TUNER_MODE works
properly if:
* the tuner driver has
sizeof(KSPROPERTY),
sizeof(KSPROPERTY_TUNER_MODE_S),
and
* the calling application passes NULL for instance data, and a
KSPROPERTY_TUNER_MODE_S for the property data.


The big problem is that none of the documentation pages use the same
terminology. It's almost like a {*filter*}. The pages for the individual
properties use the terms "property descriptor type" and "property value
type". If you look at the description of KSPROPERTY_ITEM, we're supposed
to define the minimum size for the "property identifier", and the minimum
size for the "data". Where did the term "property identifier" come from?
Is that the same as "property descriptor"? Is the "data" supposed to
include the KSPROPERTY? Some do, some don't.

Even worse, go look at IKsPropertySet::Get. The user-mode app is supposed
to pass in InstanceData and PropertyData. Where did the term
"InstanceData" come from? How does it relate to "property descriptor type"
and "property identifier"? Why should it be so hard?

After disassembling, I now know a little bit more about it. The user-mode
app's InstanceData is all of the INPUT fields beyond the KSPROPERTY.
Unfortunately, the documentation does not tell us what those fields are.
For all of the tuner properties except TUNER_MODE_CAPS, the driver's
"property identifier" is a KSPROPERTY, and the user-mode app can specify
NULL for the InstanceData. For TUNER_MODE_CAPS, the minimum "property
identifoer" in the driver is a KSPROPERTY plus a ULONG, so the user-mode
app can specif just a ULONG.

It's boneheaded that it has to be this complicated. There are a certain
number of common and well-defined use cases. Those use cases should be
deterministic and well documented.
--
- Tim Roberts, XXXX@XXXXX.COM
Providenza & Boekelheide, Inc

Re: Confusion about AVStream Properties

Postby Max Paklin » Thu, 11 Nov 2004 04:38:50 GMT

> Yes, after a day of experimentation, I now believe the second sizeof is

No, this is test driver, which we never shipped to anyone.
Your analog driver supports MPEG2 encoding, doesn't it? Aside from the right 
property sets support there is a number of things that you have to implement 
to keep MCE happy. And no, I don't have the list in my head as I've never 
done analog receiver driver for MCE.



I just did. Wow!
Astonishing.
I may be mistaken, but I think the docs are plain wrong. I've always been 
passing structures around for the input and mode and it always worked that 
way. Maybe I've been lucky all the time?



It shouldn't.
Different pieces were written by completely different people at different 
point. This is bad.



I agree.
For myself I learned the hard way (or through friends on site) what needs to 
be done when, wrote the code that works and never touched the subject ever 
again. I just do a copy-paste when needed without giving it much thought.
Every time I start thinking about it I get a headache.

-- Max.



RE: Confusion about AVStream Properties

Postby aHVlbmdwZWk » Mon, 31 Jan 2005 00:23:02 GMT

Dear All:

I have met a same situation for another property 
KSPROPERTY_VIDEOCONTROL_FRAME_RATES in the AVStream driver.
I need support mulitple different framerates for one video stream.
In a traditional Streaming Minidriver, we can set the 
NumberOfBytesToTransfer member of the SRB structure to the size of returned 
buffer.
However, in the AVStream, I can not access SRB.
I don't know how to return the size information to user-mode application.

Who can give me some suggetions?
Can I get the SRB of the KSPROPERTY_VIDEOCONTROL_FRAME_RATES property?





RE: Confusion about AVStream Properties

Postby aHVlbmdwZWk » Mon, 31 Jan 2005 00:23:02 GMT

Dear All:

I have met a same situation for another property 
KSPROPERTY_VIDEOCONTROL_FRAME_RATES in the AVStream driver.
I need support mulitple different framerates for one video stream.
In a traditional Streaming Minidriver, we can set the 
NumberOfBytesToTransfer member of the SRB structure to the size of returned 
buffer.
However, in the AVStream, I can not access SRB.
I don't know how to return the size information to user-mode application.

Who can give me some suggetions?
Can I get the SRB of the KSPROPERTY_VIDEOCONTROL_FRAME_RATES property?






Similar Threads:

1.Custom property interface for AVStream driver

2.AVStream: Get/SetHandler for KS Properties

Simple question: Does ks.sys provide synchronization
for KsPropertyHandler's, i.e. can I consider that,
say SetBrightnessPropertyHandler for the same filter
object couldn't be called simultaneously?


3.custom property set for AVSTREAM minidriver

Is it possible to add a custom property set in a AVSTREAM minidriver at
the KSDEVICE level ?
I know it is possible at the KSFILTER level using KSAUTOMATION_TABLE in
the KSFILTER_DESCRIPTOR. But the custom property I intend to add is not
related to any filter provided in the minidriver...Therefore I would
like to add it at the device level.

Thanks for your help.
Francois.

4.Node properties in AVStream

Hello, All.

In AVStream documentation I have found that nodes in AVStream minidrivers
can support properties. Handlers of properties can be declared in the node's
automation table. But I can't to find a way to get access to node's 
properties
from user-mode clients. I can to get node's category, type, but I can't to
get some object (file handle or COM) to control propery. Please point me
a correct way to do it.

PS
I want to implement the same property on filter and on one of filter nodes.
Does it is possible?

Andrey 


5.AVStream: Custom properties not available in Graphedit

Hi All,


I have implemented a HW Encoder filter.

Everything works well but, I have listed support for 20-30 custom 
property items. Are these Items expected to show up in graphedit when I 
right click on the filter and select Properties? I don't believe so.

With software filters, the filter writer has to add property pages to 
the filter in order to access the SW filter properties thru GraphEdit.

If they should be present by selecting Properties, how do I display 
these? What am I missing?

Thanks

6. Removing standard property page from Printer properties UI

7. Removing standard Unidrv property sheets from printer preferences/properties

8. Need to add a pin property/Filter property page to my BDA driver



Return to device driver

 

Who is online

Users browsing this forum: No registered users and 2 guest