Edit

Share via

Data Flow Using Isochronous Pipes

  • Article

USBCAMD2 begins streaming on the isochronous pipe by requesting two transfers of 32 packets. Each packet has a maximum size that corresponds to the maximum size in the selected alternate setting.

Note   Streaming on the isochronous pipe is independent of Microsoft DirectShow streaming.

Double-buffer isochronous transfer requests are continuously submitted to USBCAMD2 and stop only when one of the following two conditions occur:

  1. A stop DirectShow stream state is issued (KSSTATE_STOP).

  2. The camera minidriver requests USBCAMD2 to stop isochronous streaming by passing the USBCAMD_STOP_STREAMING flag in the PipeStateFlags parameter in a call to USBCAMD_SetIsoPipeState.

While streaming is in progress, USBCAMD2 and the camera minidriver repeat the following process until streaming stops:

  1. USBCAMD2 calls the camera minidriver's CamProcessUSBPacketEx callback function (at IRQL = DISPATCH_LEVEL) for every packet that USBCAMD2 receives from the USB bus driver. The camera minidriver must set the appropriate error flags in the case of error conditions. The minidriver must also set a new video frame flag if the beginning of a new video frame is detected using the FrameComplete parameter of CamProcessUSBPacketEx.

  2. After the camera minidriver has determined that a video frame is complete, USBCAMD2 calls the camera minidriver's CamProcessRawVideoFrameEx callback function (from the context of a worker thread) to process the video frame if there is a need to perform a color space conversion or decompression. USBCAMD2 returns a completed raw frame to the stream.sys class driver to be processed by the camera minidriver at IRQL = PASSIVE_LEVEL. If there is insufficient frame data or an error occurred during decompression due to bad data, for example, then the BytesReturned parameter to CamProcessRawVideoFrameEx must be set to 0.