VirtualDub2

[lansing]

Docked - what does it mean? Some screenshots may help.
In windows 7 or later, when you drag a window to the left/right edge of the screen, the window will auto maximize and take up half the size of the screen. Well that was just an example, basically, the filter preview window will not show up if you move the main window anywhere to the left side of the screen.



And why you do that? Because right side is for browser to assist with drag-n-drop or something?

Just to explain my decisions:
- I never use shrinked main window except for testing. I made "maximize" option to get rid of title bar, and plan to acquire some remaining non-client space eventually.
- I assume if someone moved/shrinked main window, they want dependent windows be positioned/shrinked the same way.


um...because I multitask and sometime I don't need it. If I wanted to see a before/after effect, I would set a hotkey for toggle screen and tap it when I needed it.


Last time I checked (year ago?) it wasn't working.
Ok so I'm not going to bother with AVS+ then, it's giving me a headache.

[lansing]

I tried to open a vapoursynth script with 10 bit video output and I got an error "couldn't locate decompressor for format 'P010' (unknown)"

[shekh]

I tried to open a vapoursynth script with 10 bit video output and I got an error "couldn't locate decompressor for format 'P010' (unknown)"

https://sourceforge.net/p/vdfiltermod/wiki/format_changes/#deep-color-input-options
not implemented yet

[lansing]

https://sourceforge.net/p/vdfiltermod/wiki/format_changes/#deep-color-input-options
not implemented yet

ok thanks

[lansing]

Hi, there's a bug in the capture mode. Every time I go to video->levels, the white balance will always reset to the far left of the bar, and a new ui window will come up each time

[shekh]

Hi, there's a bug in the capture mode. Every time I go to video->levels, the white balance will always reset to the far left of the bar, and a new ui window will come up each time

Hi. It can help understanding if you make a screen recording of what is going on. However I don't remember myself touching that, do you see the same problem with classic vd? Also probably this is driver specific and hopeless. What is the capture device anyway?

p.s. Ok, the part with multiple windows is clear now, very simple :)

[lansing]

Hi. It can help understanding if you make a screen recording of what is going on. However I don't remember myself touching that, do you see the same problem with classic vd? Also probably this is driver specific and hopeless. What is the capture device anyway?

p.s. Ok, the part with multiple windows is clear now, very simple :)

Yeah this problem exist for a long time. I'm using a Logitech webcam, I can adjust the camera level through either Logitech's own "capture filter" or the level setting in Virtualdub, I like the latter one better because it has more controls. Every time I opened the levels window, the white balance will reset, it doesn't remember my previous setting, and my whole screen will turn blue-ish.

http://i.imgur.com/JVjPA74.jpg

[lansing]

Hi I have seeking problem with version 16. On a 1080p mkv, memory usage spiked to 100% and the program hangs when I tried to seek. On a blu-ray TS file, seeking will sometime give me an error "error reading source frame xxxx: requested frame not found"

[shekh]

Hi I have seeking problem with version 16. On a 1080p mkv, memory usage spiked to 100% and the program hangs when I tried to seek.


Can you share the sample?


On a blu-ray TS file, seeking will sometime give me an error "error reading source frame xxxx: requested frame not found"

This is planned behavior with some unlucky files. AFAIK TS lacks information for simple seeking, and I use just simple seeking as implemented in ffmpeg. Other possible reason: no keyframes in the file (intra refresh). Same story, simple seeking is not able to reach exact frame.

[lansing]

Can you share the sample?



Oh I make a wrong description, the one that spikes up on seek is the cpu usage. Sample here, it's 720x546, seeking seems to work fine for the first 1:52, then any seek after that will spike cpu usage to 100%

sample (http://www.mediafire.com/file/dpv1cthi146a5q6/vd_test.mkv)

This is planned behavior with some unlucky files. AFAIK TS lacks information for simple seeking, and I use just simple seeking as implemented in ffmpeg. Other possible reason: no keyframes in the file (intra refresh). Same story, simple seeking is not able to reach exact frame.

This happens to all my TS files, it either gives me this error or it just shows like 5 frames.


Another problem I saw, on a 1920x1080 x264 10 bit mkv, memory jumps to 3.2G on a few random seeks and capped there.

With a 1920x1080 x264 8 bit mkv, memory usage will cap at 1.6G on the same procedure.

And for both type above, clicking the play0 button will kind of froze the program. It didn't hangs but the program didn't respond to any command after.

[shekh]

Oh I make a wrong description, the one that spikes up on seek is the cpu usage. Sample here, it's 720x546, seeking seems to work fine for the first 1:52, then any seek after that will spike cpu usage to 100%


Looks like "hangs" here is wrong too. Yes it takes time to decode but eventually it does finish.
I know one problem which I may try to solve: currently "caching input driver" does not allow to abort decoding. This can make a difference if you request one frame, and immediately request another. With fcchandler mkv driver you can do this, gui will appear more responsive, but to get any picture displayed you actually have to wait. It is a 250 frame gop.
Btw it may help if you see keyframes, press edit->markers from keys.


Another problem I saw, on a 1920x1080 x264 10 bit mkv, memory jumps to 3.2G on a few random seeks and capped there.

With a 1920x1080 x264 8 bit mkv, memory usage will cap at 1.6G on the same procedure.

And for both type above, clicking the play0 button will kind of froze the program. It didn't hangs but the program didn't respond to any command after.

Nothing wrong about memory. With long gop and large frames it can take all your memory. You can see about memory use in "file information" dialog.
"didn't respond" is not good, did you have to terminate the process? How much memory you had (total physical)? Maybe OS tried hard to swap out to disk?

[lansing]

Looks like "hangs" here is wrong too. Yes it takes time to decode but eventually it does finish.
I know one problem which I may try to solve: currently "caching input driver" does not allow to abort decoding. This can make a difference if you request one frame, and immediately request another. With fcchandler mkv driver you can do this, gui will appear more responsive, but to get any picture displayed you actually have to wait. It is a 250 frame gop.
Btw it may help if you see keyframes, press edit->markers from keys.



Nothing wrong about memory. With long gop and large frames it can take all your memory. You can see about memory use in "file information" dialog.


The sample is only 3 minutes out of a 2 hours long video. On the full video, one random seek will hangs the program for 3+ minutes, I lost patient after the 3 minute count, so the actual decoding time could be double or triple. And this problem only happens to a few of my videos, the rest seeks very fast.

I tried the same video on Avidemux, it only took about 6 seconds to create the index, and after that every seek and playback is instant displayed. And in comparison, the memory usage in Avidemux is significantly lower too. With a 1080p video, it needs no more than 170MB.

"didn't respond" is not good, did you have to terminate the process? How much memory you had (total physical)? Maybe OS tried hard to swap out to disk?

I have 16G RAM. I think it has to do with needing more time to decode, the same as the seek problems

[LigH]

Having a video without a (valid) keyframe index is a quite probable reason for seeking issues, especially when the video stream has timecode discontinuities. You said it was better after Avidemux reconstructed such an index. Just remultiplexing the MKV might fix it.

TransportStreams don't store such an index at all, here the playback can only rely on video stream timecodes, and when the whole file is concatenated from different "programmes" with individual timecode ranges, then an "accurate" seeking will search the wrong offset forever (a "lazy" seeking would just play the next possible position based on the percentage of the file size).

[shekh]

On a second look at "vd test.mkv" I see interesting problem. To reproduce: open, go-to frame 10000, see file information. It shows 10002 frames decoded vs expected ~250.
Now it is clear that when you seek 2 to hours into the video it wants to decode all 2 hours.
So it looks like some index heuristic failure. Maybe possible to fix.

[lansing]

Hi I found another bug, the "swap input/output pane" function doesn't work if the size of the input pane is bigger than the size of the program window

[shekh]

Hi I found another bug, the "swap input/output pane" function doesn't work if the size of the input pane is bigger than the size of the program window

fixed

[lansing]

I got a problem outputting Lagarith RGB compression. In the Lagarith setting, I set it to output RGB, but back at the compression selection window, the autoselect was forcing the output to YUV420.

[shekh]

"Autoselect" option is based on input format, if you don't want it just select "24 bit RGB" or anything else.

[lansing]

That autoselect option should also take consideration on what the individual compression codec uses as output, the users shouldn't need to do the same selection twice.

[jpsdr]

I don't know if a codec has the possibility notify a "prefered" output format, or if you have access to the "internal" native compression format. From what i've understood (if i'm not wrong), you ask a codec if it can output a specific format, and it answer yes or no. So probably autoselect ask for the the format in a specific order, and stop at the first "yes" answer. Setting Lagarith to ouput RGB doesn't mean it forces RGB, it probably means it will answer "yes" if you ask "Can you output RGB".
I think it works like this, but shekh should confirm if i've not said something wrong.

[shekh]

Yes, entire "output pixel format" selection is a workaround for VFW codecs. VFW defines no protocol to find out what format codec "wants" as the input.
With updated codecs like x264 I move the format decision to codec itself so there is no need and possibility to repeat this selection in vdub gui.
In theory, I could also do it for the lagarith codec, but in reality I don't want to spend time on it. Btw what is the benefit of lagarith vs utvideo?

Maybe good idea to rename "autoselect" to something less misleading. For me "auto" sounds like "smart choice/do not touch".

[StainlessS]

Btw what is the benefit of lagarith vs utvideo?

Well one is much smaller file size where many duplicates (some kind of repeat frame flags).

[lansing]

I ran into another problem, I have an old xvid+mp3 avi file, but the program is reporting as a mpeg4 stream and won't let me cut it with direct stream copy. I'm getting the error "The source video stream uses a compression algorithm which is not compatible with AV files". It works fine with the original Virtualdub.

[shekh]

Just press ctrl+o (file->open) and change input driver to AVI. You will get the original direct copy behavior.

[lansing]

Just press ctrl+o (file->open) and change input driver to AVI. You will get the original direct copy behavior.

Ok it works now.

[angelxesone]

Hi Shekh..hi all..

Is there an option to the caching input driver to limit the amount of RAM to be used, or maybe how many frames it can cache?

I keep reaching my max RAM when doing full encodes, and seeing "out of memory", "thread not cycling", "stuck when trying to abort" and other errors.

It keeps eating RAM even doing full encodes in batch mode, which if I remember reading somewhere, should disable the caching, CMIIW.

Also, using the caching driver, when opening different video files it shows different max RAM / frames to cache for each video. How is this calculated? My guess is it's about the GOP size or something, I don't really understand how it works, sorry. Sometimes it's as small as 100MB with 50 frames, and the largest I've seen is 6GB with 500 frames on UHD videos (on my 16GB RAM machine).

I'm sorry if this is a stupid question, but I've read this thread (albeit speedily) and I cant find an answer to my problem.

BTW I'm doing encodes on a few (old, I know) Windows Server 2008 with 4GB RAM each. And doing 4K UHD encodes is killing the memory after a few minutes.
Right now I'm back using avisynth and it works great on 8bit sources, even UHD ones. When I'm seeing 10bit sources... I'm stuck.
Also with the old Windows Server, compability problems arise when I'm searching for (modern) tools on video encoding. (even using win xp compatible x265 builds)

Thank you for any advice.

[shekh]

Actually I also run in trouble with some UHD, and thinking to add this option for max RAM. Currently the limit is based on total physical RAM and there is no way to change it.
It finds the maximum GOP length and assumes twice as much (but not less than 32) as desired cache size. Of course this caching is useless during encoding, but something prevents disabling it, I don't remember. Will look again.

[shekh]

With new version the RAM used by input driver is much smaller. There is option for cache size (default is 0.5 Gb) and an option to disable cache per file.
Also the cache shrinks automatically during encoding operation.

Other news: DIB format support is expanded with P010, P016, v410, Y410, r210, R10k.
Test modes (Tools->Create test video) can create 16-bit color cube etc. Also with alpha.
New internal filter DrawText works with: RGB 8, RGB 16, YUV 8, YUV 16, 4:4:4, 4:2:2, 4:2:0, full range, limited range, ...

Changed behavior of preview.
Old (wrong) behavior:
1) during preview the time slider runs ahead of actual displayed frame (+2 frames or something).
2) when you stop preview, the displayed frame would catch up the timeline (therefore it never stopped where I wanted).
Now it is all nice.

[LigH]

:thanks:

Optimization is always useful.

[angelxesone]

Thank you so much shekh for the caching driver update..
it works perfectly now, no more memory problems on UHD encodes..

[lansing]

I tried to frameserve a video in vd, I followed the instruction and installed the 64 bit version dll with the frameserver64.reg, I saved the frameserver file as avi. But the only program that can load the avi file is another instance of the vd filtermod itself, I couldn't open it with other programs.

[shekh]

I had same experience some time ago (with original VD). Also tried vfapi codec.
The target application must use avifile api or at least vfw api. I don't know the list of programs that support it. After effects: no. Vegas: no.
I even thought to ditch frameserving support alltogether, but it seems there is still some way to use it (from VD to Avisynth?)

[stax76]

in case somebody interested in frameserving from VD to staxrip:

https://github.com/stax76/staxrip/issues/159#issuecomment-299569068

[lansing]

I had same experience some time ago (with original VD). Also tried vfapi codec.
The target application must use avifile api or at least vfw api. I don't know the list of programs that support it. After effects: no. Vegas: no.
I even thought to ditch frameserving support alltogether, but it seems there is still some way to use it (from VD to Avisynth?)

After more testings, the 32 bit version of avisynth+ and vapoursynth also works, don't know why the 64 bit doesn't.

[shekh]

After more testings, the 32 bit version of avisynth+ and vapoursynth also works, don't know why the 64 bit doesn't.

Just tried, all works through VapourSynth.
Check your setup procedures (in any order):
1) apply frameserver64.reg
2) copy vdremote64.dll, vdsvrlnk64.dll to system32
3) copy vdremote.dll, vdsvrlnk.dll to syswow64

Step 3 seems already ok for you but 1&2 maybe failed.
You should perform procedures using win64 compatible software. To be sure, try with explorer.

[lansing]

Ok I figured out my problem, it was caused by the teracopy program I use not copying the file to the system32 folder and giving me wrong feedback about the file existed in the folder already. Now both vapousynth and avs+ 64 bit version works.

[lansing]

The "filter chain" in capture mode seems to be broken for a long time. I tried to brighten the shadow part of my webcam capture by raising gamma, but there's no gamma slider in the "levels" setting, then I tried to do it with the gamma on the vd's levels filter, but the filter chain doesn't work...

[shekh]

Are you sure it is different from the original? It works for me, but for some reason I have to
* enable filter
* enable filter chain
* enable preview mode
* set preview acceleration to "something progressive"

I don't know why it is so difficult :)

[lansing]

Are you sure it is different from the original? It works for me, but for some reason I have to
* enable filter
* enable filter chain
* enable preview mode
* set preview acceleration to "something progressive"

I don't know why it is so difficult :)

Oh it works. I was setting the video mode to "overlay" the whole time. That solved a long time mystery to me. Thanks.

[Ben_Nicholls]

Been using this for a while. Can safely safely say it is as stable as any other build!

[Emulgator]

Hi shekh, many thank for your continued work !
While starting your newest 32bit build 40463 on my Win7U64 SP1 a fault window popped up:

"Unable to locate svml_dispmd.dll..."

The main window starts nevertheless with a small delay.
I did not do any further testing, just to let you know...

-----------------------------------------
P.S. Going back in history:
From your available (to me) VD builds:
32bit Build 38098 is the last that does not throw this fault.
32bit Build 38401 starts to introduce that fault.
64bit Builds (Veedub64.exe) are unaffected.
---------------------------------------

I quote from

https://software.intel.com/en-us/forums/intel-c-compiler/topic/285859


alienskinsoftware
Tue, 01/04/2011 - 11:49
Hi, I have building a project on my development machine using the Intel Compiler.
I can run the application fine but when I give a build to someone that doesn't have the development environment,
they get an error locating the dll svml_dispmd.dll.
If I explicitly link with svml_dispmd.lib, the error goes away but I would rather not have to complicate our build.
Also, this error seems to be new. Does anyone have any ideas what might have caused this?

Thanks
[Status Points: 655 (Total Points: 51,185)]

----------------------

Jennifer J. (Intel)
Tue, 01/04/2011 - 13:02

This is expected.

On the non-development machine you need to install the redistributables from here
http://software.intel.com/en-us/articles/redistributable-libraries-for-the-intel-c-and-visual-fortran-composer-xe-for-windows/.
Make sure to test the right version of redistributables.

13 updates listed beside the RTM. ouch...

[shekh]

Very strange issue. No module links to svml_dispmd.dll and I do not use Intel compiler.
Some ideas:
check that you get archive prepared by me (there are some other which I don't track).
Try deleting plugins.
If there is chance to save advanced error log, post it here.

[Emulgator]

Now that I have thrown a DV-AVI video on that 32bit VD build 40463 window the fault message did not come back again.
No big changes, just put Gunnar Thalin's Deshaker plugins 32 and 64 into plugin folders 32 and 64
and ran both VD 32 and 64 just for fun.
And I remember now to have used the 32 bit versions above 38401 with success before.
Must be something fishy on my particular system's side.
Will test on 4 more systems.
Sorry for the inconvenience, shekh and: большое спасибо !

P.S: All VD archives were downloaded from sourceforge.

[shekh]

Did I say in message #1 I wanted CineForm? :)
https://sourceforge.net/p/vdfiltermod/wiki/cineform/

[Emulgator]

You da man !

BTW, I have a testfile here (.mp4) rendered straight out of Sony Vegas Pro 13
which makes VD preview window exhibit a horizontal pixel shift of x:=(x+2) per line, but only if VD window has focus.

If a different window obtains focus, VD windows shows correct preview. The same source decodes in MPC-HC, MPC-BE under LAV fine.
Win7U64 SP1, nVidia Quadro K5000M, driver 372.95

Affected: 40539, 40463, 40464
Not Affected: 40538...

Eek, thats fishy: The same version can work and not work. I happened to hit F1 and the behaviour changed. Gah.
Maybe my side again ? Unfortunately the other systems are out of reach now. The svml_dispmd.dll window came back.
Interference on my systems side, but by whom ?...

General
Complete name : F:\V13 Wanja Teaser.mp4
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42 (mp42/isom)
File size : 16.1 MiB
Duration : 1 min 20 s
Overall bit rate mode : Variable
Overall bit rate : 1 665 kb/s
Encoded date : UTC 2017-05-17 13:57:45
Tagged date : UTC 2017-05-17 13:57:45

Video
ID : 2
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3
Format settings : CABAC / 3 Ref Frames
Format settings, CABAC : Yes
Format settings, RefFrames : 3 frames
Format settings, GOP : M=4, N=15
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 1 min 20 s
Bit rate mode : Variable
Bit rate : 1 533 kb/s
Maximum bit rate : 2 000 kb/s
Width : 854 pixels
Height : 480 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 24.000 FPS
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.156
Stream size : 14.8 MiB (92%)
Language : English
Encoded date : UTC 2017-05-17 13:57:45
Tagged date : UTC 2017-05-17 13:57:45
Color range : Limited

Audio
ID : 1
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : mp4a-40-2
Duration : 1 min 20 s
Bit rate mode : Constant
Bit rate : 128 kb/s
Channel(s) : channel0
Channel(s)_Original : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 1.23 MiB (8%)
Language : English
Encoded date : UTC 2017-05-17 13:57:45
Tagged date : UTC 2017-05-17 13:57:45

[shekh]

Do you have "using overlays" in display options? Overlays often are buggy in drivers/hardware.

[Emulgator]

Overlays are disabled in VD. Will try soon in WinXP32SP3.

[Emulgator]

WinXP32SP3: I tested 23 VD 32 bit versions from 35491 to 40538.
All do work properly and preview that 854x480 pixel .mp4 source without skewing.

Back to the infamous Win7U64SP1 system:
With almost all 32 bit VD versions (20 of 23) the testfile triggered that preview-skewing-while-focus by 2 pixels per line
Only the three VD32 versions that throw the missing svml_dispmd.dll fault were exempt from that behaviour:
37277, 37285 and 37341.
(37341 under WinXP32SP3 showed a nice artistic layered memory delay effect when scrubbing through timeline.)

While trying other sources it became obvious that only .mp4 sources that have a width not divisible by 4
would trigger that preview-skewing-while-focus by 2 pixels per line on that particular system in VD.
(854 width :4 = 213,5 This yields 2 pixels overflow)
(630 width :4 = 157,5 This yields 2 pixels overflow)

.mp4 sources with width divisible by 4 do preview-while-focus/play without skewing.

[Your hint regarding overlay seems to hit the nail. There is definitely something going on like this.
Sometimes on focus changes the screen is built up new for a split second.
For instance starting and closing TotalMediaTheatre5 leaves me with a desktop and windows changed.
All occurrences of Tahoma fonts replaced by the Win7 Standard font SegoeUI.]

Soon I will try on a different Win7U64SP1.

shekh: Many thanks for your PM in Russian !
While this is not my native tongue, I only seem to remember some phrases from school,
not sufficient for our technical conversation. But I used Google Translator with good success.

[shekh]

oops. Thought you are russian because of "большое спасибо" :) Never mind.
Waiting your mp4 sample and settings..

Well I tried different things and saw skewing with OpenGL display. Are you using that?

[Emulgator]

Updated to nVidia 388.16: No change.

OpenGL: Yes, I had that ticked. Unticked: Fault gone ! Congratulations ! поздравление !
(I had 7 years russian in school, slowly finding that back)