-
Notifications
You must be signed in to change notification settings - Fork 15
videofilt_deprecatedfeatures
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.
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.
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.
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.
Setting up your development environment
Conventions
Plugin initialization
Dynamic loading
Reference counting
Using CPU extensions
Introduction
What's new
Breaking changes
Gotchas
Deprecated features
Migrating from the old Filter SDK
Programming model
Handling bitmaps
Creating a video filter
Setting filter parameters
Processing video frames
Managing filter data
Creating time-varying filters
Handling aspect ratio
Prefetching multiple source frames
Handling multiple sources
Making a filter configurable
Scripting support
CPU dependent optimization
VDXA index omitted
Getting started
Writing the module entry point
Creating a video filter
Adding configurability
Adding script support
Introduction
What's new
Autodetect
Direct mode
Video frames vs. samples
Video decodint model
Video decoder