This section describes additional restrictions to the FullVideo Supreme JPEG option module.

B.1.5.1 FullVideo Supreme JPEG Memory Usage

Buffers or regions of memory passed to FullVideo Supreme JPEG devices can only be registered once. For instance, the compression buffer from an analog video capture ( videoStreamAddBuffer ) cannot be used as the input buffer for decompression ( ICDecompress ). X image output buffers cannot be used as compression buffers for other operations.

Since the FullVideo Supreme JPEG option shares a command queue with low-level software and the details of the low-level management are difficult to map to the high-level multi-application environment, it is almost impossible to guarantee from the low level that no buffer will be used for two operations concurrently or while data is stale. The FullVideo Supreme JPEG device software also makes the restriction that a particular buffer may only appear once in the system at any given time.

In short, use separate buffers for each type of operation ( videoStreamAddBuffer , ICDecompress , ICCompress ) and for each type of buffer (input, output, compress, uncompress). If data needs to be passed from one operation to another, the application must copy the data.

B.1.5.2 FullVideo Supreme JPEG Image Size

The sizes of images are restricted as follows:

For all standards:

• For dual-buffer capture, the height and width of the JPEG_DIB or MJPG_DIB image will be used for both images.
• The width of a JPEG_DIB or MJPG_DIB image must be a multiple of 16 by 8.
• Each scanline of the data returned for RGB images is padded to a multiple of 4 bytes. For dithered images, widths can be used that are not multiples of 4, but the size of the data buffer must be calculated using a width that is padded to 4 bytes so that it is large enough to contain the pad data. When this buffer is used in an XCreateImage call, the bytes_per_line argument must also be padded to 4 bytes. For RGB images, the data for each pixel is 4 bytes long so there is no padding.
• Each scanline of the data returned for BICOMP_DECYUVDIB images is padded to a multiple of 4 bytes. Widths can be used that are not multiples of 2 pixels (4 bytes), but the size of the data buffer must be calculated using a width that is padded to 4 bytes so that it is large enough to contain the pad data.

During analog video capture:

• Standard NTSC/SVIDEO525
  • If the image height is less than or equal to 240, then a 640 by 240 field will be captured and scaled to the requested size.
  • If the image height is greater than 240, then a 640 by 480 frame will be captured and scaled to the requested size.
  • JPEG_DIB or MJPG_DIB images cannot be larger than 640 by 480.
• Standard PAL/SECAM/SVIDEO625
  • Only 768 by 288 fields are captured and scaled to the requested size.
  • JPEG_DIB or MJPG_DIB images cannot be larger than 768 by 288.

During analog video playback:

• No filtering is done. Sharp flickering edges may be seen in the image. When playing back JPEG data, no smoothing or filtering is done. As a result, you may see 8 by 8 JPEG quantization blocks. Dithered data looks better due to smoothing.
• If the image size is not a frame or field size, you may see unstable, skewed chromatic shifts in the image. This is more noticeable if the image size is not a multiple of 4 by 4.
• Standard NTSC/SVIDEO525
  • Maximum image size is 640 by 480. The image is scaled up to the size of the output port (640 by 480).
• Standard PAL/SECAM/SVIDEO625
  • Maximum image size is 768 by 288. The image is scaled up to the size of the output port (768 by 576).

During compression and decompression:

• Scaling is only available during decompression. Input and output dimensions must match for compression.

Mirroring is accomplished in software and will significantly slow down operations. Since analog video capture and playback operations depend on a set time interval, software mirroring might cause the next capture or playback operation to miss the next capture or playback slot, delaying it until the next time slot. For instance, if software mirroring slowed down a capture operation so that the next NTSC frame could not be captured within the 30 frames per second period, then the next capture operation would stall until 2 frame periods later, causing all other FullVideo Supreme JPEG operations (such as decompressions) to stall as well, since there is only one hardware queue. If mirroring is desirable and frame rates are important, Compaq suggests that applications perform mirroring in software on the application side. Sample code may be provided in a future release.

B.1.5.4 FullVideo Supreme JPEG Buffer Overwriting

Some FullVideo Supreme JPEG operations will overwrite the incoming data. In particular, when the input to an operation is an RGB image, the input buffer may be used as a scratch buffer by the hardware. This will happen with compression or decompression from RGB or during analog video playback of BI_BITFIELDS with RGB. Mirroring operations may also use the input buffer as a scratch buffer. If the input data is critical to retain, copy the data before passing it to Multimedia Services for OpenVMS.

B.1.5.5 FullVideo Supreme JPEG Video Fields

The Microsoft JPEG DIB standard specifies that when providing only single video fields instead of full video frames, odd fields are to be used. The FullVideo Supreme JPEG card, however, uses even fields when only one field is used on video output.

B.1.5.6 RGB and YUV Decompression for the FullVideo Supreme JPEG Option

On the FullVideo Supreme JPEG card, RGB and YUV decompressed to 8-bit dithered format cannot be run simultaneously with analog video playback operations. Currently, simultaneous analog video playback and these decompressed formats are not permitted due to hardware restrictions. The analog video playback interface videoOpen will return DV_ERR_ALLOCATED if these decompression operations are already in progress, and the decompression interface ICDecompressBegin will return ICERR_ERROR if analog video playback operations are already in progress.

No similar restrictions exist for the compression interfaces.

B.1.5.7 FullVideo Supreme JPEG Quality

Due to a hardware limitation, the highest quality factor for JPEG compression on the FullVideo Supreme JPEG option module is 8984. All quality factors from 8985 to 10000 will be treated as 8984 when JPEG data is encoded, and you will not see any quality improvement as values rise above 8984.

B.1.5.8 FullVideo Supreme JPEG State Information

The FullVideo Supreme JPEG option module does not deal with state information through the ICGetState and ICSetState functions. It does not store or make available any state information but always returns zero bytes for both get and set operations.

B.1.5.9 FullVideo Supreme JPEG Setting Port Numbers

The videoSetPortNum function will return an error for video output devices because all ports are active for video output. Also, if the standard is set to an SVIDEO standard, then the videoSetPortNum function will return an error because there is only one SVIDEO port, and it cannot be selected.

B.1.6 FullVideo Supreme JPEG Video Field Mode Support

The video interfaces videoGetFieldMode and videoSetFieldMode provide better control over frame and field modes, and in field mode, identify which field is the target of operation. The FullVideo Supreme JPEG option module supports the following modes:

Mode	NTSC	PAL/SECAM
FRAME	Yes	No
EVEN_ONLY	Yes	Yes
ODD_ONLY	No	No
BOTH	Yes	Yes

The FullVideo Supreme JPEG option module allows adjustment of video capture field dominance. By default, this option module uses odd dominance for video capture. It uses odd dominance for video playback, but the dominance cannot be adjusted.

The FullVideo Supreme JPEG option module that supports this can be determined by examining the part number on the module itself:

Revision A 54-23296-04.A01
Revision B 54-23296-04.B01

The FullVideo Supreme option module video card enables you to produce multimedia applications using video. You can capture, view, store, and display full-motion video images, and incorporate them into your documents and applications.

This section describes device details for the FullVideo Supreme option module.

B.2.1 FullVideo Supreme Option Module Restrictions

The following restriction is associated with the FullVideo Supreme option module: simultaneous video capture and playback operations are not supported. The device can be opened as either a capture or a playback channel at any given time.

B.2.2 FullVideo Supreme Connectors

Figure B-2 depicts the back of the FullVideo Supreme card.

Figure B-2 FullVideo Supreme Connectors

The FullVideo Supreme option module supports the video formats described in Table B-6 and Table B-7. The tables describe the compression and bitcount as used in the BITMAPINFOHEADER data structure.

Chapter 7 of this guide contains details of the fields in the BITMAPINFOHEADER data structure.

Table B-6 FullVideo Supreme (AV301) Decompression Formats Supported

Input		Output
biCompression	biBit- Count	biCompression	biBit- Count
BICOMP_DECXIMAGEDIB 1	24	BICOMP_DECXIMAGEDIB	8
BI_BITFIELDS 1,2	32	BICOMP_DECXIMAGEDIB	8
BICOMP_DECYUVDIB	16	BICOMP_DECXIMAGEDIB	8
BICOMP_DECXIMAGEDIB	24	BICOMP_DECXIMAGEDIB	8
BI_BITFIELDS	32	BICOMP_DECXIMAGEDIB	8
BICOMP_DECYUVDIB	16	BICOMP_DECXIMAGEDIB	8

Table B-7 FullVideo Supreme (AV301) Analog Video Capture Formats Supported

biCompression	biBitCount
BICOMP_DECXIMAGEDIB	8
BICOMP_DECXIMAGEDIB 1	24
BICOMP_DECYUVDIB	16
BI_BITFIELDS 1,2	32

The FullVideo Supreme option module supports video output of the supported video capture formats as shown in Table B-8.

Table B-8 FullVideo Supreme (AV301) Analog Video Playback Formats Supported

biCompression	biBitCount
BICOMP_DECXIMAGEDIB 1	24
BICOMP_DECXIMAGEDIB	8
BICOMP_DECYUVDIB	16
BI_BITFIELDS 1,2	32

This section describes additional restrictions to the FullVideo Supreme option module.

B.2.4.1 FullVideo Supreme Memory Usage

Buffers or regions of memory passed to FullVideo Supreme devices can only be registered once. For instance, the output JPEG data buffer from an analog video capture ( videoStreamAddBuffer ) cannot be used as the input buffer for decompression ( ICDecompress ). X image output buffers cannot be used as JPEG buffers for other operations.

Since the FullVideo Supreme option shares a command queue with low-level software and the details of the low-level management are difficult to map to the high-level multi-application environment, it is almost impossible to guarantee from the low level that no buffer will be used for two operations concurrently or while data is stale. The FullVideo Supreme device software also makes the restriction that a particular buffer may only appear once in the system at any given time.

In short, use separate buffers for each type of operation ( videoStreamAddBuffer , ICDecompress , ICCompress ) and for each type of buffer (input, output, compress, uncompress). If data needs to be passed from one operation to another, the application must copy the data.

B.2.4.2 FullVideo Supreme Image Size

The sizes of images are restricted as follows:

For all standards:

• Each scanline of the data returned for RGB images is padded to a multiple of 4 bytes. For dithered images, widths can be used that are not multiples of 4, but the size of the data buffer must be calculated using a width that is padded to 4 bytes so that it is large enough to contain the pad data. When this buffer is used in an XCreateImage call, the bytes_per_line argument must also be padded to 4 bytes. For RGB images, the data for each pixel is 4 bytes long so there is no padding.
• Each scanline of the data returned for BICOMP_DECYUVDIB images is padded to a multiple of 4 bytes. Widths can be used that are not multiples of 2 pixels (4 bytes), but the size of the data buffer must be calculated using a width that is padded to 4 bytes so that it is large enough to contain the pad data.

During analog video capture:

• Standard NTSC/SVIDEO525
  • If the image height is less than or equal to 240, then a 640 by 240 field will be captured and scaled to the requested size.
  • If the image height is greater than 240, then a 640 by 480 frame will be captured and scaled to the requested size.
• Standard PAL/SECAM/SVIDEO625
  • Only 768 by 288 fields are captured and scaled to the requested size.
  • The first one-to-three frames of a video capture operation may become corrupted, especially after the device has been used for video playback. The sample code and MMS applets will ignore the first three captured frames to compensate for this.

During analog video playback:

• No filtering is done. Sharp flickering edges may be seen in the image. When playing back JPEG_DIB or MJPG_DIB data, no smoothing or filtering is done. As a result, you may see 8 by 8 JPEG quantization blocks. Dithered data looks better due to smoothing.
• If the image size is not a frame or field size, you may see unstable, skewed chromatic shifts in the image. This is more noticeable if the image size is not a multiple of 4 by 4.
• Standard NTSC/SVIDEO525
  • The image height must be less than or equal to 480, and the image width must be less than or equal to 640 for all formats. They are scaled to the size of the output port (640 by 480).
• Standard PAL/SECAM/SVIDEO625
  • The image height must be less than or equal to 288, and the image width must be less than or equal to 768 for all formats. They are scaled to the size of the output port (768 by 576).
• For all standards:
  • The dimensions must be positive sizes less than or equal to the previous sizes or the format CONFIGURE_ SET will fail.

Mirroring is accomplished in software and will significantly slow down operations. Since analog video capture and playback operations depend on a set time interval, software mirroring might cause the next capture or playback operation to miss the next capture or playback slot, delaying it until the next time slot. For instance, if software mirroring slowed down a capture operation so that the next NTSC frame could not be captured within the 30 frames per second period, then the next capture operation would stall until 2 frame periods later, causing all other FullVideo Supreme operations (such as decompressions) to stall as well, since there is only one hardware queue. If mirroring is desirable and frame rates are important, Compaq suggests that applications perform mirroring in software on the application side. Sample code may be provided in a future release.

B.2.4.4 FullVideo Supreme Buffer Overwriting

Some FullVideo Supreme operations will overwrite the incoming data. In particular, when the input to an operation is an RGB image, the input buffer may be used as a scratch buffer by the hardware. Mirroring operations may also use the input buffer as a scratch buffer. If the input data is critical to retain, copy the data before passing it to Multimedia Services for OpenVMS.

B.2.4.5 RGB and YUV Decompression for the FullVideo Supreme Option Module

On the FullVideo Supreme card, RGB and YUV decompressed to 8-bit dithered format cannot be run simultaneously with analog video playback operations. Currently, simultaneous analog video playback and these decompressed formats are not permitted due to hardware restrictions. The analog video playback interface videoOpen will return DV_ERR_ALLOCATED if these decompression operations are already in progress, and the decompression interface ICDecompressBegin will return ICERR_ERROR if analog video playback operations are already in progress.

No similar restrictions exist for the compression interfaces.