VirtualDub2

[shekh]

@kolak
It seems everything is clear, added request to self https://sourceforge.net/p/vdfiltermod/tickets/244/

[stax76]

@shekh

Thanks for the insight. In the DivX and XviD days, VirtualDub was the main encoding app used by StaxRip.

[kolak]

@kolak
It seems everything is clear, added request to self https://sourceforge.net/p/vdfiltermod/tickets/244/

Ok, thanks.

[age]

Least note- color tags are written by the default based on resolution/fps. You can force them as well using correct flagging: https://trac.ffmpeg.org/wiki/colorspace. Default behaviour is fairly good though (at least for HD, PAL/NTSC SD formats).

When I encode prores HQ with ffmpeg ( and virtualdub) it outputs always the same matrix "BT.470 System B/G".

During the encoding in ffmpeg I'm forced to use the PRORES_METADATA

https://ffmpeg.org/ffmpeg-bitstream-filters.html#prores_005fmetadata

[shekh]

When I encode prores HQ with ffmpeg ( and virtualdub) it outputs always the same matrix "BT.470 System B/G".

During the encoding in ffmpeg I'm forced to use the PRORES_METADATA

https://ffmpeg.org/ffmpeg-bitstream-filters.html#prores_005fmetadata

It is not the same as "-movflags write_colr"? Madness.

[kolak]

When I encode prores HQ with ffmpeg ( and virtualdub) it outputs always the same matrix "BT.470 System B/G".

During the encoding in ffmpeg I'm forced to use the PRORES_METADATA

https://ffmpeg.org/ffmpeg-bitstream-filters.html#prores_005fmetadata

Latest ffmpeg should set correct flags on private ProRes headers and MOV container level.
If source has known parameters then ffmpeg by default will write them into private ProRes headers (as long as supported). In order to have this info also on container level you need to use "movflags write_colr" and tell ffmpeg what you want there with: -color_primaries, -color_trc, -colorspace options (otherwise it will write default values which is Rec.709 or Rec.601 depending on resolution). If parameters are missing on the source file then you need to tell ffmpeg what they are on input and what you want on output (+ info for movflags as in 1st case). It's bit crap that you need 2 sets of flagging in order to have 100% correctly flagged ProRes file (on container and private headers). Of curse those values should be always aligned.

Example 1 (source without known flagging):

..... -vf colorspace=iall=bt2020:all=bt2020 -color_primaries 9 -color_trc 14 -colorspace 9

in this case we tell ffmpeg that our source is Rec.2020 (iall) and we want to keep it this way (all) and also add flagging on container level as Rec.2020.

Example 2: (source with known flagging as Rec.2020):

-color_primaries 9 -color_trc 14 -colorspace 9

In this case we need just info for movflags option as private headers will be set to match source.

There are many options for colorspace filter which also allows for conversion between different color spaces. Doc:
https://ffmpeg.org/ffmpeg-all.html#toc-colorspace

You can achieve the same with zimg scaling as well which is very high quality filter. In both filters key point is fact that source flagging needs to be known- be on source or set by you. Without it you will have errors as ffmpeg won't know what to start with. All of this applies to prores and prores_ks encoders.

[kolak]

It is not the same as "-movflags write_colr"? Madness.

I thought it's but unfortunately it's way more complex (as described above).

[shekh]

Thanks for info. Btw, to differentiate encoders it is better to say prores_ks or prores_aw (they are named by author initials)

[kolak]

I think aw is more known as just prores in ffmpeg. Not sure. Ks is recognised as more Apple compliant.

[wonkey_monkey]

VirtualDub2 behaves strangely with this AviSynth+ script:

blankclip(pixel_type="rgbaps")
invert
converttoyv12

It seems to paint nothing in the panes (redrawing problems are evident if you drag the panes around, plus they darken when the window loses focus).

If you change converttoyv12 to converttoy8, you get colourful garbage, which may indicate an AviSynth+ problem but I'm not sure (since I can't read the output of "info" to determine what colourspace I've ended up with), but the redrawing issue with converttoyv12 indicates some kind of trouble with VirtualDub2 not sensibly handling unexpected data.

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

Edit: confusion abounds because converttoyv12/y8 don't actually change the bit depth, so the problem is just that VirtualDub2 doesn't display (or throw an error for) float data.

[shekh]

Edit: confusion abounds because converttoyv12/y8 don't actually change the bit depth, so the problem is just that VirtualDub2 doesn't display (or throw an error for) float data.

Yes, something bad with error handling.

[StainlessS]

Hi Shekh,

Simple script
Colorbars
Try Export single image fails to show file selector dialog box when Menu/View/Enable_Output_Pane/ is disabled, OK when enabled.
[not sure if intentional, if so then maybe could alert to failure reason]
Build 43602

[Soulvomit]

What are the chances of 32-bit ever being supported, if only for gamma-aware rescaling?

[shekh]

What are the chances of 32-bit ever being supported, if only for gamma-aware rescaling?

Not bad - there is internal FP32 format (rgb/rgba). There is no input support and I at least need to update "gamma" and "resize" filters.

[Soulvomit]

Not bad - there is internal FP32 format (rgb/rgba). There is no input support and I at least need to update "gamma" and "resize" filters.Looking forward to it if you do decide to. Many thanks.

[pinterf]

Hi shekh, what are my choices when I'd like to display an RGB48 format from Avisynth+? Does VDub2 have any support for it on the VfW interface?
Right now I report BGR[48] (BGR0) but it is not recognized.
Or I'm doing something wrong.
Thanks.

[shekh]

Hi shekh, what are my choices when I'd like to display an RGB48 format from Avisynth+? Does VDub2 have any support for it on the VfW interface?
Right now I report BGR[48] (BGR0) but it is not recognized.
Or I'm doing something wrong.
Thanks.

Hi, such format is not supported. I think I should add decoding support for BGR[48] and b48r.
What's wrong if you add ConvertToRGB64 in script?

[pinterf]

Hi, such format is not supported. I think I should add decoding support for BGR[48] and b48r.
What's wrong if you add ConvertToRGB64 in script?
Nothing wrong. But if a user would like to display such a format in VDub2,
- user applies ConvertToRGB64 at the end of the script (inconvenience, conversion overhead)
- Avisynth+ silently converts it to RGB64 and reports one of the RGB64 fourCCs. (conversion overhead)
- VirtualDub2 handles FourCC BGR[48] (I don't know if there is any extra conversion overhead on your side)

[shekh]

Nothing wrong. But if a user would like to display such a format in VDub2,
- user applies ConvertToRGB64 at the end of the script (inconvenience, conversion overhead)
- Avisynth+ silently converts it to RGB64 and reports one of the RGB64 fourCCs. (conversion overhead)
- VirtualDub2 handles FourCC BGR[48] (I don't know if there is any extra conversion overhead on your side)

Ok. If I implement packed BGR the conversion will expand it to internal planar format. To minimize overhead the best option is planar RGB (G3[0][16]), so current workaround should be 'just remove ConvertToRGB48 at the end of script'.

[pinterf]

Ok. If I implement packed BGR the conversion will expand it to internal planar format. To minimize overhead the best option is planar RGB (G3[0][16]), so current workaround should be 'just remove ConvertToRGB48 at the end of script'.
I see. So it's better to convert it losslessly to planar rgb in Avisynth and report it as G3[0][16] then everybody is happy.

Now a similar workaround is working for the opposite direction: if planar rgb would not be supported, there is an optional rgb64 conversion if user wants to do so:
http://avisynth.nl/index.php/Internal_functions#OPT_Enable_PlanarToPackedRGB

thanks

[Keiyakusha]

shekh
is there any chance you could add something like %(selectionstart) and %(selectionend) options to these (https://i.imgur.com/zQXGSGg.png) variables (external encoder) that would return frame numbers of the current selection (same values as in statusbar)?
Currently I am trying to use VirtualDub to cut some footage while saving to the intermediate format and these would help to form the filename to know where I made the cut from.

[shekh]

Keiyakusha
This is easy, no problem.

[albino]

As a long long time user of Virtualdub, I thought it was high time I make the switch to Virtualdub2. Right off the bat though I noticed that my export speeds are much slower than in Virtualdub, so I'm wondering if I'm doing something obviously wrong.

I tested with Virtualdub 1.10.4 using DShowInputDriver against Virtualdub2 43702. I also tested with an old version of ffinputdriver I had available. I noticed it right away with every file I tried, but as a control for the results below I decided to use big_buck_bunny_1080p_h264.mov, saving only the first 1:00 in order to keep the testing time easy to manage. All of the files and programs are on my NVMe drive with an i7-7700K and Windows 10 Pro. Here's my quick test results in seconds:

Virtualdub1 (DShowInputDriver)
Uncompressed: 17
MagicYUV: 14

Virtualdub1 (ffinputdriver)
Uncompressed: 23
MagicYUV: 13

Virtualdub2 (default)
Uncompressed: 25
MagicYUV: 23

I also tested with Lagarith, and all three were about the same time (though over 50 seconds each). I tried opening the file with the cache on by default, and disabling it, but the times were identical either way.

At the end of the day, the time differences aren't that much unless you're doing something significant, but I just thought I'd ask here in case there's a plugin I'm supposed to be using, or if I should be disabling/enabling some option.

Thanks!

[shekh]

As a long long time user of Virtualdub, I thought it was high time I make the switch to Virtualdub2. Right off the bat though I noticed that my export speeds are much slower than in Virtualdub, so I'm wondering if I'm doing something obviously wrong.

I tested with Virtualdub 1.10.4 using DShowInputDriver against Virtualdub2 43702. I also tested with an old version of ffinputdriver I had available. I noticed it right away with every file I tried, but as a control for the results below I decided to use big_buck_bunny_1080p_h264.mov, saving only the first 1:00 in order to keep the testing time easy to manage. All of the files and programs are on my NVMe drive with an i7-7700K and Windows 10 Pro. Here's my quick test results in seconds:

Virtualdub1 (DShowInputDriver)
Uncompressed: 17
MagicYUV: 14

Virtualdub1 (ffinputdriver)
Uncompressed: 23
MagicYUV: 13

Virtualdub2 (default)
Uncompressed: 25
MagicYUV: 23

I also tested with Lagarith, and all three were about the same time (though over 50 seconds each). I tried opening the file with the cache on by default, and disabling it, but the times were identical either way.

At the end of the day, the time differences aren't that much unless you're doing something significant, but I just thought I'd ask here in case there's a plugin I'm supposed to be using, or if I should be disabling/enabling some option.

Thanks!

This looks like terrible and unexpected difference.
Cache cannot help with sequential read - this is ok.
Some common ideas: are you comparing same architecture (x64 executables)?
Make sure the decode format is "autodetect", and there is no unwanted format conversion in the middle.
Run benchmark analyze pass or open Real-time profiler, it shows some performance details.
You can test all 3 input drivers in VD2

[albino]

This looks like terrible and unexpected difference.
Cache cannot help with sequential read - this is ok.
Some common ideas: are you comparing same architecture (x64 executables)?
Make sure the decode format is "autodetect", and there is no unwanted format conversion in the middle.
Run benchmark analyze pass or open Real-time profiler, it shows some performance details.
You can test all 3 input drivers in VD2

Hey shekh!

* Decode format is set to Autoselect, I've never changed that option before. Virtualdub1 doesn't appear to have that option.

* I'm not sure what the benchmark is, but if it's Tools -> Benchmark Resampler then here is the outputs:


Virtualdub1 32 bit:

Point: 0.13 ms, 5896.9Mpixels/sec
Linear: 1.80 ms, 437.8Mpixels/sec
Cubic: 1.55 ms, 507.9Mpixels/sec
Lanczos3: 2.07 ms, 379.9Mpixels/sec

Virtualdub2 32 bit:

Point: 0.15 ms, 5314.0Mpixels/sec
Linear: 1.80 ms, 437.0Mpixels/sec
Cubic: 1.55 ms, 507.8Mpixels/sec
Lanczos3: 2.07 ms, 380.1Mpixels/sec

Virtualdub2 64 bit:

Point: 0.24 ms, 3219.2Mpixels/sec
Linear: 1.46 ms, 540.5Mpixels/sec
Cubic: 1.26 ms, 622.5Mpixels/sec
Lanczos3: 1.68 ms, 468.2Mpixels/sec


If it's some other benchmark, then just point me in the right direction.

* As a side note, benchmark-wise, just checking pure FPS, using MagicYUV the peak for Virtualdub1 32 bit was 113 fps, and the peak for Virtualdub2 64 bit was 64 fps.

* I'm not sure what I'm looking for with Real Time Profiler. If you want me to screenshot something specific while I'm running it, or after it finishes, let me know.

* My Virtualdub1 is 32 bit, and that was a good question, so I tried comparing it against both the 32 bit and 64 bit versions of Virtualdub2. I put DShowInputDriver in the plugins32 folder of Virtualdub2 because that's where it is in my Virtualdub1, and I closed and re-opened Virtualdub2 when switching between DShowInputDriver and the default decoder. Also, I re-ran Virtualdub1 again just to have a baseline. Here's my results:


Virtualdub1 (32 bit, default with no DShowInputDriver) - Error, can't load the mov file.

Virtualdub1 (32 bit, DShowInputDriver)
Uncompressed: 15
Magic: 13

----------

Virtualdub2 (32 bit, default)
Uncompressed: 25
Magic: 23

Virtualdub2 (32 bit, DShowInputDriver)
Uncompressed: 27
Magic: 24

----------

Virtualdub2 (64 bit, default)
Uncompressed: 26
Magic: 23

Virtualdub2 (64 bit, DShowInputDriver)
Uncompressed: 27
Magic: 23


I'm sure you already have it, but here's my copy of DShowInputDriver.vdplugin in case you want to test on your end:

https://we.tl/t-eJ0aNxyu5W

Let me know if you want me to test anything else, I'm happy to do so. Thanks!

[wonkey_monkey]

shekh,

Drag any YUV video onto VirtualDub2, add a levels filter (input 0-64, output 0-255) and it comes out all messed up:

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

It seems to be skipping every fourth pixel, or possibly repeating pixels.

The problem goes away if I untick "Operate in luma instead of RGB", or if the input is RGB itself.

[shekh]

shekh,

Drag any YUV video onto VirtualDub2, add a levels filter (input 0-64, output 0-255) and it comes out all messed up:

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

It seems to be skipping every fourth pixel, or possibly repeating pixels.

The problem goes away if I untick "Operate in luma instead of RGB", or if the input is RGB itself.

Amazing, this is bug in x64 version, straight from the original VD.

[shekh]

VirtualDub2 behaves strangely with this AviSynth+ script:

blankclip(pixel_type="rgbaps")
invert
converttoyv12

It seems to paint nothing in the panes (redrawing problems are evident if you drag the panes around, plus they darken when the window loses focus).

If you change converttoyv12 to converttoy8, you get colourful garbage, which may indicate an AviSynth+ problem but I'm not sure (since I can't read the output of "info" to determine what colourspace I've ended up with), but the redrawing issue with converttoyv12 indicates some kind of trouble with VirtualDub2 not sensibly handling unexpected data.

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

Edit: confusion abounds because converttoyv12/y8 don't actually change the bit depth, so the problem is just that VirtualDub2 doesn't display (or throw an error for) float data.

I'm not sure if this is correct bitmap format from avisynth here (looks like 64-bit rgb), but VD doesn't know it *and* microsoft RLE decoder thinks it is their format but fails to works. I stopped digging with this mess and simply prohibited searching for decoder (in case fourcc=0).

[shekh]

What are the chances of 32-bit ever being supported, if only for gamma-aware rescaling?

Added fp32 mode in filters (not much optimized):
Convert to floating point (begin with this)
Gamma correct
Levels
Resize
Fill
6-axis color correction

[shekh]

shekh
is there any chance you could add something like %(selectionstart) and %(selectionend) options to these (https://i.imgur.com/zQXGSGg.png) variables (external encoder) that would return frame numbers of the current selection (same values as in statusbar)?
Currently I am trying to use VirtualDub to cut some footage while saving to the intermediate format and these would help to form the filename to know where I made the cut from.

This was long, but well, added. Using these macros is quite weird actually (you have to avoid file extension in file dialog).

[shekh]

shekh,

Drag any YUV video onto VirtualDub2, add a levels filter (input 0-64, output 0-255) and it comes out all messed up:

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

It seems to be skipping every fourth pixel, or possibly repeating pixels.

The problem goes away if I untick "Operate in luma instead of RGB", or if the input is RGB itself.

Fixed some errors in levels, also added support for full range YUV (long annoying trouble).

[shekh]

albino

I made illustration about profiler: https://sourceforge.net/p/vdfiltermod/wiki/performance/

I also noticed and fixed performance issue with conversion to RGB (shown in the wiki page) but not sure if this is what you did. Hope it helps to find something specific.

[wonkey_monkey]

:thanks:

[jpsdr]

Added fp32 mode in filters (not much optimized):


So, new SDK ? (Even if i'm not using this for now).
BTW, what is the status of a potential interlaced flag in the FilterModPixmapInfo ?

[shekh]

So, new SDK ? (Even if i'm not using this for now).
BTW, what is the status of a potential interlaced flag in the FilterModPixmapInfo ?

Not new, formats were added from build 42338:
kPixFormat_RGB_Planar
kPixFormat_RGB_Planar16
kPixFormat_RGB_Planar32F
kPixFormat_RGBA_Planar
kPixFormat_RGBA_Planar16
kPixFormat_RGBA_Planar32F

About adding flags: I'm sorry to tell, nothing changed yet

[jpsdr]

Not new, formats were added from build 42338:
kPixFormat_RGB_Planar
kPixFormat_RGB_Planar16
kPixFormat_RGB_Planar32F
kPixFormat_RGBA_Planar
kPixFormat_RGBA_Planar16
kPixFormat_RGBA_Planar32F

So, i just need to update my vdplugin.h with yours.
After, it's up to me in my plugins to eventualy add support. :p
For RGB planar, as it's something new in virtualdub2, is it the following ?

pxsrc=(VDXPixmapLayoutAlpha&)*fa->src.mpPixmapLayout;
pxsrc.pitch = pitch R
pxsrc.pitch2 = pitch G
pxsrc.pitch3 = pitch B
//////////
pxsrc=(const VDXPixmapAlpha&)*fa->src.mpPixmap;
pxsrc.data = R data pointer
pxsrc.data2 = G data pointer
pxsrc.data3 = B data pointer



About adding flags: I'm sorry to tell, nothing changed yet
No big deal, i was just asking to know, it's not something i realy miss...

Anyway, thanks again for your work on VDub2 evolving.

EDIT
Forgot to ask about :

FilterModPixmapInfo* info = fma->fmpixmap->GetPixmapInfo((fa->dst).mpPixmap);
info->ref_r; // and g,b,a

What about their value in float mode ?
Does it matter ?

[shekh]

So, i just need to update my vdplugin.h with yours.
After, it's up to me in my plugins to eventualy add support. :p
For RGB planar, as it's something new in virtualdub2, is it the following ?

pxsrc=(VDXPixmapLayoutAlpha&)*fa->src.mpPixmapLayout;
pxsrc.pitch = pitch R
pxsrc.pitch2 = pitch G
pxsrc.pitch3 = pitch B
//////////
pxsrc=(const VDXPixmapAlpha&)*fa->src.mpPixmap;
pxsrc.data = R data pointer
pxsrc.data2 = G data pointer
pxsrc.data3 = B data pointer



Yes, you just need new formats constants and the order of planes is R,G,B,A as you guessed (A=data4/pitch4)


info->ref_r; // and g,b,a
What about their value in float mode ?


Not used/undefined. This is meaningful only for 16-bit integer formats.

[qyot27]

VirtualDub2 behaves strangely with this AviSynth+ script:

blankclip(pixel_type="rgbaps")
invert
converttoyv12

It seems to paint nothing in the panes (redrawing problems are evident if you drag the panes around, plus they darken when the window loses focus).

If you change converttoyv12 to converttoy8, you get colourful garbage, which may indicate an AviSynth+ problem but I'm not sure (since I can't read the output of "info" to determine what colourspace I've ended up with), but the redrawing issue with converttoyv12 indicates some kind of trouble with VirtualDub2 not sensibly handling unexpected data.

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

Edit: confusion abounds because converttoyv12/y8 don't actually change the bit depth, so the problem is just that VirtualDub2 doesn't display (or throw an error for) float data.

FWIW, anything FFmpeg-based supports reading floating-point RGB(A) and Y32 from AviSynth+ if it's newer than 2019-05-04 (like the build of mpv I posted in another thread (https://forum.doom9.org/showthread.php?p=1881239#post1881239)). FFmpeg still can't do much with it beyond display it, but that's enough to happily play back and verify that you're getting correct output from AviSynth+.

[nji]

Recently I discovered that some movies contain duplicate frames every n-th frame.
(This must have happened by changing the frame rate somehow.)
Now I wanted to remove that frames, but found no practical way.
There is no filter for that (maybe the filter interface doesn't allow to delete frames?),
and changing the frame rate by menu (video / frame rate...) does allow to remove
every n-th frame (by frame rate conversion to a specific fps) but
you cannot specify the "start frame" to remove.
So it happens that frames that contain information are removed,
while the duplicate frames are left in the stream. That is worse than before.

The only "solution" I found is to write all frames as image sequence,
then delete every n-th image, and re-read the remaining images.
Quite unpractical.

So my question:
Is there any solution how to do that task?

[shekh]

nji

I think there is RemoveFrames filter which can do the job.
https://github.com/jpsdr/Filtres_JPSDR

Yes technically removing frames is supported. I'm not sure about the resulting timing, can be tricky to keep sync with audio.
Are you sure there is a problem with the movies? It's possible the input driver assumes wrong fps and generates this defect.

[albino]

So my question:
Is there any solution how to do that task?

If the video is 29.97 and every 5th frame is duplicated, like ABCDD, then you can just use the built-in IVTC filter and set it to Reduce, Auto, Auto to remove the dupe frames and return it to its natural 23.976 state very easily. You might have to set the audio to Full Processing Mode to keep sync, but I'm not sure since I always have the audio set to Full Processing.

[jpsdr]

nji
You can indeed try my Remove Frames filter.
If will remove Frames removed frames at the Offset position each Frames period frames.
Assuming your Offset doesn't change on the fly. The first frame is with Offset = 0.
So, for exemple with :
Frames removed = 1
Offset = 3
Frames period = 5
With the following input :
[0][1][2][3][4] [5][6][7][8][9] [10][11][12][13][14]
Will produce the following ouput :
[0][1][2][4] [5][6][7][9] [10][11][12][14]

Frames removed = 2
Offset = 2
Frames period = 6
With the following input :
[0][1][2][3][4][5] [6][7][8][9][10][11] [12][13][14][15][16][17]
Will produce the following ouput :
[0][1][4][5] [6][7][10][11] [12][13][16][17]

[nji]

Thank you very much all three of you once again!

The cause of the "duplicated" frames probably is not the input driver,
as I get the effect not only in VD2, but also in the player,
and in different movies to different amount.

If I export it as image sequence, the "double frames" are not identical.
(The "content" of the two images is, but there are small differences in
the written png image blocks that show only in arithmetic difference) (?)

Moreover the occurrence of doubling is not always regulary, but sometimes
a kind of pattern. For example: Every second frame for about 10 frames,
and then one "no doubling" and then doubling every second again,
then a triple of duplicates, then again every second frame, ... (?)

IVTC
Thank you for the hint.
I never considered that so far.
That filter works well for the scenario you described (29,97 fps and every 5th),
and for another movie (30 fps and every 6th) it is an approvement
(although from time to time there are some new, "combed" frames).
But on the movie mentioned above (29 fps and every 2nd) it fails:
the lenght stays the same, but the fps is reduced only to 23,2 fps,
and there are still duplicated frames (less and more irregulary).

I installed jpsdr's filters now.
Try, also your other two IVTC filters.


When watching the original movies, the speed seems naturally (even for that
example above, when every second frame is doubled).

So my overall guess for the cause is some kind of frame rate conversion.

Still in my case of analyzing the movie frame by frame I have to consider
the doubling.
(Actually in all filters about time (For example: Determing the moving
parameters when DeShaking(3D) ...).
But if the pattern is not regulary (as above) then how to distinguish
a doubling from a real non-motion?
(Not for the first time I hope the devs of all that movie formats and
conversions roast in hell ;-)

[poisondeathray]

If I export it as image sequence, the "double frames" are not identical.
(The "content" of the two images is, but there are small differences in
the written png image blocks that show only in arithmetic difference) (?)


But if source used lossy compression, they might supposed to be duplicates - the difference might be due to the compression as the codec tries compensate when accounting for motion vectors.

The other time this commonly happens is frame drops. Such as low quality recording devices, such as some phones

Are these theatrical movies, or "video" shot from users ?



IVTC
Thank you for the hint.
I never considered that so far.
That filter works well for the scenario you described (29,97 fps and every 5th),
and for another movie (30 fps and every 6th) it is an approvement
(although from time to time there are some new, "combed" frames).
But on the movie mentioned above (29 fps and every 2nd) it fails:
the lenght stays the same, but the fps is reduced only to 23,2 fps,
and there are still duplicated frames (less and more irregulary).


There are other adaptive methods in avisynth you can try . Some have comb detection /removal built in, some as a second post process

[nji]

But if source used lossy compression, they might supposed to be duplicates - the difference might be due to the compression as the codec tries compensate when accounting for motion vectors.

In VD2 I exported to image sequence, using png (which is lossless).
I don't have enough knowledge of codec/ motion vectors to understand
how a (visual) duplicate frame has (not visual) small differences as image.

The other time this commonly happens is frame drops. Such as low quality recording devices, such as some phones

Are these theatrical movies, or "video" shot from users ?

All these are private taken movie from early family feast, unknown hardware/ conversion.

I don't know what "frame drops" actually mean. But there is no frame missing. If you remove the duplicate frame, the motions are fluently.



There are other adaptive methods in avisynth you can try . Some have comb detection /removal built in, some as a second post process

Up till know I was successful in not opening another new tin (avisynth). ;-)

[poisondeathray]

In VD2 I exported to image sequence, using png (which is lossless).
I don't have enough knowledge of codec/ motion vectors to understand
how a (visual) duplicate frame has (not visual) small differences as image.


Not the PNG; I'm referring to the source .




Up till know I was successful in not opening another new tin (avisynth). ;-)

You can ask for help in the avisynth subforum

[albino]

All these are private taken movie from early family feast, unknown hardware/ conversion.

Sounds like these were taken with your phone then, in which case they're all Variable Frame Rate. In my experience Virtualdub can't really convert Variable Frame Rate to Constant Frame Rate without going completely out of sync. If your intention is to edit them, then you're probably much better off using something like ffmpeg or Handbrake and forcing them to CFR first before bringing them into Virtualdub.

If anyone knows of a Virtualdub method for fixing VFR and maintaining audio sync then I would be interested in it as well.

[shekh]

Sounds like these were taken with your phone then, in which case they're all Variable Frame Rate. In my experience Virtualdub can't really convert Variable Frame Rate to Constant Frame Rate without going completely out of sync. If your intention is to edit them, then you're probably much better off using something like ffmpeg or Handbrake and forcing them to CFR first before bringing them into Virtualdub.

If anyone knows of a Virtualdub method for fixing VFR and maintaining audio sync then I would be interested in it as well.

If it is old family archive, I doubt it was taken on phone. More likely some camcorder? Probably was interlaced as well? :)

[nji]

No, the movies aren't taken by me, not by phone (but with some kind of consumer camera), not with variable frame rate, and not interlaced.
However - they are movies. ;-)

[nji]

@jpsdr:

I analysed some more of the movies in question.

Sadly, the pattern of the duplicate frames sometimes is not regular.
A typical example is: Dupe every 6th frame.
For some dozens frame.
Then the dupe arises as 5th frame.
Then the period of 6 again.
This game several times in the movie.

==> can't use your fine Remove Frames filter.

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.