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

albino
15th September 2019, 22:13
I've never seen an actual camera that records dupe frames, other than maybe the 23.976 -> 29.97 thing I mentioned before, but there you go! Learn something new every day I guess :D

shekh
15th September 2019, 23:51
If anything else fails ... try ffmpeg.
And indeed:
https://stackoverflow.com/questions/37088517/ffmpeg-remove-sequentially-duplicate-frames

And it works!
But if the criterion to remove is content based:
How to distinguish dupes from non-motion?
My genius idea for that:
Having a close look at the audio stream (if present).
But: the audio is quite unimpressed at times with dupes.

The only possible solution seems for me a filter (like Remove Frames),
that combines both - contents comparison and frame number pattern, like:
"Remove duplicate frames that appear in most times (= "fuzzy logic") regulary."
This should do the job.

Quick idea: 2 or more consecutive dupes are non-motion :)

nji
16th September 2019, 08:27
Hi shekh.

Yes, a very quick idea indeed :)

I agree:
2 or more consecutive dupes will probably be non-motion.
Probably.
But most (?) non-motion will be only 1 dupe.
Probably.
==> That's no reliable criterion to distinguish non-motion from
"generated" dupes.

To distinguish them one probably has to have a look WHY these
dupes are generated.
As I'm the opposite of a prof, I don't know much about all that matter.
But as there is a "nearly" kind of regular pattern, I do assume
it has to do with the cameras' firmware, or with some strange intermediate
frame rate conversion.
Maybe the cameras' "natural" framerate doesn't match with the wanted
or the audio resolution. So they insert (more or less) regulary frames
to match it? Or something like that.

If you assume that kind of cause, the algorithm I proposed above
(combination of content comparision and "fuzzy" pattern)
should do the trick. Kind of "adaptive pattern" mode in jpsdr's filter.
It doesn't remove the non-motion dupes (as ffmpeg does).
And it doesn't "de-sync", when the inserted-frame-pattern shifts (as jpsdr's
Remove Frame does).

But maybe someone should look, if he has this effect in his (older)
movies too... (Surprise-surprise).

nji
16th September 2019, 17:28
Having had a closer look on the matter, I'm suspicious
if the duplicate frames actually are simple added,
or if they stand for a kind of "dropped frame" the
camera hardware wasn't quick enough for, and so inserted
a duplicate to stay in sync.
(Maybe there is someone here who knows if that was done sometimes?)
I tried to estimate it by the motion (and a possible "jump" next
frame of a dupe), but I'm not sure.
If that should be the case then removing the dupes would be wrong
(Except at the simple pattern of a dupe every other frame).
An improvement in that case would still be possible
by replacing the duplicates by a "temporal mean" of it's neighbours.

In both cases (true dupe or compensation for dropped frame)
there remains the problem of identifying the dupe positions.

It can't be possible that the positions are arbitrarily.
So I had a closer look to that too.
And indeed, not for all duping movies, but for the majority I found
that the period p (dupe at last pos) of dupes is not constant but more complex.
It is n times p, then (p+1), then n times p again, then... etc.
I.e. the "real period" is n*p + (p+1).
Starting at an offset.

If (!) the task is to remove the frames this can't be removed by jpsdr's Remove Frame.
In ONE go.
But in (n+1) goes!
First go: offset, period: n*p + (p+1), frame at pos. p
Second go: offset, period: p - 1 + (n-1)*p + (p+1), frame at pos. (p-1)+p
(n+1) go: ...
Not very cool I admit.
And one has to find out the pattern, and if it holds until to the movie's end
by having a close look at the frames.
(I really hope not be completely wrong with all that ;-)

shekh
16th September 2019, 19:31
nji

Maybe it won't hurt to post a sample in videohelp restoration subforum. Some people there do exactly that for decades, remove artifacts from old videos. You will likely get a great description how your video was made and plenty of ideas )

nji
16th September 2019, 19:50
Yes, I will do that.
https://forum.videohelp.com/threads/394366-Duplicates-Frames-Cause-and-means#post2560347

Actually I already thought to myself that my question is too specific for this VD2 subforum.
Thanks for the ideas everyone!

nji
18th September 2019, 20:48
Is there an up-to-date reference for writing filters.

http://www.virtualdub.org/filtersdk.html

seems to be out-dated.

Thanks - Greetings.

videoh
18th September 2019, 20:58
That page does not seem outdated. SDK 1.1 is the latest as far as I know. The .chm help file in the ZIP does appear outdated, but still useful. Fortunately, the ZIP file includes a src directory with sample filters written for SDK 1.1.

nji
18th September 2019, 21:33
:thanks:

shekh
18th September 2019, 21:34
Is there an up-to-date reference for writing filters.

http://www.virtualdub.org/filtersdk.html

seems to be out-dated.

Thanks - Greetings.

You can find sdk 1.2 and some comments about my new added stuff here: https://sourceforge.net/p/vdfiltermod/wiki/sdk/

By most part the old sdk still works unless you need support for something very specific.

(sdk 1.2 is also old, just a bit newer than 1.1)

videoh
18th September 2019, 21:45
Cool, Shekh, thanks. I was not aware you had done all that work. Bravo!

StainlessS
21st October 2019, 07:21
Hi Shekh,
qyot27 posted AviSynth+ 3.4.0, https://forum.doom9.org/showthread.p...02#post1888102
breaks VD2, bring up script editor, bang! [access violation]
VD2 will not be the only affected software, I expect there will be more probs.

Groucho2004
21st October 2019, 09:22
Hi Shekh,
qyot27 posted AviSynth+ 3.4.0, https://forum.doom9.org/showthread.p...02#post1888102
breaks VD2, bring up script editor, bang! [access violation]
VD2 will not be the only affected software, I expect there will be more probs.It works fine when you install the non-GCC version.

StainlessS
21st October 2019, 09:31
Thanks for that, I just downed the first on the list, did not even notice the other version.

TlatoSMD
31st October 2019, 07:27
How do I get third-party VDub processing plugins to work in VirtualDub2?

I'm on Windows 10 Professional Home 64-bit. I've been using old VDub 32-bit up until a few weeks ago, because none of the plugins ever worked in old VDub 64-bit. But now, some recent Microsoft update has made it so the 32-bit version of old VDub doesn't load up anymore, so I've decided to give VirtualDub2 a try.

But the same problem persists in VirtualDub2: Not a single one of my many third-party plugins (mainly MSU plugins, Logoaway, and Tacosalad's Dotcrawl, but overall they add up to 34 different plugins) are successfully loaded in VirtualDub2. When I try to add any of those plugins manually inside of the VirtualDub plugin list, I'm getting the error message, "This is not a Win32 application". Plus, also VirtulDub2 only appears on my screen in the 64-bit version, not in the 32-bit version which, just like old VDub does now, only loads in the background but never shows up on screen and which I then have to manually kill by means of Windows taskmanager.

I've consulted the official Wiki on Sourceforge, but the only bit on plugins there looks like I'd have to learn programming first to fix this issue.

So, how to actually make third-party plugins load in VirtualDub2? Note that this is not a question on how to make any of those plugins work in an AVIsynth script, it's simply about how to use them in VirtualDub2 itself like within old VDub. And it's still the same old 8-bit color per channel, 4:2:2 and 4:2:0 video files that I'm trying to use those filters on.

Without those third-party processing plugins, VirtualDub2 will be pretty much useless for me. I'd really hate to abandon Avery Lee's cool tool after it's been more than 15 years, just because it's suddenly borked now. VirtualDub2 without those third-party plugins would be pretty much nothing but a fancy converter such as XMedia Recode and would lack any right to exist next to those for me.

TlatoSMD
31st October 2019, 07:41
Okay, so I've found a solution to at least *PART* of my problem. After rebooting Windows, old 32-bit VDub loads just fine again.

But the issues with old VDub 64-bit and VirtualDub2 still persist: No third-party plugins.

EDIT: Wow, now even the 32-bit version of VirtualDub2 works, properly loading all plugins! Great, finally a working version for me. Still, kinda strange how none of this seems to work with the 64-bit versions of both old VDub and VirtualDub2, even though I'm on a 64-bit OS.

TlatoSMD
31st October 2019, 07:53
So here's the next issue: While I'm using VDub mainly for its processing plug-ins, I can't seem to make Direct stream copy work in VirtualDub2 now. The video file has x264 (aka h264) for video (8-bit color per channel) and mp3 for audio, and the error msg I keep getting is "Select different input driver". So how do I do that? It was never an issue to use Direct stream copy in order to export this kind of footage into an AVI with old VDub.

StainlessS
31st October 2019, 08:17
64 bit VD2 (or any 64 bit executable) will require 64 bit plugins, 32 bit will not work. (same issue in Avisynth+ 64 bit, and 32 bit plugins).
Also, 32 bit plugins in VD2 64 bit plugins directories may cause problems, dont do it.

x264, dont really know much about this, but, you can only do Direct Stream Copy where source stream is compatible with output file,
although you can (I've never done it) create x264 in AVI, there are some things that need be omitted [at a guess I might think CABAC may be one of them],
if source does have some unsupported x264 features, then will not be able to Direct Stream Copy.

Dont think "Select different input driver" will make any difference, unless it decodes to uncompressed video, which you could then copy to
output AVI as uncompressed video (perhaps YUV or maybe only RGB, dont know).

I would use Fast Recompress, to some output codec, but that stuff has changed in Vdub2 (cant remember in what way it changed).

You will probably get a better answer soon, a wrong answer often prompts someone else to correct it in double time,
people like to tell others just how wrong they are :)

EDIT: Having looked at VD2 Decode Format, AutoSelect would seem to be the only likely one to choose.

EDIT: The VirtualDub x264 compression thingy docs will likely tell what features of x264 are unsupported in AVI files.

TlatoSMD
31st October 2019, 09:13
x264, dont really know much about this, but, you can only do Direct Stream Copy where source stream is compatible with output file,
although you can (I've never done it) create x264 in AVI, there are some things that need be omitted [at a guess I might think CABAC may be one of them],
if source does have some unsupported x264 features, then will not be able to Direct Stream Copy.

Dont think "Select different input driver" will make any difference, unless it decodes to uncompressed video, which you could then copy to
output AVI as uncompressed video (perhaps YUV or maybe only RGB, dont know).

I would use Fast Recompress, to some output codec, but that stuff has changed in Vdub2 (cant remember in what way it changed).

[...]

EDIT: The VirtualDub x264 compression thingy docs will likely tell what features of x264 are unsupported in AVI files.

I've just tried the very same thing, on the very same file, with old VDub 32-bit without a problem. But VirtualDub2 only keeps telling me "Select different input driver" on the very same file.

EDIT: Having looked at VD2 Decode Format, AutoSelect would seem to be the only likely one to choose.

I've checked that before mentioning the issue here. It's what VirtualDub2 is set to by default, but still that error msg where old VDub has no problem at all.

StainlessS
31st October 2019, 10:12
Arh, (I remembered something), check out the File Open Selector box,
"Select different input driver" is there.

EDIT: Although I dont know what the trick is to un-disable it.

shekh
31st October 2019, 14:35
About input drivers: see this link https://sourceforge.net/p/vdfiltermod/wiki/direct_copy/

TlatoSMD
31st October 2019, 17:31
About input drivers: see this link https://sourceforge.net/p/vdfiltermod/wiki/direct_copy/

Thanks! Setting it back to standard AVI input in that open file dialogue did the trick. :)

Okay, so now that VirtualDub2 is fully functional for me, maybe, *MAYBE* its integrated script editor will help me get into AVIsynth for once, after I haven't been able for more than 15 years by now to learn AVIsynth at a sufficicent level to even just open a file.

A clickable GUI and a programming language aka "script" are just so vastly different in approach, plus both Mencoder and AVIsynth always seem to lack *DECADES* behind on their respective documentations, so none of the scripts found in documentation *EVER* work. Plus, AVIsynth and Mencoder aces often seem to have a terrible holier-than-thou attitude, so even if you're trying to contact them for help, in 9 cases out of 10 they will first ridicule the fact that you're actually trying to use commands from the documentation, and then immediately stop talking to you once they realize you're not using Linux, which basically means you're some lower life form not worth their time.

LigH
4th November 2019, 08:57
Apropos ... the input driver concept seems to be the reason why you can't use VirtualDub2 to e.g. remultiplex MKV to MP4 in Stream Copy mode, correct?

shekh
7th November 2019, 14:53
Apropos ... the input driver concept seems to be the reason why you can't use VirtualDub2 to e.g. remultiplex MKV to MP4 in Stream Copy mode, correct?

The original idea of input driver in VD was like this:
1) input driver has to split source into packets and that`s all
2) video decoder has to take packets and no other metadata and translate that into frames

I may be missing some details but taking into account ordinary h264 video it is just impossible to implement accurate decoder in that way.
However, if focus is stream copy (decoder is not needed) then such input driver can work (splitting into packets is good enough).
At the same time the decoding phase is only good as preview - it is NEVER frame accurate.
This is how original AVI driver works, and also FCCHandler' matroska driver and quicktime driver.

Another approach was ffmpeg input driver - initially developed by FCCHandler according to some history of changes.
The idea with ffmpeg was to ignore packets altogether and deliver correct decoded frames right away (I think so, or maybe the idea was lost between changes).

What is blocking simultaneous support for copy and decode with ffmpeg? The core feature is being able to translate from packets to frames and back (timestamps also would be great): ffmpeg lacks this.
Current "caching input driver" has stretched this in some ways: it does switch to direct mode when packet-frame translation is trivial, this is the case with keyframe-only formats. Doing more than that needs more time and passion.

Why avidemux can work? It uses ffmpeg with some patches applied and afaik some custom made demuxers as well. Might be as good idea to either borrow his work or fix ffmpeg myself, both ways are not simple and stay in my internal 'todo' few years.

jpsdr
26th November 2019, 11:09
Hi.
Check here (https://forum.doom9.org/showpost.php?p=1891382&postcount=4960).

nji
28th November 2019, 18:56
Scenario:
Open a movie
Select a frame
Insert it (say 5 times)
Insert a filter (apply opacity curve)

=> In "curve editor" frame numbers at positions after insert positions
doesn't correspond to having inserted frames
(Still has the original ones (= -5)).

Bug?

shekh
29th November 2019, 00:37
Welcome to the world of VirtualDub timeline coordinates. It has everything of: mistakes, confusing design, unfinished work.
Basic rule of thumb is: everything you do in timeline control (insert, delete, move parts, select range) happens after filters. Curve points are in filters coordinates (or maybe even source?) hard to tell exactly because it does not work as explained in the documantation.
Also before I realized that timeline edits transform already filtered sequence I attempted to specify time positions in final (post-edit) coordinates and this made the situation even worse.

Good idea: never use both curves and timeline edits (except select range) in the same process. Also maybe don't combine any of that with time-scaling filters (deinterlace, interpolate, delete frames etc).

nji
29th November 2019, 10:30
Phew!

This is really a BAD surprise.

First the filters, then the timeline manipulation?
But shouldn't it be just the other way round?

And not being allowed to "mix" both "operations" is like
to forbid the basic operation on movie manipulation...

???

jdawn1
8th December 2019, 12:55
Is it possible to direct stream copy AAC audio?
IM using Vdub 2 to re-encode 4k video shot on my phone which is H264 120mbit using x265.

I was using handbrake ,but for some reason handbrake messes up contrast and colors, whereas vdub gets it perfect. This is without any filters.
I get way better results from vdub, for some reason handbrake is causing remapping of colors or something.

But when I direct stream copy the audio the only option on save video is WAV format, and it doesn't work anyhow.

shekh
9th December 2019, 00:19
Is it possible to direct stream copy AAC audio?
IM using Vdub 2 to re-encode 4k video shot on my phone which is H264 120mbit using x265.

I was using handbrake ,but for some reason handbrake messes up contrast and colors, whereas vdub gets it perfect. This is without any filters.
I get way better results from vdub, for some reason handbrake is causing remapping of colors or something.

But when I direct stream copy the audio the only option on save video is WAV format, and it doesn't work anyhow.

Short answer: not possible (with different input driver for audio it may work or lead to other problems).
You can re-compress as AAC, select "Audio: Full processing mode" and then choose compression.

jdawn1
9th December 2019, 06:19
Thanks for the answer.
I did more testing on handbrake vs vdub with x265.
with the same settings, I get 0.37fps on vdub and 0.21fps on handbrake (VerySlow, 10 bit, 25 crf)
vdub matches the colors and contrast so the output is superior. The file size is also about 15% smaller.

The results are even worse when resizing to 2560 from 3840, both use Lanczos 3
handbrake: 0.45fps, terrible contrast lost, 17.7MB
vdub: 0.82fps, matching contrast and colors perfectly, 15.9MB

Hopefully vdub can do batch of input folders like handbrake!

jdawn1
28th December 2019, 18:01
Hi shekh

This might be a dumb question, but how do you add command line options to the x265 encoder on avlib-1?

https://i.imgur.com/xKZ1Apw.jpg

Sometimes I want to run two pass encoding to target a file size...
Not sure why, but your x265 arrangement gives better performance, quality and compression then handbrake so I really like to use it...
Not to mention the other benefits of vdub over HB.

shekh
28th December 2019, 23:04
Hi shekh

This might be a dumb question, but how do you add command line options to the x265 encoder on avlib-1?

https://i.imgur.com/xKZ1Apw.jpg

Sometimes I want to run two pass encoding to target a file size...
Not sure why, but your x265 arrangement gives better performance, quality and compression then handbrake so I really like to use it...
Not to mention the other benefits of vdub over HB.

Hi
Really have no idea why it has anything better, as I never benchmarked handbrake. Glad if this result comes from my effort and not from measurement error :)

The codec interface is actually that simple. There is no command line. There was similar request at least once though.

You can try with external encoder interface, as it deals with pure command lines.

age
29th December 2019, 00:15
Little bug report, encoding prores HQ from vapoursynth/avisynth has a wrong matrix in the prores metadata (always bt.470)

osgZach
13th January 2020, 08:55
Feature Request:
Can you please modernize the options allowed for exporting segmented AVI ? Currently the file size limit on segments is 2048MB which makes it very impractical for working with lossless codecs. I was hoping setting it to 0MB and using the "limit number of frames" option would get me larger files but alas... It would be nice to see this output option modernized a bit. You could even expand it to work with other output containers if people were so inclined to use it that way.

There are other possibilities too. Giving it a number of desired chunks and having it calculate the number of frames to output based on total frames or play length, etc. Being able to tell it to queue an output job in X number of chunks and automatically setup the jobs in the queue would potentially be neat as well. I could see myself using it for heavy filtering jobs that may require 24 hours or more of processing; being able to do it in lossless chunks that I can pause/resume as needed and rejoin myself later, might be useful...

but really in terms of basics anything is better than a 2GB file limit.

shekh
13th January 2020, 10:42
Interesting. I had no idea segmented output is actually useful. I thought it is just annoying complexity from times when files were transferred on cd's or something. :)

StainlessS
13th January 2020, 13:11
when files were transferred on cd's or something.

Perhaps related to FAT32 (not sure, maybe fat32 was originally borked to max 2GB, or maybe not), but anyway, I'm guessin
that many softwares were limited to 2GB, simply because of use of signed int, so max 2GB avoids the problem altogether.

osgZach
13th January 2020, 17:14
yeah it was common to limit to 2GB back then, either due to file system constraints, and/or the original AVI container. Then OpenDML came along and allowed larger than 2GB AVI files.
I'll admit I'm probably one of the few people who would use segmented output at this point. So don't worry about rushing it or if it looks like too much of a hassle after you look at the code.

SeeMoreDigital
13th January 2020, 22:58
Wow... I haven't had need to use the avi container in years!

Out of interest... What audio and video formats are people trying to put in it these days?

osgZach
13th January 2020, 23:32
I use AVI for MagicYUV codec video and if there is audio, 2 channel or multichannel PCM
Strictly as a lossless intermediate or recording format.

Last popular codec to shove into AVI with hacks was H.264 or possibly H.265 I think. But I could be wrong, I don't pay that close attention to things like I used to.

StainlessS
14th January 2020, 00:09
Yip, MagicUV and also UT_Video are great lossless codecs for AVI, and AVI is pretty much bulletproof as source clip [so long as you aint daft enough to use DivX/XVid],
you can spend a lot of time screwing around with non AVISource source filters, almost always less strain on the heart to first just convert to AVI via FFMPeg,
exception being DGIndex where is pretty damn solid too. [EDIT: 10 bit AVI may though still be problematic]

osgZach
14th January 2020, 01:33
So, interesting development.

I took 15 minutes of footage, decided to just arbitrarily put in a huge file size (10GB) and then limit the frames to 7100 frames and run a segmented export.

It gave me four total segments. 3.19GB, 3.45GB, 3.80GB, and 155.56MB (respectively 4m:56s each, and 11 seconds)


So.... I guess there is no sanity check on that input box or something? Or maybe the wording on it just never got update
I did a stream copy so no idea if that influenced it at all.

poisondeathray
14th January 2020, 07:20
So, interesting development.

I took 15 minutes of footage, decided to just arbitrarily put in a huge file size (10GB) and then limit the frames to 7100 frames and run a segmented export.

It gave me four total segments. 3.19GB, 3.45GB, 3.80GB, and 155.56MB (respectively 4m:56s each, and 11 seconds)


So.... I guess there is no sanity check on that input box or something? Or maybe the wording on it just never got update
I did a stream copy so no idea if that influenced it at all.


Different types of content have different compression ratios

7100 frames of complex, noisy footage would be much larger than 7100 frames of 1 color black, for all types of compression schemes (lossy, lossless, I-frame, or long GOP)

Uncompressed video, however, will lead to the same filesize per frame

osgZach
14th January 2020, 08:18
I think you've overlooked the context of the data.

As mentioned earlier, I output lossless MagicYUV files.
I requested a modification to the alleged 2GB file size limit on segmented AVI output - which it appears is not an actual limit after some further testing. I put 10GB on purpose to see if it would reject it or break the output in some way, and then I chose 7100 to make sure I got several segments over a 21k frame selection range.

https://i.imgur.com/nftUpHE.png

LigH
14th January 2020, 09:02
I believe the 2 GB limit for legacy AVI is not related to FAT32 files, but to 32 bit chunk sizes in the AVI structure, which are often even interpreted as signed. OpenDML was the AVI 2.0 extension to circumvent this internal limit.

StainlessS
15th January 2020, 07:13
Makes sense, thanks LigH.

osgZach
16th January 2020, 05:06
hmm ok, still seeing some weirdness here I guess.

I took a MagicYUV (M8Y0) input for a denoised Wrath of Khan I made a while ago, and gave it enough frames to split down the middle (58m15s both files). But when I try to open either of them in WMP, JRiver, etc it won't play. VLC says it has to rebuild the file index. Openinng with Vdub prompts an operation for "Reconstructing Index Block", it hangs for a bit, then throws out this warning

https://i.imgur.com/GBijb2i.png

seeking around takes a few seconds to accomplish.

I can open an earlier aborted output just fine, because that file was only 500MB so I am guessing there may still be something to investigate with VDubs file splitting abilities. The only thing I did here aside from specify a large maximum frame per segment, was increasing the file size limit to 500GB I'll experiment with some lower values on the size limit to see if it has any weird influence on output errors.

wonkey_monkey
16th January 2020, 11:20
Sounds like VirtualDub just literally splits the file output, rather than creating two valid AVI files. The index would be in the second half (it's also always written on abort, I believe, making an aborted file valid), and the second half would not contain any headers.

osgZach
17th January 2020, 08:08
Sounds like VirtualDub just literally splits the file output, rather than creating two valid AVI files. The index would be in the second half (it's also always written on abort, I believe, making an aborted file valid), and the second half would not contain any headers.

I don't think this is the case. I just set it to 2GB segment size and every single one outputs / loads fine independently outside of Vdub, even moved a single segment to another location and loaded without any hiccups.
I'm going to re-run the job I just with the messed up outputs when I go to bed and see what happens. Still hoping I just caused a glitch doing other stuff on the PC.

osgZach
17th January 2020, 18:37
The magic number seems to be a segment size of 4096MB anything above this appears to produce index errors in all files, except for the final segment, if it is below that size.