MPEG-4 was based heavily on H.263 for progressive-scan coding, and on MPEG-2 for support of interlace and color sampling formats other than 4:2:0. The features that support H.263 and MPEG-2 can be used to support MPEG-4. MPEG-4 can support a sample accuracy of more than 8 bits. Prioritize H.264/AVC 444 Graphics mode for Remote Desktop connections. When enabled on the RDP Server, the H.264/AVC 444 mode will be prioritized when the RDP 10 client and server both support AVC/H.264 and support the AVC 444 mode. Edit: I checked on my Windows 10 machine and there is a second option that needs to be enabled.
-->The IOCTL_AVC_CLASS I/O control code is supported only from kernel mode, using the IRP_MJ_INTERNAL_DEVICE_CONTROL dispatch.
Avc.sys supports two device interfaces, depending upon the type of instance (peer or virtual). These interfaces define the functionality that the driver exposes for subunit drivers, other drivers, and applications. During initialization, avc.sys calls IoRegisterDeviceInterface with either GUID_AVC_CLASS (a peer, or nonvirtual instance) or GUID_VIRTUAL_AVC_CLASS (a virtual instance), then uses IoSetDeviceInterfaceState as appropriate for the started or stopped state of the driver.
Peer instances of avc.sys register the device interface identified by GUID_AVC_CLASS. This interface supports one I/O control code, IOCTL_AVC_CLASS, which in turn supports multiple function codes. Child drivers of peer avc.sys instances are guaranteed to have access to this interface through their parent device object.
Avc Others Drivers Education
Virtual instances of avc.sys register the device interface identified by GUID_VIRTUAL_AVC_CLASS. This interface supports four I/O control codes:
IOCTL_AVC_CLASS
IOCTL_AVC_UPDATE_VIRTUAL_SUBUNIT_INFO
IOCTL_AVC_REMOVE_VIRTUAL_SUBUNIT_INFO
IOCTL_AVC_BUS_RESET
The GUID_AVC_CLASS interface supports all IOCTL_AVC_CLASS function codes, although some have limitation on their use. However, the GUID_VIRTUAL_AVC_CLASS interface does not support all IOCTL_AVC_CLASS function codes. The reference page for each individual function code specifies whether it is supported for GUID_VIRTUAL_AVC_CLASS instances of avc.sys.
The IOCTL_AVC_CLASS function codes (and any restrictions) are described in each function code. Drivers for desktop.
For more information about IRPs and IOCTLs, see Handling IRPs.
Major code
Input / Output buffer
Parameters->Others.Argument1 points to either an AVC_COMMAND_IRB structure or AVC_MULTIFUNC_IRB structure. Both structures contain an AVC_IRB structure as a header, as illustrated in the following example:
The AVC_IRB structure contains a single Function member. This member must be set to the desired function code from the AVC_FUNCTION enumeration.
Avc Others Driver Interview
The AVC_MULTIFUNC_IRB structure contains a union member that specifies the function I/O request block type-specific parameters for the function code. The parameters and their meanings are documented with each function code.
Parameters->Others.Argument1 points to the same AVC_COMMAND_IRB or AVC_MULTIFUNC_IRB structure that was passed as input. As part of completing the function, the subunit driver fills in certain submembers of the union within the structure with information for the driver. The returned information is documented with each request.
Status block
The information the AV/C protocol driver returns in the I/O Status Block (Irp->IoStatus.Status) is documented with each request.
Remarks
Most AV/C functions must be called IRQL = PASSIVE_LEVEL. A few may be called at IRQL <= DISPATCH_LEVEL. The respective IRQL is documented in each AV/C function.
Requirements
| Header | avc.h (include Avc.h) |
See also