Skip to content

videofilt_deprecatedfeatures

shekh edited this page Apr 15, 2018 · 1 revision

VirtualDub Plugin SDK 1.2

Deprecated features

The following features are supported in current versions of the video filter API, but may perform inefficiently in newer hosts or may not be supported in future versions. The functionality is described here for completeness and to provide migration advice.

VBitmap rendering methods (V1-V11 only)

The VFBitmap structure exposes a number of methods for processing video images, such as BitBlt(). This is the list of virtual methods exposed, in vtable order:

/// Initialize bitmap parameters for a 16-bit (555), 24-bit, or 32-bit bitmap with the given
/// size and base data pointer. Returns *this.
VBitmap& init(void *data, PixDim w, PixDim h, int depth);

/// Initialize bitmap parameters for a 16-bit (555), 24-bit, or 32-bit bitmap with the given
/// Win32 bitmap header. Only bottom-up bitmaps are supported. Returns *this.
VBitmap& init(void *data, BITMAPINFOHEADER *);

/// Compute a BITMAPINFOHEADER for the current bitmap.
void MakeBitmapHeader(BITMAPINFOHEADER *bih) const;

/// Compute pitch, modulo, and size for scanlines aligned to 4-byte boundaries.
void AlignTo4();

/// Compute pitch, modulo, and size for scanlines aligned to 8-byte boundaries.
void AlignTo8();

/// Blit a rectangle of size (dx, dy) from (x1, y1) in the source bitmap to (x2, y2) in the
/// destination (this) bitmap. Color conversion is allowed.
void BitBlt(PixCoord x2, PixCoord y2, const VBitmap *src,
            PixCoord x1, PixCoord y1, PixDim dx, PixDim dy) const;

/// Blit a rectangle of size (dx, dy) from (x1, y1) in the source bitmap to (x2, y2) in the
/// destination (this) bitmap. Color conversion is allowed. Conversion blits from 24-bit or 32-bit
/// to 16-bit results in a conversion with 4x4 ordered dithering. If to565 is true, a depth
/// value of 16 in the destination indicates 565 instead of 555 channels.
void BitBltDither(PixCoord x2, PixCoord y2, const VBitmap *src,
                  PixDim x1, PixDim y1, PixDim dx, PixDim dy, bool to565) const;

/// Same as BitBlt(), except that a depth value of 16 for the source bitmap is interpreted as
/// 565 instead of 555.
void BitBlt565(PixCoord x2, PixCoord y2, const VBitmap *src, PixDim x1, PixDim y1, PixDim dx, PixDim dy) const;

/// Translate a rectangle of size (dx, dy) from (x1, y1) in the source bitmap to (x2, y2) in
/// the destination (this) bitmap. Both bitmaps must be 32-bit. The red, green, and channels
/// are translated via a 256 byte lookup table pointed to by tbl.
bool BitBltXlat1(PixCoord x2, PixCoord y2, const VBitmap *src,
                 PixCoord x1, PixCoord y1, PixDim dx, PixDim dy, const Pixel8 *tbl) const;

/// Translate a rectangle of size (dx, dy) from (x1, y1) in the source bitmap to (x2, y2) in
/// the destination (this) bitmap. Both bitmaps must be 32-bit. The red, green, and channels
/// are translated via a 256 entry lookup table pointed to by tbl. The red, green, and blue
/// channels of the lookup table are used for the respective channel lookups.
bool BitBltXlat3(PixCoord x2, PixCoord y2, const VBitmap *src,
                 PixCoord x1, PixCoord y1, PixDim dx, PixDim dy, const Pixel32 *tbl) const;

/// Stretch a rectangle (x2, y2)-(x2+dx1, y2+dy1) in the source bitmap to (x1, y1)-(x1+dx, y1+dy)
/// in the destination (this) bitmap using point sampling. Both bitmaps must be 32-bit.
bool StretchBltNearestFast(PixCoord x1, PixCoord y1, PixDim dx, PixDim dy,
                           const VBitmap *src, double x2, double y2, double dx1, double dy1) const;

/// Stretch a rectangle (x2, y2)-(x2+dx1, y2+dy1) in the source bitmap to (x1, y1)-(x1+dx, y1+dy)
/// in the destination (this) bitmap using bilinear filtering. Both bitmaps must be 32-bit. When
/// stretching, pixels are replicated along the border (clamp rule).
bool StretchBltBilinearFast(PixCoord x1, PixCoord y1, PixDim dx, PixDim dy,
                            const VBitmap *src, double x2, double y2, double dx1, double dy1) const;

/// Fill a rectangle in the current bitmap with the given 32-bit color value. The bitmap must be
/// 32-bit.
bool RectFill(PixCoord x1, PixCoord y1, PixDim dx, PixDim dy, Pixel32 c) const;

/// Compute a histogram of the color values within the given rectangle. pHisto points to a 256 entry
/// table of pixel counts; iHistoType must be one of the following constants:
///
///     HISTO_LUMA  (0): Compute histogram of Y = 0.211R + 0.715G + 0.074B luminance values.
///     HISTO_GRAY  (1): Compute histogram of red, green, and blue values sequentially (3x counts).
///     HISTO_RED   (2): Compute histogram of red values.
///     HISTO_GREEN (3): Compute histogram of green values.
///     HISTO_BLUE  (4): Compute histogram of blue values.
///
/// 16-bit (555), 24-bit, and 32-bit bitmaps are supported.
///
bool Histogram(PixCoord x, PixCoord y, PixCoord dx, PixCoord dy, long *pHisto, int iHistoType) const;

Custom VBitmap objects can also be declared in the filter. The memory for the bitmap must be allocated by the filter, but the VBitmap object can be constructed directly. The InitVTables callback is used by the filter to retrieve the VBitmap virtual table (vtbl) pointer, which is then used by the VBitmap constructor to initialize the object.

V12+ only: It is invalid to use non-inline (virtual) methods within VBitmap in filters that declare a high API version of V12 or later. Their definitions have been removed from the standard video filter include file. The VBitmap object does not include the mpPixmap pointer from the enclosing VFBitmap structure, so it is not possible to use any of the methods on a bitmap with a non-RGB format, even in a filter that declares API V11 or lower and normally still has access to the functions.

Using Windows GDI with filter bitmaps (V1-V11 only)

By setting the NEEDS_HDC flag on the dwFlags field of the VFBitmap structure, it is possible to request a GDI display context (DC) for the bitmap, which becomes available in the hdc field during operation. This allows Win32 GDI drawing functions to be used directly on the destination bitmap and BitBlt() operations to be used from the source images.

Because of restrictions in what images can be exposed and the relatively slow operation of GDI drawing primitives compared to other available rendering techniques, it is highly recommended that older filters be migrated away from using GDI for video image processing and any new filters avoid its use entirely. Custom or alternate image processing routines can frequently be an order of magnitude faster than GDI.

V12+ only: It is invalid to request an HDC for any bitmap that has a format other than 32-bit RGB, mainly because GDI does not support non-RGB formats. Use of HDCs will thus prevent alternate format support in your filter.

VirtualDub specific: Starting with versions that support API V12, requesting HDCs in a filter imposes a performance penalty, as the pixmap images must be copied in and out of the GDI bitmap.

ESP omission buffer (V1-V11 only)

When runProc is active, the ArbitraryUserPointer field of the Win32 thread information block (TIB) is defined to point to a special data structure:

struct {
    char data[64];
    void *espsave;
};

This data structure is meant to be used by specially crafted assembly language code to temporarily reuse the stack pointer (ESP) as an eighth general purpose register. The FS selector points to the TIB, so ArbitraryUserPointer is at fs:dword ptr [14h]. Because each thread has its own copy of this structure, a function can be made to be re-entrant and still reuse ESP as follows:

mov     eax,dword ptr fs:[14h]

;[move stack values into thread-specific space]

mov     dword ptr [eax+40h],esp
mov     esp,new_value

...

mov     eax,dword ptr fs:[14h]
mov     esp,dword ptr [eax+40h]

This technique requires specially crafted assembly language code and must be done with extreme caution — if an exception occurs while ESP has been hijacked, the host program will immediately crash silently without warning, with no exception handlers firing.

For new filters, it is recommended that the structured exception handling (SEH) chain pointer be used instead. This avoids conflicting with any other uses the host may have for the ArbitraryUserPointer field in the TIB and works with both old and new hosts. To use the technique, allocate the desired block on the stack and place a dummy SEH chain link at the bottom. Here's a full example:

push    0                       ;set handler in SEH stub to NULL (force invalid)
push    fs:dword ptr [0]        ;set next-link in SEH stub to current SEH chain head
mov     fs:dword ptr [0], esp   ;link stub into SEH chain

...

mov     esp, fs:dword ptr [0]   ;recover stack pointer
mov     eax, [esp]              ;get previous SEH chain head
mov     fs:dword ptr [0], eax   ;pop SEH stub off of SEH chain

Host compatibility warning: Avisynth does not support the fs:[14h] pointer in its VirtualDub filter adapter.

X64 only: The 64-bit (X64) version of the video filter API does not support this feature.

V12+ only: This functionality is no longer supported in future versions of the API. New filters marked as V12+ should not use the fs:[14h] field and may crash if they attempt to do so.


Copyright (C) 2007-2012 Avery Lee.

Clone this wiki locally