The VF1 model can actually support multithreaded operation, because the filters expect to receive the source frame on entry, not explicitly request it. This also supercedes the frame lag feature that made it easier, but not entirely possible, for VirtualDub to identify the windowing behavior of a multi-frame-input filter.Īnother issue is synchronous operation. The source frames can come from any number of input source pins and can vary on a per-frame basis. In VF2, the filter's main Run() function is being restructured as a general frame function: y = filter(x, x. It doesn't work well for filters that need to reference more than one source frame, however, or those which want to reorder/add/remove frames.
This is the simplest API to support from a filter author's point of view, because it basically means your filter is a Process() function. YCbCr-to-YCbCr conversions do not go through RGB color space.Īnother problem with the VF1 API is that it enforces in-order processing of video frames, because it is a strict one-frame-in, one-frame-out API.
#Avisynth filters full#
Note that current versions already have a bypass shunt in place for the simple case: if there are no video filters in the chain, the conversions to and from RGB32 are bypassed, even in Full Processing Mode, and a direct blt is done from the source to output format.
#Avisynth filters code#
I don't have this done yet, but all of the support code is in place. I didn't do it this way in 1.6, though, and I'm not sure it's worth the additional rework. well, you get the idea. Some of the capture filters work this way. Ideally, the video format information would have color format and channel format separate. This means the exact same code path could be used for RGB24, RGB32, YUY2, UYVY, Y41P, Y8. For instance, a vertical blur often doesn't care what colorspace or even how many channels are being used, as long as the data is arranged in byte-per-channel format. At this point all that remains with regard to API work is allowing the filters themselves to indicate their format compatibility and to see the new formats. I'm not terribly fond of simply throwing errors when direct compatibility isn't possible between filters, however, so there's some UI work to be done here (the conversion itself is just a call to VDPixmapBlt()).Īs a side note, it's possible for some filter algorithms to ignore aspects of the video frame format. I already completed the prerequisites for this a while back with the new pixmap library in 1.6, which can convert between the common RGB and YCbCr formats, and the new display code, which can handle the formats directly. The only real limitation in the API itself is that it has a single depth field that corresponds to the RGB bit depth the remainder of the limitations were in VirtualDub's support code around that API, most notably the bitmap library. It would thus be desirable to support multiple types of formats in the chain.
While this is very easy to program, and is advantageous for some types of rendering, it is inefficient with other types of image processing algorithms that can be performed directly in the YCbCr color model, which is preferred for many video compression formats. One of the biggest limitations of the current filter API is that it only supports the 32-bit X8R8G8B8 pixel format. Some of the features I talk about here might not make it into the next version, though, depending on how well they work out, as honestly the current design is rather ambitious. I don't normally like to talk about designs-in-progress because it seems too much like a promise that I may not be able to keep, but I also don't like to work alone in the dark for too long. Below, I'll talk about some of these and some of the implications for both users and filter authors. For brevity, I will refer to the current-generation video filter system as VF1 and the next-generation system as VF2. I've sunk a lot of time into it so far, and there are some parts of it that are nice, and other parts that are simply hairy to implement and design. The video filter system is one of the oldest remaining parts of the VirtualDub source code, now that I've rewritten the capture and project modules, and large portions of the render module. While it contributes a rather important part of VirtualDub's feature set, at this point it is also a major limiting factor in the program's development. As such, it has gotten my full attention for the next major experimental release, 1.7.0 (in case you were wondering what I've been doing for the past couple of months).ĭesigning a next-generation video filter system isn't easy. ¶Redesigning the VirtualDub video filtering system