Use vlCreatePath() to create the data path. Its function prototype is

VLPath vlCreatePath(VLServer vlSvr, VLDev vlDev
    VLNode src, VLNode drn) 

This code fragment creates a path if the device is unknown:

if ((path = vlCreatePath(vlSvr, VL_ANY, src, drn)) < 0) {
    vlPerror(_progName);
    exit(1);
}

This code fragment creates a path that uses a device specified by parsing a devlist:

if ((path = vlCreatePath(vlSvr, devlist[devicenum].dev, src,
    drn)) < 0) {
    vlPerror(_progName);
    exit(1);
}

---

Note: If the path contains one or more invalid nodes, vlCreatePath() returns VLBadNode.

---

If you specify VL_ANY as the device when you create the path, use vlGetDevice() to discover the device ID selected. Its function prototype is

VLDev vlGetDevice(VLServer vlSvr, VLPath path)

For example:

devicenum = vlGetDevice(vlSvr, path);
deviceName = devlist.devices[devicenum].name;
printf("Device is: %s/n", deviceName);

For this optional step, use vlAddNode(). Its function prototype is

int vlAddNode(VLServer vlSvr, VLPath vlPath, VLNodeId node)

where

This example fragment adds a source node and a blend node:

vlAddNode(vlSvr, vlPath, src_vid);
vlAddNode(vlSvr, vlPath, blend_node);

Use vlSetupPaths() to set up the data path. Its function prototype is

int vlSetupPaths(VLServer vlSvr, VLPathList paths,
      u_int count, VLUsageType ctrlusage,
      VLUsageType streamusage) 

where

This example fragment sets up a path with shared controls and a locked stream:

if (vlSetupPaths(vlSvr, (VLPathList)&path, 1, VL_SHARE,
    VL_LOCK) < 0)
{
    vlPerror(_progName);
    exit(1);
}

---

Note: The Video Library infers the connections on a path if vlBeginTransfer() is called and no drain nodes have been connected using vlSetConnection() (implicit routing). To specify a path that does not use the default connections, use vlSetConnection() (explicit routing). Chapter 5, “Managing Connections,” explains the use of this function and related requirements.The following rules are used in determining the connections:

---

---

Note: Do not combine implicit and explicit routing.

---

Use vlSelectEvents() to specify the events you want to receive. Its function prototype is

int vlSelectEvents(VLServer vlSvr, VLPath path, VLEventMask eventmask)

where

Table 2-1 lists and describes the VL event masks

For example:

vlSelectEvents(vlSvr, path, VLTransferCompleteMask); 

Event masks can be Or'ed; for example:

vlSelectEvents(vlSvr, path, VLTransferCompleteMask |
      VLTransferFailedMask);

For more details on VL event handling, see Chapter 4, “Event Handling.”

Timing type expresses the timing of video presented to a source or drain. Table 2-3 summarizes dimensions for VL_TIMING.

To specify video input and output formats of the video signal on the physical connector, use VL_FORMAT.

A video packing describes how a video signal is stored in memory, in contrast with a video format, which describes the characteristics of the video signal. For example, the memory source nodes—CC1 and both VGI1 nodes—accept packed video from a DMbuffer or VL buffer and output video in a given format.

Packings are specified through the VL_PACKING control on the memory nodes. This control also converts one video output format to another in memory, within the limits of the nodes.

---

Note: On dual-linked VGI1 memory nodes, only native packings are available; no conversions can be performed.

---

Packing types for eight bits per component are summarized in Table 2-5. In this table, the Native To column lists the nodes to which the packing is native; no software conversion is required, so these packings are fastest.

Packing types for ten bits per component are summarized in Table 2-6. The ten data bits are left-aligned within a 16-bit word. The hardware sets the lower six bits to zero before it writes them to memory. When reading from memory, the lower six bits are ignored. All are native to VGI1 memory nodes.

In addition, the OCTANE Digital Video option also supports dual-link AYUAYV, a packed format with three 10-bit components per 32-bit word, with the lowest two bits set to 0. It is native to VGI1 memory nodes. Bits are

Finally, OCTANE Digital Video option supports two 10-bit formats that have two bits for alpha, as summarized in Table 2-7.

---

Note: Other libraries may use different packing names.

---

For example:

VLControlValue val;

val.intVal = VL_PACKING_RGBA_10;
vlSetControl(vlSvr, path, memdrn, VL_PACKING, &val);

If the single-link packings VL_PACKING_RGB_332_P, VL_PACKING_RGB_8, and VL_PACKING_Y_8_P are requested of a memory drain node, the Video Library performs a software conversion to translate the data from a native packing and format. The application receives data in the requested packing and format, although the capture rate may be degraded.

VL_ZOOM controls the expansion or decimation of the video image. Values greater than one expand the video; values less than one perform decimation. Figure 2-1 illustrates zooming and decimation.

---

Note: OCTANE Digital Video screen drain nodes support the full range of VL_ZOOM (7/1, 6/1, 5/1, 4/1, 3/1, 2/1, 1/1, 1/2, 1/3, 1/4, 1/5, 1/6, 1/7, 1/8). Screen source nodes support 1/1 and 1/2. The texture node supports decimation only. The remaining nodes do not support zoom or decimation (the ratio 1/1 only).

---

Figure 2-1. Zoom and Decimation

VL_ZOOM takes a nonzero fraction as its argument; do not use negative values. For example, this fragment captures half-size decimation video to the screen:

val.fractVal.numerator = 1;
val.fractVal.denominator = 2;
if (vlSetControl(server, screen_path, screen_drain_node, VL_ZOOM, &val)){
   vlPerror("Unable to set zoom");
   exit(1);
}

---

Note: For a source, zooming takes place before blending; for a drain, blending takes place before zooming.

---

This fragment captures half-size decimation video to the screen, with clipping to 320 × 243 (NTSC size minus overscan):

val.fractVal.numerator = 1;
val.fractVal.denominator = 2;
if (vlSetControl(server,screen_path, screen_drain_node,
VL_ZOOM, &val))
{
    vlPerror("Unable to set zoom");
    exit(1);
}
val.xyVal.x = 320;
val.xyVal.y = 243;
if (vlSetControl(server, screen_path, screen_drain_node,
VL_SIZE, &val))
{
    vlPerror("Unable to set size");
    exit(1);
}

This fragment captures xsize × ysize video with as much decimation as possible, assuming the size is smaller than the video stream:

if (vlGetControl(server, screen_path, screen_source, VL_SIZE, &val))
{
   vlPerror("Unable to get size");
   exit(1);
}
if (val.xyVal.x/xsize < val.xyVal.y/ysize)
   zoom_denom = (val.xyVal.x + xsize - 1)/xsize;
else
   zoom_denom = (val.xyVal.y + ysize - 1)/ysize;
val.fractVal.numerator = 1;
val.fractVal.denominator = zoom_denom;
if (vlSetControl(server, screen_path, screen_drain_node, VL_ZOOM, &val))
{
   /* allow this error to fall through */
   vlPerror("Unable to set zoom");
}
val.xyVal.x = xsize;
val.xyVal.y = ysize;
if (vlSetControl(server, screen_path, screen_drain_node,
VL_SIZE, &val))
{
   vlPerror("Unable to set size");
   exit(1);
}

VL_SIZE controls how much of the image sent to the drain is used, that is, how much clipping takes place. This control operates on the zoomed image; for example, when the image is zoomed to half size, the limits on the size control change by a factor of 2. Figure 2-2 illustrates clipping.

Figure 2-2. Clipping an Image

For example, to display PAL video in a 320 × 243 space, clip the image to that size, as shown in the following fragment:

VLControlValue value;

value.xyval.x=320;
value.xyval.y=243;
vlSetControl(vlSvr, path, drn, VL_SIZE, &value); 

---

Note: Because this control is device-dependent and interacts with other controls, always check the error returns. For example, if offset is set before size and an error is returned, set size before offset.

---

VL_OFFSET puts the upper left corner of the video data at a specific position; it sets the beginning position for the clipping performed by VL_SIZE. The values you enter are relative to the origin.

This example places the data ten pixels down and ten pixels in from the left:

VLControlValue value;

value.xyval.x=10; 
value.xyval.y=10; 
vlSetControl(vlSvr, path, drn, VL_OFFSET, &value); 

To capture the blanking region, set offset to a negative value.

Figure 2-3 shows the relationships between the source and drain size, offset, and origin.

---

Note: For memory nodes, VL_OFFSET and VL_SIZE in combination define the active region of video that is transferred to or from memory.

---

Figure 2-3. Zoom, Size, Offset, and Origin

An application can request that the OCTANE Digital Video option capture or play back a video stream in a number of ways. For example, the application can request that each field be placed in its own buffer, that each buffer contain an interleaved frame, or that only odd or even fields be captured. This section enumerates the capture types that the OCTANE Digital Video option supports.

A field mask is useful for identifying which fields will be captured and played back and which fields will be dropped. A field mask is a bit mask of 60 bits for NTSC or 50 bits for PAL (two fields per frame). A numeral 1 in the mask indicates that a field is captured or played back, while a zero indicates that no action occurs.

For example, the following field mask indicates that every other field will be captured or played back:

10101010101010101010...

Capture types are as follows:

These capture types apply to both VL buffers and DMbuffers.

VL_RATE determines the data transfer rate by field or frame, depending on the capture type as specified by VL_CAP_TYPE, as shown in Table 2-8.

---

Note: Not all rates are supported on all memory nodes; see Appendix C, “OCTANE Digital Video Color-Space Conversions,” for details. The buffer size must be set in accordance with the capture type, as listed in Table 2-10 later in this chapter.

---

The VL_CAPTURE_NONINTERLEAVED capture type specifies that frame-size units are captured noninterleaved. Each field is placed in its own buffer, with the dominant field in the first buffer. If one of the fields of a frame is dropped, all fields are dropped. Consequently, an application is guaranteed that the field order is maintained; no special synchronization is necessary to ensure that fields from different frames are mixed.

The rate (VL_RATE) for noninterleaved capture is in terms of fields and must be even. For NTSC, the capture rate may be from 2-60 fields per second, and for PAL 2-50 fields per second. Because a frame is always captured as a whole, a rate of 30 fields per second results in the following field mask:

1100110011001100...

The first bit in the field mask corresponds to the dominant field of a frame. The OCTANE Digital Video option waits for a dominant field before it starts the transfer.

If VL_CAPTURE_NONINTERLEAVED is specified for playback, similar guarantees apply as for capture. If one field is lost during playback, it is not possible to “take back” the field. The OCTANE Digital Video option resynchronizes on the next frame boundary, although black or “garbage” video might be present between the erring field and the frame boundary.

The rate during playback also follows the rules for capture. For each 1 in the mask above, a field from the VL buffer is output. During the 0 fields, the previous frame is repeated. Note that the previous frame is output, not just the last field. If there are a pair of buffers, the dominant field is placed in the first buffer.

Interleaved capture interleaves the two fields of a frame and places them in a single buffer; the order of the frames depends on the value set for VL_MGV_DOMINANCE_FIELD (see Table B-5 or Table B-6 in Appendix B for details). The OCTANE Digital Video option guarantees that the interleaved fields are from the same frame: if one field of a frame is dropped, then both are dropped.

The rate for interleaved frames is in frames per second: 1-30 frames per second for NTSC and 1-25 frames per second for PAL. A rate of 15 frames per second results in every other frame being captured. Expressed as a field mask, the following sequence is captured:

1100110011001100....

As with VL_CAPTURE_NONINTERLEAVED, the OCTANE Digital Video option begins processing the field mask when a dominant field is encountered.

During playback, a frame is deinterleaved and output as two consecutive fields, with the dominant field output first. If one of the fields is lost, the OCTANE Digital Video option resynchronizes to a frame boundary before playing the next frame. During the resynchronization period, black or “garbage” data may be displayed.

Rate control follows similar rules as for capture. For each 1 in the mask above, a field from the interleaved frame is output. During 0 periods, the previous frame is repeated.

This option is not applicable to the texture node VL_TEX.

In the VL_CAPTURE_EVEN_FIELDS capture type, only even (F2) fields are captured, with each field placed in its own buffer. Expressed as a field mask, the captured fields are

1010101010101010...

The OCTANE Digital Video option begins processing this field mask when an even field is encountered.

The rate for this capture type is expressed in even fields. For NTSC, the range is 1-30 fields per second, and for PAL 1-25 fields per second. A rate of 15 fields per second (NTSC) indicates that every other even field is captured, yielding a field mask of

1000100010001000...

During playback, the even field is repeated as both the F1 and F2 fields, until it is time to output the next buffer. If a field is lost during playback, black or “garbage” data might be displayed until the next buffer is scheduled to be displayed.

The VL_CAPTURE_ODD_FIELDS capture type works the same way as VL_CAPTURE_EVEN_FIELDS, except that only odd (F1) fields are captured, with each field placed in its own buffer. The rate for this capture type is expressed in odd fields. A rate of 15 fields per second (NTSC) indicates that every other odd field is captured. Field masks are the same as for VL_CAPTURE_EVEN_FIELDS.

The VL_CAPTURE_FIELDS capture type captures both even and odd fields and places each in its own buffer. Unlike VL_CAPTURE_NONINTERLEAVED, there is no guarantee that fields are dropped in frame units. Field synchronization can be performed by examining the UST (Unadjusted System Time), the MSC (Media Stream Count), or the dmedia info sequence number associated with each field.

The rate for this capture type is expressed in fields. For NTSC, the range is
1-60 fields per second, and for PAL 1-50 fields per second. A rate of 30 fields per second (NTSC) indicates that every other field is captured, resulting in the following field mask:

101010101010101010...

Contrast this with the rate of 30 for VL_CAPTURE_NONINTERLEAVED, which captures every other frame.

Field mask processing begins on the first field after the transfer is started; field dominance, evenness, oddness plays no role in this capture type.

This section explains:

create video buffer between me and the audio output;
create audio buffer between me and the video output; 
while (1)
{
   sleep until one of the buffers is getting empty;
   for (video buffer)
      {
         use UST/MSC to determine:
            “at what time (what UST) will the next video data I enqueue
            on the buffer actually go out the jack of the machine?”;
      }

   for (audio buffer)
      {
         (exact same thing as above, except for audio)
      }

   From the predicted video and audio USTs, determine
      “what is the synchronization error between the audio and video
      streams?”

   Enqueue more frames to fill up the audio and video buffer queues.
   If there is synchronization error, enqueue new frames to either skip
   frames on the stream that is behind or repeat frames on the stream
   that is ahead.
     }
}

Media Library Interfaces for UST and MSC

UST/MSC calls allow you to associate a UST with a particular piece of data that just left a buffer or is about to enter a buffer. The VL calls for determining the MSC and UST—vlGetUSTMSCPair(3dm), vlGetFrontierMSC(3dm), and vlGetUSTPerMSC(3dm)—help synchronize input and output of different data streams in cases where the application is getting data from or putting data into each device via a buffer. The application is at the “frontier” end of this buffer and the devices are at the “device” end of the buffer.

• vlGetUSTMSCPair() gets the timing information for each frame/field as it enters or leaves the physical jack of a device.

  This call returns an atomic UST/MSC pair for the jack (specified with the VL_NODE and the VLPort for that node) for a given path that contains a VL_MEM node. The returned MSC is not guaranteed to be the one currently at the jack, nor is it even guaranteed to be the number of any media stream sample currently in the application's buffer. To relate the returned MSC to a particular item in the application's buffer, you must use vlGetFrontierMSC().

• vlGetFrontierMSC() gets the frontier MSC associated with a particular VL_MEM node.

  The frontier MSC, at the application end of the media stream, is the MSC of the next item that the application removes from or puts into the buffer.

• vlGetUSTPerMSC() gets the time spacing of fields/frames in a path (the nominal average UST time elapsed between media stream samples in a given VLPath that includes a VL_MEM node).

These calls are used for extrapolating a UST/MSC pair as shown in vlGetFrontierMSC(). For other types of media streams, a similar mechanism extrapolates the UST/MSC pair; for example, for audio, use equivalent AL calls.

Once you have calculated the extrapolated UST/MSC pairs for both media streams, you can determine the synchronization error. The difference in the audio and video USTs for matching frame numbers is the amount they are out of sync. To resynchronize them, you must enqueue new frames to either skip frames on the stream that is behind or repeat frames on the stream that is ahead. The number of frames to be skipped or repeated is the difference in USTs divided by the frame rate.

To use UST/MSC, the application must have separate handles for each separate piece of data coming in or going out of some kind of buffer. The application can use these handles to specify, for example, a particular frame to output or pixels of a particular field to get.

---

Note: For complete details, including syntax, code examples, and caveats, see the references pages for these calls.

---

The VL supports two buffering mechanisms for capturing or playing back video:

---

Note: For complete information on DMbuffers and digital media image converters, see the Digital Media Programming Guide.

---

In general, VL buffers and DMbuffers differ in the following ways:

Each buffering mechanism has a set of API functions for creating, registering, and manipulating buffers. A mismatch between a buffer mechanism and an API call, for example, applying a VL buffer call to a DMbuffer, results in a VLAPIConflict error return.

Applications can use either VL buffers or DMbuffers, as long as a memory node is used with only one buffering mechanism at a time. If an application uses multiple memory paths, each path can use a different buffering mechanism. To switch buffering mechanisms, the VL path should be torn down and reconstructed.

Table 2-9 shows correspondences between VL buffer and DMbuffer API functions.

The DMbuffer is created through the dmBufferCreatePool() routine and is associated with a memory node by the dmPoolRegister() routine.

When the OCTANE Digital Video option transfers data from the Video Library to an application, it places data in a buffer element and marks the element as valid. The application can retrieve the element through the vlDMBufferGetValid() routine. When the application is done, it uses the dmBufferFree() routine to alert the video device that the buffer element can be reused. For complete details on using DMbuffers, see Chapter 5 of the Digital Media Programming Guide (007-1799-060 or later).

This section explains

DMstatus dmBufferSetPoolDefaults(DMparams *poolParams, int bufferCount, int bufferSize, DMboolean cacheable, DMboolean mapped)

int vlDMBufferGetParams(VLServer svr, VLPath path, VLNode node, DMparams *params)

DMstatus dmBufferCreatePool(const DMparams *poolParams, DMbufferpool *returnPool)

int vlDMBufferPoolRegister(VLServer svr, VLPath path, VLNode node, DMbufferpool pool)

int vlBeginTransfer(VLServer vlSvr, VLPath path, int count,
      VLTransferDescriptor* xferDesc) 

xferDesc.mode = VL_TRANSFER_MODE_DISCRETE;

xferDesc.count = imageCount;
xferDesc.delay = 0;
xferDesc.trigger = VLTriggerImmediate;

xferDesc.mode = VL_TRANSFER_MODE_CONTINUOUS;

xferDesc.count = 0;
xferDesc.delay = 0;
xferDesc.trigger = VLTriggerImmediate;

int vlDMBufferGetValid(VLServer svr, VLPath path, VLNode node, DMbuffer* dmbuffer)

int vlDMBufferPutValid(VLServer svr, VLPath path, VLNode node, DMbuffer dmbuffer)

The processes for data transfer using VL buffers are as follows:

Each process is explained separately.

Creating a Buffer for Video Data

Once you have specified frame parameters in a transfer involving memory (or have determined to use the defaults), create a VL buffer for the video data. In this case, video data is frames or fields, depending on the capture type:

• frames if the capture type is VL_CAPTURE_NONINTERLEAVED

• fields if the capture type is anything else

VL buffers provide a way to read and write varying sizes of video data. A frame of data consists of the actual frame data and an information structure describing the underlying data, including device-specific information.

When a VL buffer is created, constraints are specified that control the total size of the data segment and the number of frame or field buffers (sectors) to allocate. A head and a tail flag are automatically set in a VL buffer so that the latest frame can be accessed. A sector is locked down if it is not called; that is, it remains locked until it is read. When the VL buffer is written to and all sectors are occupied, data transfer stops. The sector last written to remains locked down until it is released.

All sectors in a VL buffer must be of the same size, which is the value returned by vlGetTransferSize(). Its function prototype is

long vlGetTransferSize(VLServer vlSvr, VLPath path)

For example:

transfersize = vlGetTransferSize(vlSvr, path);

where transfersize is the size of the data in bytes.

To create a VL buffer for the frame data, use vlCreateBuffer(). Its function prototype is

VLBuffer vlCreateBuffer(VLServer vlSvr, VLPath path, VLNode node, int numFrames)

where

VLBuffer		is the handle of the buffer to be created
vlSvr		names the server to which the path is connected
path		specifies the data path
node		specifies the memory node containing data to transfer to or from the VL buffer
numFrames		specifies the number of sectors in the buffer (fields or frames, depending on the capture type)

For example:

buf = vlCreateBuffer(vlSvr, path, src, 1);

Table 2-10 shows the relationship between capture type and minimum VL buffer size.

Table 2-10. Buffer Size Requirements

Capture Type	Minimum Sectors for Capture	Minimum Sectors for Playback
VL_CAPTURE_NONINTERLEAVED	2	4
VL_CAPTURE_INTERLEAVED	1	2
VL_CAPTURE_EVEN_FIELDS	1	2
VL_CAPTURE_ODD_FIELDS	1	2
VL_CAPTURE_FIELDS	1	2

---

Note: For VGI1 memory nodes, real-time memory or video transfer can be performed only as long as buffer sectors are available to the OCTANE Digital Video device.

---

int vlRegisterBuffer(VLServer vlSvr, VLPath path,
     VLNode memnodeid, VLBuffer buffer)

vlRegisterBuffer(vlSvr, path, drn, Buffer);

Reading Data From the VL Buffer

If your application uses a VL buffer, use various VL calls for reading frames, getting pointers to active buffers, freeing buffers, and other operations. Table 2-11 lists the buffer-related calls.

Table 2-11. Buffer-Related Calls

Call	Purpose
vlGetNextValid()	Returns a handle on the next valid frame or field of data
vlGetLatestValid()	Reads only the most current frame or field in the buffer, discarding the rest
vlPutValid()	Puts a frame or field into the valid list (memory to video)
vlPutFree()	Puts a valid frame or field back into the free list (video to memory)
vlGetNextFree()	Gets a free buffer into which to write data (memory to video)
vlBufferDone()	Informs you if the buffer has been vacated
vlBufferReset()	Resets the buffer so that it can be used again

Figure 2-4 illustrates the difference between vlGetNextValid() and vlGetLatestValid(), and their interaction with vlPutFree().

Figure 2-4. vlGetNextValid() and vlGetLatestValid()

Table 2-12 lists the calls that extract information from a buffer.

Table 2-12. Calls for Extracting Data From a Buffer

Call	Purpose
vlGetActiveRegion()	Gets a pointer to the data region of the buffer (video to memory); called after vlGetNextValid() and vlGetLatestValid()
vlGetDMediaInfo()	Gets a pointer to the DMediaInfo structure associated with a frame; this structure contains timestamp and field count information
vlGetImageInfo()	Gets a pointer to the DMImageInfo structure associated with a frame; this structure contains image size information

---

Caution: None of these calls has count or block arguments; appropriate calls in the application must deal with a NULL return in cases of no data being returned.

---

In summary, for video-to-memory transfer, use

buffer = vlCreateBuffer(vlSvr, path, memnode1); vlRegisterBuffer(vlSvr, path, memnode1, buffer); vlBeginTransfer(vlSvr, path, 0, NULL); info = vlGetNextValid(vlSvr, buffer); /* OR vlGetLatestValid(vlSvr, buffer); */ dataptr = vlGetActiveRegion(vlSvr, buffer, info); /* use data for application */ … vlPutFree(vlSvr, buffer);

For memory-to-video transfer, use

buffer = vlCreateBuffer(vlSvr, path, memnode1); vlRegisterBuffer(vlSvr, path, memnode1, buffer); vlBeginTransfer(vlSvr, path, 0, NULL); buffer = vlGetNextFree(vlSvr, buffer, bufsize); /* fill buffer with data */ … vlPutValid(vlSvr, buffer);

To read the frames to memory from the buffer, use vlGetNextValid() to read all the frames in the buffer or get a valid frame of data. Its function prototype is

VLInfoPtr vlGetNextValid(VLServer vlSvr, VLBuffer vlBuffer)

Use vlGetLatestValid() to read only the most current frame in the buffer, discarding the rest. Its function prototype is

VLInfoPtr vlGetLatestValid(VLServer vlSvr, VLBuffer vlBuffer)

After removing interesting data, return the buffer for use with vlPutFree() (video to memory). Its function prototype is

int vlPutFree(VLServer vlSvr, VLBuffer vlBuffer)

To send frames from memory to video, use vlGetNextFree() to get a free buffer to which to write data. Its function prototype is

VLInfoPtr vlGetNextFree(VLServer vlSvr, VLBuffer vlBuffer, int size)

After filling the buffer with the data you want to send to video output, use vlPutValid() to put a frame into the valid list for output to video (memory to video). Its function prototype is

int vlPutValid(VLServer vlSvr, VLBuffer vlBuffer)

---

Caution: These calls do not have count or block arguments; appropriate calls in the application must deal with a NULL return in cases of no data being returned.

---

To get DMediaInfo and Image Data from the buffer, use vlGetActiveRegion() to get a pointer to the active buffer. Its function prototype is

void * vlGetActiveRegion(VLServer vlSvr, VLBuffer vlBuffer, VLInfoPtr ptr)

Use vlGetDMediaInfo() to get a pointer to the DMediaInfo structure associated with a frame. This structure contains timestamp and field count information. The function prototype for this call is

DMediaInfo * vlGetDMediaInfo(VLServer vlSvr, VLBuffer vlBuffer,  VLInfoPtr ptr)

Use vlGetImageInfo() to get a pointer to the DMImageInfo structure associated with a frame. This structure contains image size information. The function prototype for this call is

DMImageInfo * vlGetImageInfo(VLServer vlSvr, VLBuffer vlBuffer,  VLInfoPtr ptr)