Log in

View Full Version : VirtualDub2


Pages : 1 [2] 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

wiseant
1st July 2016, 20:59
@shekh

Hi

I re-downloaded VirtualDub_pack37277.zip - the scripted.vdplugin is different from the VirtualDub_pack37277.zip that I downloaded yesterday [June 30]:


C:\VirtualDub_pack_37277_old\plugins32
scripted.vdplugin
616 KB (630,784 bytes)
June 30, 2016, 8:05:02 PM


This scripted.vdplugin did not work - VirtualDub failed to open - had to close it with Task Manager


C:\VirtualDub_pack_37277\plugins32
scripted.vdplugin
614 KB (628,736 bytes)
July 01, 2016, 6:32:02 PM


This scripted.vdplugin does work on my system.

Thank you!

StainlessS
10th July 2016, 14:26
Getting an alert box on startup, "Module Failed to load correctly ... plugins32\ffdlls\avutil-55.dll".

Everything else cleared from plugins32 before copying all plugin32 stuff from VirtualDub_pack_37277\plugins32.


XP32 SP3

EDIT: I did get some kind of memory leak alert for colortools, in Debugview (old version of VDFM), but gone now in new version.

shekh
10th July 2016, 14:41
Getting an alert box on startup, "Module Failed to load correctly ... plugins32\ffdlls\avutil-55.dll".

Everything else cleared from plugins32 before copying all plugin32 stuff from VirtualDub_pack_37277\plugins32.


could be a problem with ffmpeg
can you try this ffmpeg build (run ffplay on some movie)
https://ffmpeg.zeranoe.com/builds/win32/shared/ffmpeg-20160428-git-78baa45-win32-shared.7z

or any more recent build?

Groucho2004
10th July 2016, 15:16
XP32 SP3
Use a static build. The last (stable) one supported on XP is 3.0 (https://ffmpeg.zeranoe.com/builds/win32/static/ffmpeg-3.0-win32-static.7z)

StainlessS
10th July 2016, 15:57
Thanks guys.
Linked by Groucho2004 ffplay worked fine, Shekh linked "the procedure entry point _wfopen_s could not be located in dynamic link library msvcrt.dll".
I tried to just move the ffdlls directory somewhere else, and it still throws up the error.
Is there some other way to disable use of that dll (not bothered about ffmpeg stuff, I found that it tended to interfere with ffmpeg proper anyway).

manolito
10th July 2016, 16:06
FWIW there is a patch at the Zeranoe forum which makes the latest FFmpeg versions work under XP. It is a simple search and replace patch, wfopen_s is changed to wfopen.
https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=13&t=3572


Cheers
manolito

StainlessS
10th July 2016, 16:29
Thank you Manolito, very interesting, gonna give it a try.

Does VirtualDub FilterMod use system installed 'standard' ffmpeg, I have to have "FFInputDriver.vdplugin" in plugins32 for it to use those dll's in
standard VD (ie avsutil-55.dll etc).

shekh
10th July 2016, 17:00
Thank you Manolito, very interesting, gonna give it a try.

Does VirtualDub FilterMod use system installed 'standard' ffmpeg, I have to have "FFInputDriver.vdplugin" in plugins32 for it to use those dll's in
standard VD (ie avsutil-55.dll etc).

FilterMod includes cch_input.vdf (caching input driver) if you don't want it remove this file along with ffdlls directory.

"FFInputDriver.vdplugin" why you need it?

shekh
10th July 2016, 18:26
EDIT: I did get some kind of memory leak alert for colortools, in Debugview (old version of VDFM), but gone now in new version.

Thanks for alert but this is too vague.
How did you get the message, did you compile debug build of VirtualDub?
Which old version?
What I can find in commit history, there were fixes to some memory leaks in may.

Reel.Deel
10th July 2016, 18:45
Shekh, any thoughts on incorporating APNG from this mod: http://vdubapngmod.sourceforge.net/

shekh
10th July 2016, 18:55
Shekh, any thoughts on incorporating APNG from this mod: http://vdubapngmod.sourceforge.net/

My thoughts were "lets see if somebody ask" :)
Are you using it? What you do with apng's?

Reel.Deel
10th July 2016, 18:58
My thoughts were "lets see if somebody ask" :)
Are you using it? What you do with apng's?

Yes I use it from time to time. Here's one I made for the AviSynth wiki: http://avisynth.nl/index.php/ChannelMixer#Examples

StainlessS
10th July 2016, 20:40
FilterMod includes cch_input.vdf (caching input driver) if you don't want it remove this file along with ffdlls directory.

"FFInputDriver.vdplugin" why you need it?
FFInputDriver.vdplugin was just some kind of video source plugin, I did not use it at all and removed it from plugin32,
(It used to [I think] conflict with Avisynth FFMpegSource, they changed each others path/path search order, or something like that).

I'll remove cch_Input thing.

I did not keep any record of the error message captured by DebugView, from vd_edit.zip with files internally dated 28/6/2016.
I had not gotten around to install the latest VDFM, so thought it might have been fixed there.

I'll re-install the one that gave the error message and see if I can get it to repeat the message.

StainlessS
10th July 2016, 20:53
Here memory leak messages,


00000012 20:46:48.359 Verifying class: FrameSubset
00000013 20:46:48.375 Plugins: Attempting to load "C:\Z\plugins\clrtools.vdf"
00000014 20:46:48.375 Plugins: Unloading module "C:\Z\plugins\clrtools.vdf"
00000015 20:46:48.375 Plugins: Attempting to load "C:\Z\plugins32\scripted.vdplugin"
00000016 20:46:48.562 RemoveDirt 0.9
00000017 20:46:48.640 SSETools 0.1
00000018 20:46:48.750 FFMS2 avs plugin: Initializing...
00000019 20:46:49.484 Plugins: Unloading module "C:\Z\plugins32\scripted.vdplugin"
00000020 20:46:49.656 RemoveDirt 0.9
00000021 20:46:49.734 SSETools 0.1
00000022 20:46:49.843 FFMS2 avs plugin: Initializing...
00000023 20:46:54.984 RemoveDirt 0.9
00000024 20:46:55.062 SSETools 0.1
00000025 20:46:55.656 VideoDisplay/DirectDraw: Display is 32-bit xRGB (8-8-8-8).
00000026 20:46:55.656 VideoDisplay: Using DirectDraw offscreen surface for 508x379 RGB888 display.
00000027 20:46:55.671 VideoDisplay/DirectDraw: Display is 32-bit xRGB (8-8-8-8).
00000028 20:46:55.671 VideoDisplay: Using DirectDraw offscreen surface for 508x379 RGB888 display.
00000029 20:47:23.687 VideoDisplay/DirectDraw: Display is 32-bit xRGB (8-8-8-8).
00000030 20:47:23.687 VideoDisplay: Using DirectDraw offscreen surface for 360x570 XRGB8888 display.
00000031 20:47:34.593 VideoDisplay/DirectDraw: Display is 32-bit xRGB (8-8-8-8).
00000032 20:47:34.593 VideoDisplay: Using DirectDraw offscreen surface for 1x1 XRGB8888 display.
00000033 20:47:34.593 VideoDisplay/DirectDraw: Display is 32-bit xRGB (8-8-8-8).
00000034 20:47:34.593 VideoDisplay: Using DirectDraw offscreen surface for 1x1 XRGB8888 display.
00000035 20:47:34.609 VideoDisplay/DirectDraw: Display is 32-bit xRGB (8-8-8-8).
00000036 20:47:34.609 VideoDisplay: Using DirectDraw offscreen surface for 508x379 RGB888 display.
00000037 20:47:34.609 VideoDisplay/DirectDraw: Display is 32-bit xRGB (8-8-8-8).
00000038 20:47:34.609 VideoDisplay: Using DirectDraw offscreen surface for 360x570 XRGB8888 display.
00000039 20:47:44.343 VideoDisplay/DirectDraw: Display is 32-bit xRGB (8-8-8-8).
00000040 20:47:44.343 VideoDisplay: Using DirectDraw offscreen surface for 508x379 RGB888 display.
00000041 20:47:44.343 VideoDisplay/DirectDraw: Display is 32-bit xRGB (8-8-8-8).
00000042 20:47:44.359 VideoDisplay: Using DirectDraw offscreen surface for 360x570 XRGB8888 display.
00000043 20:47:48.187 Plugins: Unloading module "C:\Z\plugins\clrtools.vdf"
00000046 20:47:48.218 ===== MEMORY LEAKS DETECTED =====
00000049 20:47:48.390 Primary leaks:
00000052 20:47:48.390 Secondary leaks:
00000054 20:47:48.390 #3143 018B8BB8 ( 12 bytes)
00000055 20:47:48.390 #2657 018B9358 ( 12 bytes)
00000056 20:47:48.390 #3142 018B9AF0 ( 60 bytes) Allocator: 007D5975
00000057 20:47:48.390 #3148 018C70B8 ( 208 bytes) Allocator: 0092237B
00000058 20:47:48.390 #2662 018C7320 ( 208 bytes) Allocator: 0092237B
00000059 20:47:48.390 #2656 018C81F0 ( 60 bytes) Allocator: 007D5975
00000060 20:47:48.390 #2663 04DD0040 ( 820843 bytes) Allocator: 00B573F9
00000061 20:47:48.390 #3149 04EA0040 ( 820843 bytes) Allocator: 00B573F9
00000063 20:47:48.390 End of leak dump.


Looks like its color Tools v1.4 that has the memory leaks, and presumably debugging switched off in the latest VDFM on SourceForge.

shekh
10th July 2016, 20:55
FFInputDriver.vdplugin was just some kind of video source plugin, I did not use it at all and removed it from plugin32,
(It used to [I think] conflict with Avisynth FFMpegSource, they changed each others path/path search order, or something like that).


Yes it is possible to have conflict if FFMpegSource uses shared ffmpeg too.

shekh
10th July 2016, 21:01
Here memory leak messages,
Looks like its color Tools v1.4 that has the memory leaks, and presumably debugging switched off in the latest VDFM on SourceForge.

Wow, serious leaks, nice catch.
What you do step by step, from starting VD to exit?
ColorTools is unrelated (it does not share memory with VD anyway), the leaks belong to VD.

StainlessS
10th July 2016, 21:15
All I did was load a single frame clip in AVS script [loaded into Avisynth using ImageSource() from jpeg],
Added Colortools filter in VD, played single frame clip with histogram showing (only change to defaults in Colortools
was I ticked the "Accumulate across frames" box [but only one frame source]).
Then play 1 frame clip, then close VDFM.
Up pops error messages in DebugView from System Internals (Microsoft).

shekh
12th July 2016, 22:22
interesting :)

https://trac.ffmpeg.org/ticket/5657

shekh
13th July 2016, 22:28
Leak reported by StainlessS fixed, I reuploaded binaries.
Looks like epic threading race, at least as old as output pane.

StainlessS
14th July 2016, 17:16
OOOooooh, lovely :)

shekh
16th July 2016, 11:25
FWIW there is a patch at the Zeranoe forum which makes the latest FFmpeg versions work under XP. It is a simple search and replace patch, wfopen_s is changed to wfopen.
https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=13&t=3572


Cheers
manolito

The path may seem to solve local problem but this is very ugly patch.
There is no need to replace wfopen_s with wfopen, you can replace it with all zeroes because the function will not work anyway.


FILE *_wfopen(
const wchar_t *filename,
const wchar_t *mode
);

errno_t _wfopen_s(
FILE** pFile,
const wchar_t *filename,
const wchar_t *mode
);

raffriff42
17th July 2016, 17:44
Hi shekh, my File/Export submenu goes away (Export has no [>] showing an expandable menu) after I close a source file and reopen the same file or another one. The commands themselves still work if they have hotkeys assigned, but I can't select them from the menu.

EDIT VirtualDub 1.10.4 does not do this, and I'm pretty sure a previous version of VirtualDub FilterMod (earlier than build 37200, the oldest one I have on hand) did not do it either.

shekh
17th July 2016, 18:13
Thanks, I already have it fixed in source code. Before I upload new binaries the workaround is to enter and exit "capture avi".

Done.

shekh
23rd July 2016, 21:43
New version has different build of "caching input driver" with reduced ffmpeg and is XP compatible. Also it is now single module without ffdlls dependency.
However maybe it lost support of some fancy formats, let me know if something should be added back.
I used this config to build ffmpeg

--enable-gmp
--enable-libmp3lame
--enable-libopus
--enable-libvorbis
--enable-libvpx


And APNG support was merged with help of APNG Mod author.
Enjoy :)

StainlessS
24th July 2016, 01:00
Thank you kind sir :)

raffriff42
24th July 2016, 14:19
...APNG support was merged with help of APNG Mod author. Loading an APNG (via drag and drop; sources from APNG Mod and from ffmpeg), I see the first frame only.
EDIT Build 37341 = all good.

Also, a problem with the built-in Resize filter - it previews OK, but output is frozen.

shekh
24th July 2016, 19:34
The latest build is 37341 which includes APNG support
"Error: no information available" is the old VD behavior before latest version, it had no dialog to display for image.

Checked resize: everything seems ok. If you can repeat it I need more detail: preferences (maybe registry export), source file, filter settings.
Did you press "disable output pane" hotkey?

p.s.
Found some trouble with dx9 display in latest version, considered broken.

raffriff42
24th July 2016, 22:20
Disabling 3D filter acceleration (VDXA) did the trick (Preferences/3D Acceleration)
A video driver issue? (I have NVidia, 365.19, 2016-05)

shekh
24th July 2016, 22:57
Disabling 3D filter acceleration (VDXA) did the trick (Preferences/3D Acceleration)
A video driver issue? (I have NVidia, 365.19, 2016-05)

Now I can repeat it. Looks like something changed in the program, not driver.

Reel.Deel
25th July 2016, 13:22
And APNG support was merged with help of APNG Mod author.
Enjoy :)

Thanks :)

shekh
25th July 2016, 20:56
Disabling 3D filter acceleration (VDXA) did the trick (Preferences/3D Acceleration)
A video driver issue? (I have NVidia, 365.19, 2016-05)

Uploaded build 37357

* fixed dx9 display bug
* fixed VDXA (was broken since version 7)

Thanks raffriff42 for report!

18fps
29th July 2016, 08:19
Thanks for this program! I love the fact that I can open a tiff sequence.
Would it by possible to add support also for dpx format (already supported by ffmpeg, as one of the -image2 image formats)?

shekh
29th July 2016, 11:21
Thanks for this program! I love the fact that I can open a tiff sequence.
Would it by possible to add support also for dpx format (already supported by ffmpeg, as one of the -image2 image formats)?

Do you mean opening or saving?
Opening should be already covered by plugin (cch_input.vdf)
If not, post image sample.

18fps
29th July 2016, 13:49
Thank you for pointing to cch_input. I had to edit the ini to add the extension, after that, it works. Very nice!

Myrsloik
3rd August 2016, 12:09
Two small details that are usually just cosmetic but still bother me:
1. Since VapourSynth reports errors the same way avisynth does you'll actually get an error message saying something like "Avisynth error!
<vapoursynth error message here>" because vdub always adds the "avisynth error" even when it's a .vpy file opened.
2. Also because I use the same interface, vdub assumes the error message string always uses the local encoding (like avisynth), this isn't true for vs which passes an utf8 string which then may or may not display correctly.

Not sure what to do about it. I guess one way would be to simply declare a new error reporting interface and try that first.

shekh
3rd August 2016, 14:09
Two small details that are usually just cosmetic but still bother me:
1. Since VapourSynth reports errors the same way avisynth does you'll actually get an error message saying something like "Avisynth error!


I can rename the message to something like "AVI handler open failure:..."


2. Also because I use the same interface, vdub assumes the error message string always uses the local encoding (like avisynth), this isn't true for vs which passes an utf8 string which then may or may not display correctly.


This is bad. Also I am not happy about error message format, would prefer something parseable like


filename.vpy(linenumber) : error bla-bla-bla


VD has very little code around avisynth, basically


extern "C" const GUID IID_IAvisynthClipInfo // {E6D6B708-124D-11D4-86F3-DB80AFD98778}
= {0xe6d6b708, 0x124d, 0x11d4, {0x86, 0xf3, 0xdb, 0x80, 0xaf, 0xd9, 0x87, 0x78}};

struct IAvisynthClipInfo : IUnknown {
virtual int __stdcall GetError(const char** ppszMessage) = 0;
virtual bool __stdcall GetParity(int n) = 0;
virtual bool __stdcall IsFieldBased() = 0;
};

...

mpAVIFile->QueryInterface(IID_IAvisynthClipInfo, (void **)&mpAvisynthClipInfo);


So if you merely clone the same interface with different GUID then I can put different names AviSynth/VapourSynth and do something about character encodings.

May be a better idea to implement input driver based on native VS API but I dont want to do it myself.

Myrsloik
3rd August 2016, 14:22
I'm not sure you'd gain anything from native api support. You don't do prefetching and I don't think there are any relevant formats you can't already open through vfw. Am I wrong?

If not I'll just create a new interface to save some effort.

shekh
3rd August 2016, 15:07
Ok
I have no idea about new benefits, maybe I can make use of some metadata (full range etc). But this can be included in new interface too. And what is prefetching? :)

shekh
14th August 2016, 13:05
Adding "native" support for x264 encoder.

All these formats are supported: yv12, yv16, yv24, rgb (both 8 and 10 bit).
Colorspace options 601/709 and full/limited range for all yuv formats.

"Video color depth" dialog is discontinued, it never made much sense. Now there is separate "Decode format" dialog and "Output format" inside compression dialog.

https://sourceforge.net/p/vdfiltermod/wiki/compression/attachment/compression.png

Internally there is full support for 16 bit yuv formats but I dont use them for anything but output to x264 (may be expanded later).

What is x264 plugin (actually 2 plugins for each bitdepth): this is basically x264vfw from https://sourceforge.net/projects/x264vfw/ with some cosmetic changes:
VFW API is extended to support format negotiation etc.
File output is removed.
Decode support is removed.
Format conversion is disabled (handled by VD).

In fact some arbitrary vfw codec can be simply renamed as vdplugin, this may be useful to have many portable versions of same codec.

Jamaika
14th August 2016, 16:12
Thanks. Certainly come in handy for beginners.
Whining Jamaika:
Lack Rec. 2020
How is the support for above 8bit color depth and rec 2020 in the preview?
Good and it, but I preferred the appearance codec komisar.gin.by.
It could use a codec VP9vfw at youtube.
And what with support GoPro CineForm YUVA4444 / RGBA 12bit?

shekh
14th August 2016, 17:01
Thanks. Certainly come in handy for beginners.
Whining Jamaika:
Lack Rec. 2020
How is the support for above 8bit color depth and rec 2020 in the preview?
Good and it, but I preferred the appearance codec komisar.gin.by.
It could use a codec VP9vfw at youtube.
And what with support GoPro CineForm YUVA4444 / RGBA 12bit?

> Lack Rec. 2020

I think it`s better to make advanced conversion filter for stuff like this (also proper place to do all kinds of dithering). Supposedly a library like zimg already does all math.
Just a thought, I don`t plan to make it today.

> How is the support for above 8bit color depth and rec 2020 in the preview?

Are you asking to actually output high bit depth to display? I don`t have such display and don`t even think about getting one.

Komisar codec is something I considered to look into, after a while.

> It could use a codec VP9vfw at youtube

Not sure what are you talking about. Does VP9vfw exist? Do you have a link?

> And what with support GoPro CineForm YUVA4444 / RGBA 12bit?

Nothing, since it it does not support such formats with vfw codec and is closed source and devs dont even visit their own showcase forum.
Well in fact it has "enable 4444" option which will upconvert 8bit rgb to 12bit rgb. Pointless, huh?

Jamaika
14th August 2016, 19:06
Not sure what are you talking about. Does VP9vfw exist? Do you have a link?
I realize. I can dream. In the same way as the improvement in VirtualDub container AVI, which is obsolete.
It is only outdated VP8vfw but it has currently container webm.

Is this project still current?
https://sourceforge.net/projects/mpxplay/files/x265vfw/

shekh
14th August 2016, 19:43
Is this project still current?
https://sourceforge.net/projects/mpxplay/files/x265vfw/

I wrote here, will see. link (http://forum.videohelp.com/threads/361092-Are-there-any-programmer-who-can-create-vfw-directshow-based-X265-encoder?p=2456061&viewfull=1#post2456061)

b2kguga
15th August 2016, 16:53
Hi shekh

Can you explain a few things about VDub plugin api ? I wanted to know exactly what functions are called when toggle function is activated.

For example, whenever i use the toggle, if preview is enabled these routines are called (In order)

ParamProc, StartProc, RunProc

When i press again the preview (to disabled it), the function EndProc is called.

So,what are the usage and routines envolved with ? UndoSystem RedoSystem, RedoFrame ?

shekh
15th August 2016, 18:20
Did you read PluginSDK.chm? I advise reading it start to end, it has a lot of answers.

Or if you read but don`t understand something specific, ask again with more detail about your problem. Normally all you need to get started is just grab any existing plugin, so your questions are quite disappointing.

> UndoSystem

Never used it, don`t even imagine why it is needed.

b2kguga
20th August 2016, 22:58
Skeh i read it, but i´m having trouble identifying where some routines starts and ends and preview is enabled and the correct usage of RedoSystem. I mean, after using UndoSystem the program seems to start all routines again, but which functions are passed 1st ?

Sorry for the bad english, but it may be better i explain in examples.

I´m giving a try building a new version of LogoAway. So far, the rebuild is doing well. I´m doing it in assembly and debugging it also with my own assembler. One of the things i´m having difficulties to understand is that inside my ConfigDialog it have a call to the toggle function of Vdub.

Apparently it restarts he execution of other Vdub starter functions such as:
RunProc, EndProc, StartProc etc.

I wanted to know the order that these functions are called. This is because the controls i´m using needs the values to be update and, therefore, needed to reload (and destroy) old memory allocated. This is causing the dialog to flick the preview window.


Proc ConfigDlgProc:
Arguments @Adressee, @Message, @wParam, @lParam
Local @mfd, @fa
Uses ebx, esi, edi, ecx, edx

call 'USER32.GetWindowLongA' D@Adressee, &DWL_USER
mov D@mfd eax
(...)
...If D@Message = &WM_COMMAND ; User action

If D@mfd <> 0
call On_WmCommand D@Adressee, D@wParam, D@lParam, D@mfd
Else
xor eax eax
End_If
(...)EndP

; inside WM_Command the controls are used as:

(...)
...Else_If D@wParam = IDC_EDIT_LOGO_BORDER_WIDTH ; Border Size (Width)

call IFilterPreviewUndoSystem D@fa
; ImgWidth= Pos+BorderWidth
lea eax D@lpTranslated
call 'USER32.GetDlgItemInt' D@hDlg, IDC_EDIT_LOGO_BORDER_WIDTH, eax, &FALSE
(...)
call IFilterPreviewRedoSystem D@fa

...Else_If D@wParam = IDC_EDIT_LOGO_BORDER_HEIGHT
(...)
..Else_if D@wParam = IDC_BTN_SHOW_PREVIEW

call IFilterPreviewToggle D@fa, D@hBtn
xor eax eax
(...)



What is happenning is that when i set the new width or height of the logo, the preview is flickering because the plugin is restarted and the memory is allocated/deallocated.


Proc EndProc:
Arguments @fa, @ff
Uses esi, edi, ebx
(...)
; used to deallocate memory
EndP



Proc StartProc:
Arguments @fa, @ff
Local @BWidth, @BHeight, @TmpMemData, @GradientSize, @MemSize2, @MemSize3, @MemSize4, @MemSize5,
@ErrorMessage
Uses ebx, esi, edi

mov eax D@fa
mov esi D$eax+FilterActivation.filter_dataDis
(...)
; this is where to allocate the memory
EndP



Proc RunProc:
Arguments @fa, @ff
Local @ImgWidth, @WithBorderNorth, @WithBorderEast, @WithBorderSouth, @WithBorderWest, @CurSrcframe, @IsKeyFrameSet, @Counter
Uses ebx, esi, edi
(...)
; this is where the plugin actually works.
EndP


The problem is that, when activating the preview the plugin stops the execution, and starts again on EndProc (To delete the memory), StartProc (to allocate the memory again) and on Runproc (to run the previewed data)

I wanted to know the order of the functions where undosystem uses to reload.

I mnean, undosystem seems to run again on all the functions pointed by the FilterDefinition structure, but i´m not sure the order the pointers are being called once undosystem and RedoSystem are activated.



[FilterDefinition:
FilterDefinition.next: D$ &NULL
FilterDefinition.prev: D$ &NULL
FilterDefinition.module: D$ &NULL
FilterDefinition.name: D$ Sz_PluginName
FilterDefinition.desc: D$ Sz_Description
FilterDefinition.maker: D$ Sz_Author
FilterDefinition.private_data: D$ &NULL
FilterDefinition.inst_data_size: D$ Size_Of_FilterData
FilterDefinition.initProc: D$ InitProc
FilterDefinition.deinitProc: D$ 0;DeInitProc
FilterDefinition.runProc: D$ RunProc
FilterDefinition.paramProc: D$ ParamProc
FilterDefinition.ConfigProc: D$ ConfigProc
FilterDefinition.StringProc: D$ StringProc
FilterDefinition.StartProc: D$ StartProc
FilterDefinition.EndProc: D$ EndProc
FilterDefinition.script_obj: D$ VDXScriptObject
FilterDefinition.fssProc: D$ FssProc
FilterDefinition.stringProc2: D$ StringProc2
FilterDefinition.serializeProc: D$ &NULL
FilterDefinition.deserializeProc: D$ &NULL
FilterDefinition.copyProc: D$ &NULL
FilterDefinition.prefetchProc: D$ &NULL
FilterDefinition.copyProc2: D$ &NULL
FilterDefinition.prefetchProc2: D$ &NULL
FilterDefinition.eventProc: D$ &NULL
FilterDefinition.accelRunProc: D$ &NULL
FilterDefinition.mSourceCountLowMinus1: D$ &NULL
FilterDefinition.mSourceCountHighMinus1: D$ &NULL
FilterDefinition.mpStaticAboutProc: D$ &NULL
FilterDefinition.mpStaticConfigureProc: D$ &NULL]


I´m asking this because i want to avoid the flickering and the only solution i can find is making the allocation and deallocation of memory be inside RunProc function using a flag to check if we are really running the plugin or only using it on preview mode.

The documentation says that the place to allocate and deallocate memory is on StartProc and EndProc and maybe i need to do those allocs/deallocs in other places.

This is what i´ve built so far
http://i67.tinypic.com/4vqvxc.jpg

shekh
26th August 2016, 20:49
Fixed some serious bugs
and just another screenshot for completeness

https://sourceforge.net/p/vdfiltermod/wiki/compression/attachment/compression2.png

shekh
8th September 2016, 19:34
Added FFV1/Huffyuv with simple UI (luckily these codecs do not need difficult setup)
Other options in dropdown are 8 bit rgba, yuv420, yuv422, yuv444 (equal for both codecs)

https://sourceforge.net/p/vdfiltermod/wiki/compression/attachment/compression3.png

StainlessS
9th September 2016, 14:12
Ooooh, lovely :)

kolak
11th September 2016, 22:43
ffv1 got 16bit RGB mode in ffmpeg recently if I remember well.