16,472
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
shaolunyuan 2003-05-24
- 打赏
- 举报
This is not a typical filter example, because filters will normally derive from more specialized base classes than CUnknown. However, because all base filter classes eventually derive from CUnknown, this example demonstrates what is essential in a more generic manner. (The example is probably more typical for a DirectShow plug-in distributor (PID), which extends the functionality of the filter graph manager, or for a framework for implementing an arbitrary COM object.)
In this example, the NonDelegatingQueryInterface method is implemented. The more specialized filter base classes that derive from CUnknown are responsible for implementing NonDelegatingQueryInterface for the required interfaces; this is only necessary in the derived filter class if it adds some interfaces that are not in the base classes. In this case, it adds its own interface, IMyInterface.
INonDelegatingUnknown::NonDelegatingQueryInterface is a method that allows other objects to access interfaces on the COM object. All COM objects support IUnknown::QueryInterface to do this, and the DirectShow class library supplies the DECLARE_IUNKNOWN macro to enable the IUnknown interface. The DirectShow framework goes one step further and makes it easy to aggregate objects (make them part of a larger COM object) by implementing an INonDelegatingUnknown interface. Even if your object is not aggregated, it uses the INonDelegatingUnknown interface, which is mapped to the IUnknown interface by the base classes.
Although aggregation is handled for all objects by the DirectShow class framework, it is typically not used by filters in current DirectShow filter graphs. Plug-in distributors do, however, require aggregation (as is described later in this article), and future filter graphs might incorporate filter objects that are composed of collections of aggregated filters.
With this in mind, it might be helpful to explore more of the details of the previous example. First, a brief review of some COM basics might be helpful. COM objects are created by their class factories, are reference counted during their lifetimes, and self-destruct when their reference counts drop to zero. COM objects can be created in isolation, or can be aggregated with an already existing COM object. In this second case, the existing object (referred to as the outer object) maintains the reference count. The created object (referred to as the inner object) is not reference counted, but will be destroyed by the outer object during the destruction of the outer object. The application cannot directly manipulate COM objects; an application can only invoke the methods, which the object chooses to expose through its interfaces. Typically, COM objects make several interfaces available. All COM objects must support the IUnknown interface.
All classes using the DirectShow framework must inherit from CUnknown either directly (as in the previous example) or indirectly, through one of the other supplied base classes. CUnknown, with the DECLARE_IUNKNOWN macro and the NonDelegatingQueryInterface method, provide the IUnknown interface with the required reference counting and support for COM aggregation.
NonDelegatingQueryInterface is a method on INonDelegatingUnknown, which is supported by CUnknown. NonDelegatingQueryInterface is overridden in derived classes that support new interfaces, such as IMyInterface in the previous example. The method should check for all the interfaces known to be implemented on the object and return appropriate pointers to these interfaces. Requests for unrecognized interfaces should be passed to the NonDelegatingQueryInterface of CUnknown. The call to the GetInterface method (of CUnknown) copies the interface into the ppv parameter and ensures that the correct reference count is incremented.
The methods in INonDelegatingUnknown mirror those in IUnknown. For more information about CUnknown, the INonDelegatingUnknown interface, and the NonDelegatingQueryInterface method, see the CUnknown section in the reference material. INonDelegatingUnknown is defined in Combase.h; CUnknown is implemented in Combase.cpp.
When an instance of the class is required, the framework, using the information in the class factory template, calls the derived class's CreateInstance member function. The framework passes a pointer to an outer unknown (if the object will be part of an aggregate object) through the pUnkparameter, and passes a pointer to an HRESULT value through the phr parameter. The constructor of an inherited class can set this value if an error occurs. The phr parameter should not be initialized; this is the calling application's responsibility. The CreateInstance member function constructs an instance of the class by calling the constructor. The name passed to the constructor is wrapped with the NAME macro supplied by DirectShow. When building debugging versions, NAME passes the textual name on to the constructor. When building nondebugging versions, NAME results in a null pointer, thus saving space in versions that are not for debugging purposes.
The class constructor and destructor are declared protected. This prohibits the creation of the object using C++ language constructs. Instances of this class can be created only by calling the CreateInstance member function.
The class constructor needs to construct the inherited CUnknown. The pName parameter points to a string that is available for debugging purposes. It is vital that the string referenced by pName is in static storage, because the constructor for CUnknown will not copy it.
Reviewing the Instantiation Process
It might be helpful at this point to consider the normal process of instantiating a COM object, and examine how the DirectShow COM framework supports this process. First, a look at the entry points required of an in-process server DLL (such as a filter or plug-in distributor) is in order.
In-process server DLLs must export certain standard functions so that COM can interact with them. The DirectShow framework provides these functions for you. The module definition file for the DLL must list these functions in its EXPORTS section, and link to Strmbase.lib. The functions are: DllGetClassObject and DllCanUnloadNow. (The source code for these functions is supplied in Dllentry.cpp.)
A DirectShow object can define DLL entry points that facilitate the automatic registration of COM classes. These entry points are DllRegisterServer and DllUnregisterServer. Although the framework does not directly provide these entry points, it does provide a function, called AMovieDllRegisterServer2, that can implement these entry point functions. These functions take care of registering and unregistering all COM objects for which you have provided class factory templates in the g_Templates array. You can add a DllRegisterServer function to your module that simply calls AMovieDllRegisterServer2, or you could do the same for DllUnregisterServer. For more information on self-registering DirectShow COM objects, see Register DirectShow Objects.
Registry entries are required to link the class identifier (CLSID) of the COM object to the DLL in which the class is implemented. The framework provides entry points in the DLL that support the automatic registration of class identifiers in the registry, using the information provided in the class factory templates.
In this example, the NonDelegatingQueryInterface method is implemented. The more specialized filter base classes that derive from CUnknown are responsible for implementing NonDelegatingQueryInterface for the required interfaces; this is only necessary in the derived filter class if it adds some interfaces that are not in the base classes. In this case, it adds its own interface, IMyInterface.
INonDelegatingUnknown::NonDelegatingQueryInterface is a method that allows other objects to access interfaces on the COM object. All COM objects support IUnknown::QueryInterface to do this, and the DirectShow class library supplies the DECLARE_IUNKNOWN macro to enable the IUnknown interface. The DirectShow framework goes one step further and makes it easy to aggregate objects (make them part of a larger COM object) by implementing an INonDelegatingUnknown interface. Even if your object is not aggregated, it uses the INonDelegatingUnknown interface, which is mapped to the IUnknown interface by the base classes.
Although aggregation is handled for all objects by the DirectShow class framework, it is typically not used by filters in current DirectShow filter graphs. Plug-in distributors do, however, require aggregation (as is described later in this article), and future filter graphs might incorporate filter objects that are composed of collections of aggregated filters.
With this in mind, it might be helpful to explore more of the details of the previous example. First, a brief review of some COM basics might be helpful. COM objects are created by their class factories, are reference counted during their lifetimes, and self-destruct when their reference counts drop to zero. COM objects can be created in isolation, or can be aggregated with an already existing COM object. In this second case, the existing object (referred to as the outer object) maintains the reference count. The created object (referred to as the inner object) is not reference counted, but will be destroyed by the outer object during the destruction of the outer object. The application cannot directly manipulate COM objects; an application can only invoke the methods, which the object chooses to expose through its interfaces. Typically, COM objects make several interfaces available. All COM objects must support the IUnknown interface.
All classes using the DirectShow framework must inherit from CUnknown either directly (as in the previous example) or indirectly, through one of the other supplied base classes. CUnknown, with the DECLARE_IUNKNOWN macro and the NonDelegatingQueryInterface method, provide the IUnknown interface with the required reference counting and support for COM aggregation.
NonDelegatingQueryInterface is a method on INonDelegatingUnknown, which is supported by CUnknown. NonDelegatingQueryInterface is overridden in derived classes that support new interfaces, such as IMyInterface in the previous example. The method should check for all the interfaces known to be implemented on the object and return appropriate pointers to these interfaces. Requests for unrecognized interfaces should be passed to the NonDelegatingQueryInterface of CUnknown. The call to the GetInterface method (of CUnknown) copies the interface into the ppv parameter and ensures that the correct reference count is incremented.
The methods in INonDelegatingUnknown mirror those in IUnknown. For more information about CUnknown, the INonDelegatingUnknown interface, and the NonDelegatingQueryInterface method, see the CUnknown section in the reference material. INonDelegatingUnknown is defined in Combase.h; CUnknown is implemented in Combase.cpp.
When an instance of the class is required, the framework, using the information in the class factory template, calls the derived class's CreateInstance member function. The framework passes a pointer to an outer unknown (if the object will be part of an aggregate object) through the pUnkparameter, and passes a pointer to an HRESULT value through the phr parameter. The constructor of an inherited class can set this value if an error occurs. The phr parameter should not be initialized; this is the calling application's responsibility. The CreateInstance member function constructs an instance of the class by calling the constructor. The name passed to the constructor is wrapped with the NAME macro supplied by DirectShow. When building debugging versions, NAME passes the textual name on to the constructor. When building nondebugging versions, NAME results in a null pointer, thus saving space in versions that are not for debugging purposes.
The class constructor and destructor are declared protected. This prohibits the creation of the object using C++ language constructs. Instances of this class can be created only by calling the CreateInstance member function.
The class constructor needs to construct the inherited CUnknown. The pName parameter points to a string that is available for debugging purposes. It is vital that the string referenced by pName is in static storage, because the constructor for CUnknown will not copy it.
Reviewing the Instantiation Process
It might be helpful at this point to consider the normal process of instantiating a COM object, and examine how the DirectShow COM framework supports this process. First, a look at the entry points required of an in-process server DLL (such as a filter or plug-in distributor) is in order.
In-process server DLLs must export certain standard functions so that COM can interact with them. The DirectShow framework provides these functions for you. The module definition file for the DLL must list these functions in its EXPORTS section, and link to Strmbase.lib. The functions are: DllGetClassObject and DllCanUnloadNow. (The source code for these functions is supplied in Dllentry.cpp.)
A DirectShow object can define DLL entry points that facilitate the automatic registration of COM classes. These entry points are DllRegisterServer and DllUnregisterServer. Although the framework does not directly provide these entry points, it does provide a function, called AMovieDllRegisterServer2, that can implement these entry point functions. These functions take care of registering and unregistering all COM objects for which you have provided class factory templates in the g_Templates array. You can add a DllRegisterServer function to your module that simply calls AMovieDllRegisterServer2, or you could do the same for DllUnregisterServer. For more information on self-registering DirectShow COM objects, see Register DirectShow Objects.
Registry entries are required to link the class identifier (CLSID) of the COM object to the DLL in which the class is implemented. The framework provides entry points in the DLL that support the automatic registration of class identifiers in the registry, using the information provided in the class factory templates.
shaolunyuan 2003-05-24
- 打赏
- 举报
DirectShow and COM
Microsoft® DirectShow™ provides a framework that simplifies the creation of Component Object Model (COM) objects. This article describes this framework and most of what you need to know about COM to create a filter or plug-in distributor using the C++ class library. The article assumes the reader is familiar with C++. An understanding of COM would be helpful, but is not essential.
Contents of this article:
COM Objects in DirectShow
Reviewing the Instantiation Process
Creating Filters
Creating Plug-in Distributors
Implementing the Class Factory
Using an Object-Oriented Model
COM Objects in DirectShow
DirectShow filters, the filter graph manager, plug-in distributors, and enumerators are all COM objects. A general design has been adopted for the way in which DirectShow implements COM objects. This design is available to help you implement your own filters and plug-in distributors (or any COM object).
DirectShow components are supplied as in-process servers; that is, servers that run in the same address space as your application. They are packaged in a single dynamic-link library (DLL), Quartz.dll. Use the COM framework of DirectShow to build your own in-process COM servers, which you can package in your own DLL(s).
Typically, a single C++ class implements a single COM class. The DirectShow COM framework requires that C++ classes implementing COM objects conform to a few simple rules. One of these rules is that the developer provides a class factory template for each such class. The class factory template contains information about the class that is vital to the framework. Class factory templates are defined in the DLL using two global variables (g_Templates and g_cTemplates) as shown in the following example.
CFactoryTemplate g_Templates[]=
{ {L"My class name", &CLSID_MyClass, CMyClass::CreateInstance, CMyClass::Init},
{L"My class name2", &CLSID_MyClass2, CMyClass2::CreateInstance}
};
int g_cTemplates = sizeof(g_Templates)/sizeof(g_Templates[0]);
The names and types of these variables must be as they appear in the previous example. Because any DLL might contain several COM classes, each of which will require a class factory template, the factory templates are defined in an array and the number of elements in the array is recorded in another variable. Each element of the array contains the following fields.
A textual description of the class (using wide characters, therefore the "L" prefix).
A pointer to the class identifier of the class (CLSID).
A pointer to a static method of the class that can create instances of the class (CFactoryTemplate::CreateInstance).
A pointer to a static method of the class. This method is called when the DLL is loading or unloading and can perform one-time initialization and termination. If this method is not required, this can be omitted, will default to NULL, and will be ignored.
A pointer to an AMOVIESETUP_FILTER structure. This is required when using filter self-registration services.
The DirectShow COM framework uses the information in these class factory templates to create instances of the specific class, and to register and unregister the COM classes.
The following example demonstrates a simple C++ class implementing a COM class using the DirectShow framework.
class CMyClass : public IMyInterface, public CUnknown
{
private:
/* private attributes */
protected:
~CMyClass()
{ /* release private attributes */ }
CMyClass(TCHAR *pName, LPUNKNOWN pUnk, HRESULT *phr)
: CUnknown( pName, pUnk, phr )
{ /* set up private attributes */ }
public:
DECLARE_IUNKNOWN
static CUnknown *CreateInstance(LPUNKNOWN pUnk, HRESULT *phr)
{
CUnknown * result = 0;
result = new CMyClass( NAME("CMyClass"), pUnk, phr );
if ( !result ) *phr = E_OUTOFMEMORY;
return result;
}
STDMETHODIMP NonDelegatingQueryInterface(REFIID iid, void ** ppv)
{
if ( iid == IID_IMyInterface )
{
return GetInterface(static_cast<IMyInterface *>(this), ppv );
}
else
{
return CUnknown::NonDelegatingQueryInterface(iid, ppv);
}
}
/* My interface methods */
};
Microsoft® DirectShow™ provides a framework that simplifies the creation of Component Object Model (COM) objects. This article describes this framework and most of what you need to know about COM to create a filter or plug-in distributor using the C++ class library. The article assumes the reader is familiar with C++. An understanding of COM would be helpful, but is not essential.
Contents of this article:
COM Objects in DirectShow
Reviewing the Instantiation Process
Creating Filters
Creating Plug-in Distributors
Implementing the Class Factory
Using an Object-Oriented Model
COM Objects in DirectShow
DirectShow filters, the filter graph manager, plug-in distributors, and enumerators are all COM objects. A general design has been adopted for the way in which DirectShow implements COM objects. This design is available to help you implement your own filters and plug-in distributors (or any COM object).
DirectShow components are supplied as in-process servers; that is, servers that run in the same address space as your application. They are packaged in a single dynamic-link library (DLL), Quartz.dll. Use the COM framework of DirectShow to build your own in-process COM servers, which you can package in your own DLL(s).
Typically, a single C++ class implements a single COM class. The DirectShow COM framework requires that C++ classes implementing COM objects conform to a few simple rules. One of these rules is that the developer provides a class factory template for each such class. The class factory template contains information about the class that is vital to the framework. Class factory templates are defined in the DLL using two global variables (g_Templates and g_cTemplates) as shown in the following example.
CFactoryTemplate g_Templates[]=
{ {L"My class name", &CLSID_MyClass, CMyClass::CreateInstance, CMyClass::Init},
{L"My class name2", &CLSID_MyClass2, CMyClass2::CreateInstance}
};
int g_cTemplates = sizeof(g_Templates)/sizeof(g_Templates[0]);
The names and types of these variables must be as they appear in the previous example. Because any DLL might contain several COM classes, each of which will require a class factory template, the factory templates are defined in an array and the number of elements in the array is recorded in another variable. Each element of the array contains the following fields.
A textual description of the class (using wide characters, therefore the "L" prefix).
A pointer to the class identifier of the class (CLSID).
A pointer to a static method of the class that can create instances of the class (CFactoryTemplate::CreateInstance).
A pointer to a static method of the class. This method is called when the DLL is loading or unloading and can perform one-time initialization and termination. If this method is not required, this can be omitted, will default to NULL, and will be ignored.
A pointer to an AMOVIESETUP_FILTER structure. This is required when using filter self-registration services.
The DirectShow COM framework uses the information in these class factory templates to create instances of the specific class, and to register and unregister the COM classes.
The following example demonstrates a simple C++ class implementing a COM class using the DirectShow framework.
class CMyClass : public IMyInterface, public CUnknown
{
private:
/* private attributes */
protected:
~CMyClass()
{ /* release private attributes */ }
CMyClass(TCHAR *pName, LPUNKNOWN pUnk, HRESULT *phr)
: CUnknown( pName, pUnk, phr )
{ /* set up private attributes */ }
public:
DECLARE_IUNKNOWN
static CUnknown *CreateInstance(LPUNKNOWN pUnk, HRESULT *phr)
{
CUnknown * result = 0;
result = new CMyClass( NAME("CMyClass"), pUnk, phr );
if ( !result ) *phr = E_OUTOFMEMORY;
return result;
}
STDMETHODIMP NonDelegatingQueryInterface(REFIID iid, void ** ppv)
{
if ( iid == IID_IMyInterface )
{
return GetInterface(static_cast<IMyInterface *>(this), ppv );
}
else
{
return CUnknown::NonDelegatingQueryInterface(iid, ppv);
}
}
/* My interface methods */
};
shaolunyuan 2003-05-24
- 打赏
- 举报
D
[This is preliminary documentation and subject to change.]
Data Encryption Standard
(DES) A standard defined by the National Bureau of Standards for encryption of digital data transmissions within the United States.
data link layer
The second of the seven layers in the International Organization for Standardization's Open Systems Interconnection (OSI) model for standardizing computer-to-computer communications. The data link layer is one level above the physical layer. It is involved in packaging and addressing information and in controlling the flow of separate transmissions over communications lines. The data link layer is the lowest of the three layers (data link, network, and transport) that help move information from one device to another. See also transport layer.
data service
A mechanism provided by a service provider for sending broadcast data to broadcast clients. Such data can include Program Guide information, World Wide Web pages, software, and other digital information. The data service mechanism can be any broadcast process, including Internet channel broadcasting.
data stream
See stream.
datagram
One packet of information and associated delivery information, such as the destination address, that is routed through a packet-switching network. In a packet-switching network, data packets are routed independently of each other and may follow different routes and arrive in a different order from which they were sent. An Internet Protocol (IP) multicast packet is an example of a datagram.
dependency
A file that must be downloaded for an enhancement page to display properly, for example an image file in .gif format.
DBS
See direct broadcast satellite.
DES
See Data Encryption Standard.
DES decryptor
A hardware device that converts cipher text encrypted to the Data Encryption Standard (DES) back to plain text.
device
A unit of hardware, for example an audio adapter. For hardware used with the Microsoft® Windows® 98 operating system, such a unit can be detected by Plug and Play. See also device class, device driver, and device object.
device class
A group into which devices and buses are placed for the purposes of installing and managing device drivers and allocating resources. The hardware registry tree is organized by device class. Windows 98 uses class installers to install the drivers for the different classes of hardware.
device driver
A software component that allows an operating system to communicate with one or more specific hardware devices attached to a computer.
device object
A programming object used to represent a physical, logical, or virtual hardware device whose device driver has been loaded into the operating system.
direct broadcast satellite
(DBS) A satellite communications technology that allows use of a very small (18 inches to 3 feet in diameter) receiver dish packaged as a consumer electronics product, enabling consumers to directly receive satellite television signals.
DirectShow
The Microsoft® DirectShow™ (formerly Microsoft® ActiveMovie™) application programming interface (API) is a multimedia technology designed to play video, audio, and other multimedia streams in a variety of formats that are stored locally or acquired from Internet servers. DirectShow relies on a modular system of pluggable components called filters arranged in a configuration called a filter graph. A component called the filter graph manager oversees the connection of these filters and controls the data flow of the stream.
DirectShow filter
A Microsoft® DirectShow™ component that processes data streams. Each filter handles part of the operation involved in receiving, decoding, transforming, scheduling, and displaying interdependent video, audio, or other data streams. Filters connect to each other in a configuration called a filter graph.
A DirectShow filter is a user-mode entity that is an instance of a Component Object Model (COM) object, usually implemented by a dynamic-link library (DLL). A Broadcast Architecture DirectShow filter can be a source filter, a transform filter, a renderer filter, or a utility filter.
See also KSProxy filter.
DLL
See dynamic-link library.
downstream
One-way data flow from head end to broadcast client. See also upstream.
dynamic-link library
(DLL) A file with the file name extension .dll that contains one or more functions compiled, linked, and stored separately from the computing processes that use them.
[This is preliminary documentation and subject to change.]
Data Encryption Standard
(DES) A standard defined by the National Bureau of Standards for encryption of digital data transmissions within the United States.
data link layer
The second of the seven layers in the International Organization for Standardization's Open Systems Interconnection (OSI) model for standardizing computer-to-computer communications. The data link layer is one level above the physical layer. It is involved in packaging and addressing information and in controlling the flow of separate transmissions over communications lines. The data link layer is the lowest of the three layers (data link, network, and transport) that help move information from one device to another. See also transport layer.
data service
A mechanism provided by a service provider for sending broadcast data to broadcast clients. Such data can include Program Guide information, World Wide Web pages, software, and other digital information. The data service mechanism can be any broadcast process, including Internet channel broadcasting.
data stream
See stream.
datagram
One packet of information and associated delivery information, such as the destination address, that is routed through a packet-switching network. In a packet-switching network, data packets are routed independently of each other and may follow different routes and arrive in a different order from which they were sent. An Internet Protocol (IP) multicast packet is an example of a datagram.
dependency
A file that must be downloaded for an enhancement page to display properly, for example an image file in .gif format.
DBS
See direct broadcast satellite.
DES
See Data Encryption Standard.
DES decryptor
A hardware device that converts cipher text encrypted to the Data Encryption Standard (DES) back to plain text.
device
A unit of hardware, for example an audio adapter. For hardware used with the Microsoft® Windows® 98 operating system, such a unit can be detected by Plug and Play. See also device class, device driver, and device object.
device class
A group into which devices and buses are placed for the purposes of installing and managing device drivers and allocating resources. The hardware registry tree is organized by device class. Windows 98 uses class installers to install the drivers for the different classes of hardware.
device driver
A software component that allows an operating system to communicate with one or more specific hardware devices attached to a computer.
device object
A programming object used to represent a physical, logical, or virtual hardware device whose device driver has been loaded into the operating system.
direct broadcast satellite
(DBS) A satellite communications technology that allows use of a very small (18 inches to 3 feet in diameter) receiver dish packaged as a consumer electronics product, enabling consumers to directly receive satellite television signals.
DirectShow
The Microsoft® DirectShow™ (formerly Microsoft® ActiveMovie™) application programming interface (API) is a multimedia technology designed to play video, audio, and other multimedia streams in a variety of formats that are stored locally or acquired from Internet servers. DirectShow relies on a modular system of pluggable components called filters arranged in a configuration called a filter graph. A component called the filter graph manager oversees the connection of these filters and controls the data flow of the stream.
DirectShow filter
A Microsoft® DirectShow™ component that processes data streams. Each filter handles part of the operation involved in receiving, decoding, transforming, scheduling, and displaying interdependent video, audio, or other data streams. Filters connect to each other in a configuration called a filter graph.
A DirectShow filter is a user-mode entity that is an instance of a Component Object Model (COM) object, usually implemented by a dynamic-link library (DLL). A Broadcast Architecture DirectShow filter can be a source filter, a transform filter, a renderer filter, or a utility filter.
See also KSProxy filter.
DLL
See dynamic-link library.
downstream
One-way data flow from head end to broadcast client. See also upstream.
dynamic-link library
(DLL) A file with the file name extension .dll that contains one or more functions compiled, linked, and stored separately from the computing processes that use them.
u2m 2003-05-24
- 打赏
- 举报
http://www.csdn.net/develop/list_article.asp?bigclassid=2
不过是delphi的
不过是delphi的
