VirtualDub2

[shekh]

Originally Posted by raffriff42

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]

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]

Originally Posted by 18fps

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]

Thank you for pointing to cch_input. I had to edit the ini to add the extension, after that, it works. Very nice!

[Myrsloik]

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]

Originally Posted by Myrsloik

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:..."

Originally Posted by Myrsloik

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]

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]

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]

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.



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]

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]

Originally Posted by Jamaika

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]

Originally Posted by shekh

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]

Originally Posted by Jamaika

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

I wrote here, will see. link

[b2kguga]

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]

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]

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

[shekh]

Fixed some serious bugs
and just another screenshot for completeness

[shekh]

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)

[StainlessS]

Ooooh, lovely

[kolak]

ffv1 got 16bit RGB mode in ffmpeg recently if I remember well.