VirtualDub2

[jpsdr]

All my apologies, my bad again (it's becoming quite an anoying habit), i'm very not used to all these new behaviors...
It never cames to my mind that bottom was still active when it wasn't with original (so i didn't even check), neither that right panel could be moved with mouse.
Finaly nothing wrong, so it's perfect.

[LigH]

In the good old VirtualDubMod, saving a screenshot of the currently displayed frame was so easy: Video » Snapshot source frame (Shift+1).

Trying the same in VDubFMod r38543 (32b) ... Video menu: No more matching entry. File menu: Export ... a submenu, that costs me precious time, unless there is a keyboard shortcut assigned; Single image ... no shortcut assigned yet, have to try to assign one later; click. Nothing happens?

Well, let's assign the shortcut. To File.SaveImage – seems valid. Test it ... nothing happens.

Let's try in VDubFMod r38544 (64b) ... pressing shortcut (was assigned for both versions, that's nice): OK, a dialog appears. Exporting a single image works. So it appears to be broken only in the 32b version.

Or is it? Trying again ... this time it works there as well?! Strange. A reliable bug could be found and fixed. But unreliable issues are the hardest. :o

[StainlessS]

Ligh, Menu/File/Export/Save Single Image, for current frame (choice of output formats).

EDIT: Oops sorry, you already saw that, guess I'm in a hurry to get some shut eye and just partially skim read your post.

EDIT: REading a bit more in full
Or is it? Trying again
I think that used to be a problem in earlier versions, thought it got fixed (I'm on 32 bit build 20160407164938).

EDIT:
I've never had that problem for some time, but only just updated to VirtualDub_Pack_38543, I'll keep my eyes open for that problem
re-appearing (used Save Single Image about a half dozen times throughout the night in previous version, no problems).

[LigH]

Yes. As I wrote, it's in a submenu, so navigating the mouse cursor through it takes a lot of time, unless I assign a keyboard shortcut. Please read it again completely, there is more about it.

[shekh]

Yes. As I wrote, it's in a submenu, so navigating the mouse cursor through it takes a lot of time, unless I assign a keyboard shortcut. Please read it again completely, there is more about it.

Yes it is supposed to have a shortcut, since it is also accessible from filter preview and there is no menu.
The logic behind File->Export structure is because Image sequence is also there (and it is very similar).

The bug when it suddenly does not work still exists in all versions and is old, btw in the same situation "copy to clipboard" command gets disabled too.

[jpsdr]

Minor issue i've noticed :
In View->Pane Layout if you select "Auto Size panes" when it's not it's done immediatly. But unselect it has no effect. You have to close VDubMod and restart it unselected to remove the "Auto Size".
And... it's also the case in the original version... Well, i think it's up to you to chose if it's worth fixing or not.

[shekh]

And what do you think it should do? Instead you can begin changing zoom right away.

[jpsdr]

I thought it should go back to what it was previously, but, it's just my thought.

[StainlessS]

Request for change back to VD standard behaviour:

Dont like that VDFM drops display of frames [EDIT: contents] whilst user stepping through the timeline via keyboard [EDIT: right cursor key], you have to stop timeline traversal to see the current frame. (I can see that it is quicker to not display frames during such time, but not if you have to stop to view every frame).

EDIT: Perhaps its an option, if so then make it (standard mode) default.
EDIT: Only happens in heavy filtering scripts that do not play anywhere near real time.

[shekh]

Request for change back to VD standard behaviour:

Dont like that VDFM drops display of frames whilst user stepping through the timeline via keyboard, you have to stop timeline
traversal to see the current frame. (I can see that it is quicker to not display frames during such time, but not if you have to stop to view every frame).

EDIT: Perhaps its an option, if so then make it (standard mode) default.

Definitely not (planned) behavior. IMO step keys are exactly for viewing each frame, no reason to make it quicker.
So this is a defect (in my test it is even worse with old VD)

[StainlessS]

In actual fact I was wrong in what I said in PM to Shekh.

This script exhibits different behaviour in all three, VD 1.10.4, VDMod 1.5.10.3, and VirtualDubFilterMod.

Colorbars.Killaudio.ShowFrameNumber
GSCript("""
Function paws() {
x=0
for(n=1,1000000) { # EDIT: Changed 0 to 1 in Blue
x=x+1
}
return x
}
""")
SSS="""
Return Last.Subtitle(string(Paws()+current_frame))
"""
Return Last.ScriptClip(SSS)


EDIT: when press and hold Right cursor key:-

VD standard does not update either frame contents nor frame number/time on timeline.
VDMod, updates frame contents but not timeline frame number/time.
VDFM, updates timeline frame numbers/time, but not contents.

I'm happiest with current VDMod behaviour, seeing frame contents change but would like both contents and timeline numbers to update.

EDIT: Modify 1000000 to bigger number if fast machine.
EDIT: In all 3 VD apps, updates properly when cursor key finally released.

[LigH]

A beginner in Windows GUI programming would possibly suggest to insert Application->ProcessMessages()/DoEvents() randomly in keyboard event handlers until it works... ;)

But times of "cooperative multitasking" (where threads deliberately idle for others) are probably over.

[StainlessS]

But times of "cooperative multitasking" (where threads deliberately idle for others) are probably over.

A simple Visual Basic program consisting of a forever loop without any DoEvents() used to bring the entire machine almost to its knees in W2K, wonder if W7, W8.1 W10 still have issues, I'm guessin YES. Windoze has always required cooperation irrespective of whatever M$ has pretended.
(EDIT: that was on a UniProcessor system, never tried on MultiProcessor sys)

[LigH]

Windows will still use time slices to schedule several tasks per core. And tight loops will probably still hog at least one core to a point where the task scheduler itself hardly gets a slice, despite several priority classes. But hogging a multi-core system to death should be quite improbable now, as long as you don't fill it with real-time class threads.

I would not be surprised about CPU features supporting task scheduling and thread switching in OS kernels, which are now superior to those in times of CPUs with only (80)x86 numbers as name; I just couldn't point at them, not knowing specific names. Cooperative multitasking may not be "necessary to survive" anymore; but I guess it can still support fluid interaction.

[StainlessS]

I just tried to knock up a VB exe with forever loop, and tried on Multi-Processor system Duel core, 50% CPU hogged on one processor, no seize up problems encountered.
Tried on single physical core P4 with hyper-threading, 50% CPU on one logical core, no seize up.
Tried on P4 with single physical CPU and no hyper-threading, 100% CPU used and again no seizure experienced.
Both P4's used were even over VNC (no monitors nor keyboards attached), and no problems experienced.
Bit of a surprise that we had no problems at all, guess I was totally wrong (all 3 systems XP, so W7+ probably also ok).

EDIT: Just did a reboot, and got alert saying that could not shut down Project1.exe, so I force closed it.
I had forgotten to kill the VB exe after using VNC on P4's (had let it continue whilst using VNC). it was
no problem at all to the point that I forgot that it was running.

[LigH]

As suspected: user ring (3) processes may not anymore be able to suppress kernel ring (0) processes; task switching will have a superior priority. Somehow. Someone may know its name. But we should stop detrailing this forum thread...

[shekh]

But we still have plenty of ways to knock the system. Simple example: x64 process can infinitely allocate memory. Try it. Try to kill it.

[Jamaika]

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)
New codec vfw X265. ;)

[shekh]

Uploaded new version (15)
Single-stepping refresh is also fixed, and some other suggestions.

About experimental stuff: it has more trouble than I expected, so leaving in quite unfinished state now.
It is possible to save Utvideo\MagicYUV\FFV1 and the like to mkv, mov.
It is possible to use AAC encoder and save to ffmpeg formats (avi too). Will accept any type of samples.
Using legacy acm codecs with ffmpeg formats is not possible at all (likely will never be).
Using x264 encoder when writing to ffmpeg formats is something I hope to sort later.

[v0lt]

shekh
Thank you very much for the opportunity to be saved in MKV, MP4 and MOV.
:thanks:

[StainlessS]

Great stuff, cheers Shekh :)

[Reel.Deel]

Uploaded new version (15)

Thanks! I like that you combined the 32 and 34-bit versions into 1 package. Make it more convenient. :)

[LigH]

I don't like that they are mixed in the same directory. Please keep them at least in separate subdirectories; people can umpack as they like, but sorting them out is annoying.

Anyway, thanks for another update. :)

But somehow I do not yet understand how to export a video with x264, if not via "external encoder". The description sounds as if there is some internal support. But I missed it so far.

[shekh]

I don't like that they are mixed in the same directory. Please keep them at least in separate subdirectories; people can umpack as they like, but sorting them out is annoying.


Damn. Why exactly do you need to divide them? There is one VirtualDub.chm instead of two.
Maybe shared jobs/autosave can make some trouble, is it the case?


But somehow I do not yet understand how to export a video with x264, if not via "external encoder". The description sounds as if there is some internal support. But I missed it so far.

Interesting. Can you follow screenshots on this page: https://sourceforge.net/p/vdfiltermod/wiki/compression/
I deliberately put internal encoders at top to make them easier to find..

[shekh]

How the name "Veedub64.exe" was invented?
For me it seems ridiculous, why not VirtualDub64.exe? :)

[LigH]

Veedub64.exe already existed this way when made by Avery Lee.

Ah, they are in the same list as the VfW codecs, that's why I did not look there...

[v0lt]

For me it seems ridiculous, why not VirtualDub64.exe? :)
This is your fork. You can change the name to more clear.

[dipje]

Neat Video got updated to 4.5, and apparently the Virtualdub version now supports Virtualdub FilterMod. You're getting noticed :P.

[shekh]

Neat Video got updated to 4.5, and apparently the Virtualdub version now supports Virtualdub FilterMod. You're getting noticed :P.

Does not seem to add anything specific yet, so probably just a declaration of compatibility.

[Gromozeka]

shekh
Thank you very much.
output mkv forever!

[Gromozeka]

WNR 0.1 not worked in virtualdub filtermod

[shekh]

WNR 0.1 not worked in virtualdub filtermod

I tried it with official VD 1.10.5 and it had problems too. Does not crash immediately but the output is not consistent (which is enough indication that the filter is broken).
Unless you find source code there is nothing to do with it.

[Gromozeka]

Unless you find source code there is nothing to do with it.

Sorry. I don't have the source code WNR 0.1 :(
It's a pity that the wavelet technologies hasn't found the future development

[Reel.Deel]

@Gromozeka

Don't know how they compare to WNR but there's a couple of wavelet denoising plugins for AviSynth: VagueDenoiser (http://avisynth.org.ru/vague/vaguedenoiser.html) and WaveletReducer (http://forum.doom9.org/showthread.php?t=86081).

[Gromozeka]

@Gromozeka

Don't know how they compare to WNR but there's a couple of wavelet denoising plugins for AviSynth: VagueDenoiser (http://avisynth.org.ru/vague/vaguedenoiser.html) and WaveletReducer (http://forum.doom9.org/showthread.php?t=86081).

thanks, I know about it

[jpsdr]

Discorver a big critical issue. I can't open avs file, i have always an ffmpeg error message telling me "unable to open file", when the same avs file opens perfectly with standard VDub.

[LigH]

AviSynth files should be opened using the AviSynth API, maybe VfW, but not via ffmpeg plugin, I believe ... is it possible to enforce the use of ffmpeg input even when it may not be appropriate?

[shekh]

Discorver a big critical issue. I can't open avs file, i have always an ffmpeg error message telling me "unable to open file", when the same avs file opens perfectly with standard VDub.

Did you change priority in cch_input.ini? Eg "default = 1" or anything above -5 makes such effect.
Initial config should work (just checked).

Opening avs with ffmpeg is possible in theory, but I disabled avisynth when compiled ffmpeg so it should never work.

[jpsdr]

I didn't change anything, just updated from 14 to 15. And i don't want ffmpeg to open avisynth, i still want internal VDUb Avisynth API to open it.
I'll do more checks/tests on several PCs later, when i'll have a little time. But saying "I disabled avisynth when compiled ffmpeg so it should never work", do you mean that ffmpeg is "included" within VDubFilterMod, when not in VDub. What plugin is it ? I can check if removing it solve the issue. What's strange, it's that i've opened avs scripts before with version 14.

[LigH]

Yes, VDubFilterMod includes an ffmpeg based input filter (plugins[32|64]\cch_input.vdf). AviSynth scripts (*.avs) are not included in its file mask. They open fine in my installation of v14. They also open fine in v15 (I separated 32 bit and 64 bit files, but that may not be necessary, as their file names are all distinct).

If you have only a 32 bit version of AviSynth installed, and try to open an AviSynth script in VeeDub64.exe, it may fail, but I would be surprised if it tried to open it "desperately" in the ffmpeg input plugin.

[jpsdr]

Thanks, i'll do some tests later when back home.

[shekh]

FFMPEG base input is within avlib-1.vdplugin now, was named cch_input.vdf before.
If AviSynth is not installed, should give this error: AVI Import Filter error: (Unknown) (80040154)
If you delete cch_input.ini or put wrong priority in it: FFMPEG: Unable to open file.
Check if you have cch_input.ini in plugins32 and plugins64 folders.

internal avs/vpy has priority of -4
default for ffmpeg is set to -5 in ini to allow avs before it

[jpsdr]

I have both... : cch_input.vdf and avlib-1.vdplugin. Removing avlib-1.vdplugin solved the issue.
Keeping cch_input.vdf alone no issue, both issue, only avlib-1.vdplugin issue.
I have the .ini, and priority is -5.

Edit :
Ok...! I put the .vdf in "plugin", and the ".vdplugin" in "plugin32/64".
The cch_input.ini was, and stayed in the "plugin", so probably the avlib-1.vdplugin didn't find it in plugin32/64... I would never found out that the cch_input.ini was for avlib-1.vdplugin...

[LigH]

But that's the newer plugin. You should have removed the older cch_input.vdf instead.

[jpsdr]

And if both old an new were present it's because i've overwrited the old files with the new files, not deleted everything before copying...

[jpsdr]

BTW, isn't finaly this plugin the same as this one (https://sourceforge.net/projects/virtualdubffmpeginputplugin/files/?source=navbar) ?

[shekh]

BTW, isn't finaly this plugin the same as this one (https://sourceforge.net/projects/virtualdubffmpeginputplugin/files/?source=navbar) ?

Are you asking about features or ...?
Apparently my plugin is developed by me and the quoted one is not. They have some common history long ago.

[jpsdr]

Yes, just about features. I have the feeling that both are doing (or are for) the same thing, meaning it would probably be useseless to have both installed, so having to choose which one i install.

[LigH]

In general, you may be right. VirtualDub originally could only handle AVI files. The demand to at least import, if not even export different formats, grew in the last years. Modifications appeared. Then Avery Lee implemented plugin interfaces and support for external encoders. shekh will surely have adapted a previous simple ffmpeg all-purpose input plugin to a central feature, supporting the extended color models and filter modes of the core application as well.

[jpsdr]

That's what i've thought just afterward. The "other" plugin may probably output allways 8bits even if the input is an mkv or a mov with a 10bits video/codec, when shekh's codec may output 10bits supporting the extended color models he added.