TDeint and TIVTC

[Stereodude]

Thanks. It's most probably not TFM filter related.
With VTS_02_1_bad_sample.M2V I got the difference right at frame 14. Debugging revealed nothing. But as I was single stepping until frame 14 in vdub2 and pressed a refresh, a totally different frame came in at the very same frame #14. Totally reproducible, so it's probably the source + source filter that behaves inconsistently, because it is not returning the same frame when the Nth frame is requested. I'm using ffms2 (don't know which version) but I think probably your issue has very similar roots.
:confused: How is it not TFM related?

1) MPEG2Source is frame accurate. I don't know about ffms2 as I don't use it for MPEG-2.

2) I transcoded both of the samples to a lossless AVI that is absolutely frame accurate and used that in place of the MPEG-2 source the same thing happens. The short file works as expected the longer one doesn't.

3) What other filter in the filter chain is responsible for TFM's field matches? Why would TFM behave differently when the sequence occurs 40 frames into the clip vs. 321 frames into the clip?

[pinterf]

Going back using mpeg2source.

So that y0 parameter (band exclusion) is only used in the very first check in field matching decision (they call it of compareFields inside).
And then, bacause micmatching>0 the combing check algorithms (for myself: CheckComb) is working again on the whole frame.
The "micmatching" parameter is default = 1
When I set "micmatching"=0 the combing decision became identical for the stacked and non-stacked case.
Debug display output will report different MIC however but it seems that it does not overrides the first field matching decision.

[Stereodude]

Thank you for digging into this.

So the documentation isn't really correct. That band is not excluded from the entire field matching decision, only part of it. It seems counter-intuitive that the band is not excluded from all checks/processing that influence matching since that's the very reason why you'd want to exclude the defined band in the first place. The TFM documentation states, "An exclusion band can be used to ignore subtitles, a logo, or other things that may interfer with the matching." None of those things will interfere with matching unless they have more combing than the underlying content. If they have no combing they won't interfere and you wouldn't need to exclude them.

IMHO the y0/y1 feature is broken.

Any thoughts on why the two clips behave differently?

[pinterf]

Thank you for digging into this.

So the documentation isn't really correct. That band is not excluded from the entire field matching decision, only part of it. It seems counter-intuitive that the band is not excluded from all checks/processing that influence matching since that's the very reason why you'd want to exclude the defined band in the first place.

IMHO the y0/y1 feature is broken.


I agree, it took quite a few hours to shed light on this. At least I gained a more insider look over the internal processes. :)

The docs will be modded, and the source? Well, at the moment I do not dare to touch the other stuff to really exclude the y0-y1 bands from the checking. There are other things to do first.


Any thoughts on why the two clips behave differently?
No time now for that, we can return to it some weeks later.

Currently the whole TIVTC project is under heavy changes/refactoring (since weeks and there are some more weeks ahead) in order to have a clean and maintainable source.

What can you expect:

My target is finishing the porting to 10+ bits, and make some AVX2 stuff, and the general lookout of the source code, remove as much ciphered and copy-pasted part as I can.

As for high bit-depth project: FrameDiff is already working in 16 bits, display=true is working on my test bench for YV16 and YV24 (and 8-16 bits) as well (current release is - inheritedly - can display only for YV12 and YUY2)

And an old TFM crash bug was fixed as well.

[Stereodude]

I agree, it took quite a few hours to shed light on this. At least I gained a more insider look over the internal processes. :)

The docs will be modded, and the source? Well, at the moment I do not dare to touch the other stuff to really exclude the y0-y1 bands from the checking. There are other things to do first.
The feature was introduce in the 11/21/2004 v0.9.1 and it apparently took about 15.5 years for someone to notice that it doesn't really work as promised, so what's the hurry? :p

[bruno321]

New computer, new installation of avisynth+ 64 and megui 64. I'm having a problem with TDecimate and megui, I don't know who's the culprit. Script:

MPEG2Source("D:\projects\tests\segment.demuxed.d2v", cpu=0)
tfm()
TDecimate(hybrid=1)

AVSMeter64 output of the script:

AVSMeter 3.0.0.4 (x64), (c) Groucho2004, 2012-2020
AviSynth+ 3.5 (r3106, 3.5, x86_64) (3.5.0.0)

Number of frames: 1315
Length (hh:mm:ss.ms): 00:01:05.750
Frame width: 720
Frame height: 576
Framerate: 20.000 (20/1)
Colorspace: YV12

Frames processed: 1315 (0 - 1314)
FPS (min | max | average): 84.27 | 276.4 | 150.8
Process memory usage (max): 34 MiB
Thread count: 8
CPU usage (average): 23.6%

Time (elapsed): 00:00:08.722


However, megui 2913 x64 gives me this error:

--[Information] [6/3/2020 10:05:21 AM] Started handling job
--[Information] [6/3/2020 10:05:24 AM] Preprocessing
-[NoImage] MPEG2Source("D:\projects\tests\segment.demuxed.d2v", cpu=0)
-[NoImage] tfm()
-[NoImage] TDecimate(hybrid=1)
--[Information] [6/3/2020 10:05:24 AM] AviSynth input script
--[Information] [6/3/2020 10:05:25 AM] resolution: 720x576
--[Information] [6/3/2020 10:05:25 AM] frame rate: 20/1
--[Information] [6/3/2020 10:05:25 AM] frames: 1315
--[Information] [6/3/2020 10:05:25 AM] length: 00:01:05.750
--[Information] [6/3/2020 10:05:25 AM] aspect ratio: 5:4 (1.250)
--[Information] [6/3/2020 10:05:25 AM] color space: YV12
--[Information] [6/3/2020 10:05:25 AM] Job command line: "C:\encoding\MeGUI-2913-64\tools\x264\x264.exe" --preset veryslow --tune film --crf 20 --keyint 200 --sar 1:1 --frames 1315 --output "D:\projects\tests\segment.demuxed tfm.264" "D:\projects\tests\segment.demuxed.avs"
--[Information] [6/3/2020 10:05:25 AM] Process started
--[Information] [6/3/2020 10:05:25 AM] Standard output stream
--[Information] [6/3/2020 10:05:25 AM] Standard error stream
--[Error] [6/3/2020 10:05:27 AM] Process exits with error: 0xC0000005 STATUS_ACCESS_VIOLATION (-1073741819)
--[Information] [6/3/2020 10:05:27 AM] Job completed


When I use only tfm(), megui doesn't have a problem. Here's avsmeter64 avsinfo in case it helps:

AVSMeter 3.0.0.4 (x64), (c) Groucho2004, 2012-2020

VersionString: AviSynth+ 3.5 (r3106, 3.5, x86_64)
VersionNumber: 2.60
File / Product version: 3.5.0.0 / 3.5.0.0
Interface Version: 7
Multi-threading support: Yes
Avisynth.dll location: C:\Windows\SYSTEM32\avisynth.dll
Avisynth.dll time stamp: 2020-04-02, 16:27:26 (UTC)
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+


[C++ 2.5 Plugins (64 Bit)] [Version, Time stamp]
C:\Program Files (x86)\AviSynth+\plugins64\DGDecode.dll [1.5.8.0, 2010-03-18]

[C++ 2.6 Plugins (64 Bit)] [Version, Time stamp]
C:\Program Files (x86)\AviSynth+\plugins64+\ConvertStacked.dll [n/a, 2020-04-02]
C:\Program Files (x86)\AviSynth+\plugins64+\DirectShowSource.dll [n/a, 2020-04-02]
C:\Program Files (x86)\AviSynth+\plugins64+\ImageSeq.dll [n/a, 2020-04-02]
C:\Program Files (x86)\AviSynth+\plugins64+\Shibatch.dll [n/a, 2020-04-02]
C:\Program Files (x86)\AviSynth+\plugins64+\TimeStretch.dll [n/a, 2020-04-02]
C:\Program Files (x86)\AviSynth+\plugins64+\VDubFilter.dll [n/a, 2020-04-02]
C:\Program Files (x86)\AviSynth+\plugins64\DePan.dll [2.13.1.6, 2020-05-22]
C:\Program Files (x86)\AviSynth+\plugins64\DePanEstimate.dll [2.10.0.4, 2020-05-22]
C:\Program Files (x86)\AviSynth+\plugins64\DupStep.dll [0.0.3.0, 2020-06-03]
C:\Program Files (x86)\AviSynth+\plugins64\masktools2.dll [2.2.23.0, 2020-05-14]
C:\Program Files (x86)\AviSynth+\plugins64\mvtools2.dll [2.7.43.0, 2020-06-02]
C:\Program Files (x86)\AviSynth+\plugins64\nnedi3.dll [0.9.4.55, 2020-05-05]
C:\Program Files (x86)\AviSynth+\plugins64\RgTools.dll [1.0.0.0, 2020-04-27]
C:\Program Files (x86)\AviSynth+\plugins64\TIVTC.dll [1.0.17.0, 2020-05-12]

[Scripts (AVSI)] [Time stamp]
C:\Program Files (x86)\AviSynth+\plugins64+\colors_rgb.avsi [2020-03-12]
C:\Program Files (x86)\AviSynth+\plugins64\QTGMC.avsi [2020-06-02]
C:\Program Files (x86)\AviSynth+\plugins64\Zs_RF_Shared.avsi [2020-06-03]

[Uncategorized files] [Time stamp]
C:\Program Files (x86)\AviSynth+\plugins64+\colors_rgb.txt [2020-03-12]



[Plugin errors/warnings]
____________________________________________________________________________________________________________

"C:\Program Files (x86)\AviSynth+\plugins64\DePanEstimate.dll" requires the FFTW library for some functions.

Note: 'libfftw3f-3.dll' can be downloaded here:
http://www.fftw.org/install/windows.html

'libfftw3f-3.dll' should be placed in "System32" and/or "SysWoW64"
____________________________________________________________________________________________________________

"C:\Program Files (x86)\AviSynth+\plugins64\mvtools2.dll" requires the FFTW library for some functions.

Note: 'libfftw3f-3.dll' can be downloaded here:
http://www.fftw.org/install/windows.html

'libfftw3f-3.dll' should be placed in "System32" and/or "SysWoW64"

[pinterf]

Could you please test this build:
https://drive.google.com/open?id=1kUsTcYXtQHE7F2wrasDp8xivUFIQws0q
Replace your existing v1.0.17 TIVTC.DLL with the appropriate dll from the package.

[bruno321]

Same error.

[Groucho2004]

Same error.Are you using the "portable" (or whatever it's called) Avisynth in megui?

[bruno321]

You mean "use the included avisynth"? That's disabled.

[pinterf]

Then I'd need a source sample for which the crash still occurs because with my samples I cannot reproduce the issue.

[bruno321]

Sure. Here it is https://fex.net/s/plnfycz

Thanks for looking at it :)

[pinterf]

Sure. Here it is https://fex.net/s/plnfycz

Thanks for looking at it :)
Thanks, everything is o.k. for me, could not reproduce your issue.

[bruno321]

Seems it was a problem with DGDecode. I switched to MPEG2DecPlus and it's fine now.

[kedautinh12]

tdecimate() error, i meet too much artifact

Code: tfm().tdecimate()
Video test: https://drive.google.com/open?id=1IxbWmo4Iu5eKivW7XZmv8IN7MnS3qIjq
Frame 2533: https://drive.google.com/open?id=14jFXF_JRVTtUiwVurPaRaI-9rPS31ZJ-

[AzraelNewtype]

Japanese broadcast is often kind of messy like this. Look into JIVTC, which is much slower and harder to use but designed specifically around this problem.

[kedautinh12]

Japanese broadcast is often kind of messy like this. Look into JIVTC, which is much slower and harder to use but designed specifically around this problem.

thanks, but i meet error: "invalid arguments to function 'JIVTC'"

my scripts:
LoadPlugin("E:\MeGUI-2924-64\tools\avisynth_plugin\yadifmod.dll")
LoadPlugin("E:\MeGUI-2924-64\tools\avisynth_plugin\masktools2.dll")
LoadPlugin("E:\MeGUI-2924-64\tools\avisynth_plugin\nnedi3.dll")
Import("E:\MeGUI-2924-64\tools\avisynth_plugin\JIVTC.avsi"

JIVTC()

[StainlessS]

function JIVTC(clip c, int pattern, int "thr", bool "draft", clip "ivtced", string "bobber", bool "show")


Clip c and pattern, are non optional, so of course "JIVTC()" error aborts for missing arguments.

[pinterf]

tdecimate() error, i meet too much artifact

Code: tfm().tdecimate()
Video test: https://drive.google.com/open?id=1IxbWmo4Iu5eKivW7XZmv8IN7MnS3qIjq
Frame 2533: https://drive.google.com/open?id=14jFXF_JRVTtUiwVurPaRaI-9rPS31ZJ-
That specific part is like zooming into a fire fractal. It is really a tough task for an automatic recognition. Problem is that for some square blocks (greenish artifacts) the mask creation and thus the merge-it? decision was not successful. Since there are a zillion parameters of both filters, one can spend a week with trial and error.

[LigH]

@kedautinh12: "clip c" may implicitly be "last" after a source filter; but the explicit pattern will be mandatory.

[pinterf]

And finally after many months of reverse engineering, de-copypasting, refactoring and feature adding:

Download TIVTC 1.0.19 and TDeint 1.6 suite (https://github.com/pinterf/TIVTC/releases/tag/v1.0.19), supporting full 8-16 bits and all planar formats (and YUY2)

That was probably my hardest project so far.

I hope not much bugs will be reported but since it was a huge reconstruction there will surely be some of them.

Enjoy.

Probably there will be at least one more update later with more SIMD accelerated stuff for 10+ bits (not to mention the bugfixes)

[Myrsloik]

And finally after many months of reverse engineering, de-copypasting, refactoring and feature adding:

Download TIVTC 1.0.19 and TDeint 1.6 suite (https://github.com/pinterf/TIVTC/releases/tag/v1.0.19), supporting full 8-16 bits and all planar formats (and YUY2)

That was probably my hardest project so far.

I hope not much bugs will be reported but since it was a huge reconstruction there will surely be some of them.

Enjoy.

Probably there will be at least one more update later with more SIMD accelerated stuff for 10+ bits (not to mention the bugfixes)

Just one question:

Why did you do it?

[pinterf]

A sort of entertainment. Instead of solving crossword puzzles.

[real.finder]

And finally after many months of reverse engineering, de-copypasting, refactoring and feature adding:

Download TIVTC 1.0.19 and TDeint 1.6 suite (https://github.com/pinterf/TIVTC/releases/tag/v1.0.19), supporting full 8-16 bits and all planar formats (and YUY2)

That was probably my hardest project so far.

I hope not much bugs will be reported but since it was a huge reconstruction there will surely be some of them.

Enjoy.

Probably there will be at least one more update later with more SIMD accelerated stuff for 10+ bits (not to mention the bugfixes)

thanks for the update :thanks:

[FranceBB]

And finally after many months of reverse engineering, de-copypasting, refactoring and feature adding:

Download TIVTC 1.0.19 and TDeint 1.6 suite (https://github.com/pinterf/TIVTC/releases/tag/v1.0.19), supporting full 8-16 bits and all planar formats (and YUY2)

That was probably my hardest project so far.

I hope not much bugs will be reported but since it was a huge reconstruction there will surely be some of them.

Enjoy.

Probably there will be at least one more update later with more SIMD accelerated stuff for 10+ bits (not to mention the bugfixes)

10bit tdeint is definitely useful for Panasonic P2 since they're based on AVC-Intra Class which is essentially is H.264 10bit interlaced, so it's indeed something nice to have.
I haven't found anything interlaced higher than 10bit planar, but still since you made it 16bit compatible I'll just say that it's just good to have. :)

A sort of entertainment. Instead of solving crossword puzzles.

Please never turn to crossword puzzles, we need your dedication to this other kind of "entertainment" xD

Jokes aside, thank you. :)

[LigH]

Cheers to the dedicated restless...

https://cosgan.de/images/smilie/musik/n015.gif

[kedautinh12]

@kedautinh12: "clip c" may implicitly be "last" after a source filter; but the explicit pattern will be mandatory.

Thanks, it's work but didn't fixed my problem

[LigH]

Then - how does your script look now, and which error appears now?

LoadPlugin("E:\MeGUI-2924-64\tools\avisynth_plugin\yadifmod.dll")
LoadPlugin("E:\MeGUI-2924-64\tools\avisynth_plugin\masktools2.dll")
LoadPlugin("E:\MeGUI-2924-64\tools\avisynth_plugin\nnedi3.dll")
Import("E:\MeGUI-2924-64\tools\avisynth_plugin\JIVTC.avsi"

# JIVTC() -- invalid arguments to function 'JIVTC' -- pattern is missing

# you have to try one of the following:
JIVTC(0)
# JIVTC(1)
# JIVTC(2)
# JIVTC(3)
# JIVTC(4)

[kedautinh12]

Then - how does your script look now, and which error appears now?

LoadPlugin("E:\MeGUI-2924-64\tools\avisynth_plugin\yadifmod.dll")
LoadPlugin("E:\MeGUI-2924-64\tools\avisynth_plugin\masktools2.dll")
LoadPlugin("E:\MeGUI-2924-64\tools\avisynth_plugin\nnedi3.dll")
Import("E:\MeGUI-2924-64\tools\avisynth_plugin\JIVTC.avsi"

# JIVTC() -- invalid arguments to function 'JIVTC' -- pattern is missing

# you have to try one of the following:
JIVTC(0)
# JIVTC(1)
# JIVTC(2)
# JIVTC(3)
# JIVTC(4)

I already know but i try from 0 to 5 and my problem in video didn't fixed with JIVTC

[LigH]

So, what exactly is the problem? Is there an error message instead of a filtered video? Or is just the result of the filtering not satisfying?

[StainlessS]

kedautinh12
That cannot be your full script, where do you get your clip from ?, post your FULL script as asked already by LigH,
and also answer LigH questions in prev post.

[kedautinh12]

So, what exactly is the problem? Is there an error message instead of a filtered video? Or is just the result of the filtering not satisfying?

The result of the filtering not satisfying

My full scripts:
FFVideoSource("D:\RADWIMPS - Daijoubu [1440x1080i MPEG2 M-ON! HD].ts", fpsnum=30000, fpsden=1001, threads=1, colorspace="YUV420P8")
tfm().JIVTC(5)

Result have many artifact, my example in frame 2544:
https://drive.google.com/open?id=1IetWJ4aiNnM1XNWZZ6xYoZCrR3pIfIzG

[LigH]

I got clip from private torrent page ...

In this case, your answer may be in chapter #6 of this document (http://forum.doom9.org/forum-rules.htm).

[colinhunt]

Gents, I need help with TFM/TDecimate. I ripped a Japanese music video from Blu-ray for deinterlacing and ivtc'ing from 29.97 to 23.976, but it refuses to co-operate and driving me bonkers. I'm seeing duplicate frames mostly around scene changes, before or after, and nothing I try gets rid of the duplicates. I'm using
Staxrip as the front-end. Mediainfo reports source .m2ts as 29.970 fps MBAFF & TFF.

So far I've tried, in addition to defaults, various combinations of TFM and TDecimate modes, some of TFM's PP modes, TFM set to slowest/best accuracy, outputting metrics into an external file during 1st pass and reading it in pass 2 (both TFM and TDecimate), both short and long cycle/cycleR values on TDecimate, sceneThresh settings both small & large, noise threshold of 0 and 1 for metrics calculations, blockx and blocky values of 4 and 8, hints enabled & disabled, and maxndl values between 4-6.

I'm pretty much tearing my hair out here so any advice/tips are very much welcome.

[FranceBB]

Gents, I need help with TFM/TDecimate. I ripped a Japanese music video from Blu-ray for deinterlacing and ivtc'ing from 29.97 to 23.976, but it refuses to co-operate and driving me bonkers. I'm seeing duplicate frames mostly around scene changes, before or after, and nothing I try gets rid of the duplicates. I'm using
Staxrip as the front-end. Mediainfo reports source .m2ts as 29.970 fps MBAFF & TFF.

So far I've tried, in addition to defaults, various combinations of TFM and TDecimate modes, some of TFM's PP modes, TFM set to slowest/best accuracy, outputting metrics into an external file during 1st pass and reading it in pass 2 (both TFM and TDecimate), both short and long cycle/cycleR values on TDecimate, sceneThresh settings both small & large, noise threshold of 0 and 1 for metrics calculations, blockx and blocky values of 4 and 8, hints enabled & disabled, and maxndl values between 4-6.

I'm pretty much tearing my hair out here so any advice/tips are very much welcome.

A sample would be welcomed.

In the meantime, can you try with:

tfm(mode=1,pp=5,slow=2,micmatching=2,clip2=tdeint(mode=2,type=3))
tdecimate()

and let me know? That's what I use whenever I find something telecined.

[pinterf]

Meanwhile a v20 was released with a hotfix addressing a crash in v19 when PP=1 and display=true

[colinhunt]

and let me know? That's what I use whenever I find something telecined.
Thank you for replying, I appreciate it!

I tested your config, and while I saw less duplicates, some still lingered. I also saw blended frames which didn't happen in my previous experiments.

Here's a 45 second clip from the start of the video, cut with ffmpeg -c copy and output to .m2ts to match the original: https://drive.google.com/file/d/1sToixVK2_pPiAYpKzpRaON9Vsf2APEcP/view?usp=sharing

There's a scene change at 00:22.109 or thereabouts which seems like a very tricky bit; there's always a duplicate frame either right before the cut or immediately after. Previous cut, at approx 00:20.941, comes also out with a duplicate frame before or after, most of the time. That's where your config created a blended frame at, btw.

It also occurred to me that perhaps this video was actually shot in 29.97 fps instead of 23.98, but looking at the clip frame-by-frame in its original interlaced form, for example the hand movement starting at 00:22.843, makes it seem like the original frame rate wasn't 29.97. I could be mistaken, of course.

[colinhunt]

Meanwhile a v20 was released with a hotfix addressing a crash in v19 when PP=1 and display=true
I can't even begin to tell you how much I appreciate your continuing contributions. Keep up the great work!

[kedautinh12]

https://drive.google.com/file/d/1stoixvk2_ppiaypkzpraon9vsf2apecp/view?usp=sharing



snsd?

[colinhunt]

snsd?
Absolutely.

[zybex]

I need help with TFM/TDecimate. I ripped a Japanese music video from Blu-ray for deinterlacing...
I'm pretty much tearing my hair out here so any advice/tips are very much welcome.

Is it OK for you ?
https://mega.nz/file/X4oTCaAR#gk4A2PwVxalWVtyZ2Hpnre5oGuOG48Na5MVXVCDqOXQ

[colinhunt]

Is it OK for you ?
https://mega.nz/file/X4oTCaAR#gk4A2PwVxalWVtyZ2Hpnre5oGuOG48Na5MVXVCDqOXQ
Well, no. That's been deinterlaced only and runs at 29.97 fps with a duplicate frame in every 5-frame segment. Not what I was trying to achieve. Thanks for giving it a shot, though.

[hello_hello]

I'm a bit rushed so I can't check the whole thing frame by frame now, but the scene change you mentioned seems to be duplicate free if you do this:

TFM(micmatching=0).TDecimate()

I think there's telecine each side of the scene change, and possibly an orphaned field or two (shoot me if I sound like Katie), and maybe in an attempt to make it a whole frame TFM is trying too hard to find a matching field, so when it does it creates an extra duplicate frame instead of dropping the orphaned fields. Or maybe that's a load of bullocks.... :)

taxi_clip.mkv (https://www.udrop.com/a0g/taxi_clip.mkv)

[colinhunt]

I'm a bit rushed so I can't check the whole thing frame by frame now, but the scene change you mentioned seems to be duplicate free if you do this
Thank you for taking the time! I went through your clip frame-by-frame, and found only two instances of frame duplicates (at 00:27.110 and 00:44.169), neither of which were in the tricky section I described. Very promising indeed! I'll process the entire video with micmatching disabled and we'll see what happens. Thanks!

[hello_hello]

00:44.169 is the last frame, so I'm not sure it should count, especially as the video was cut at the end.

It looks as though the duplicate frame around 00:27.110 might have been a decoding oddity. I've decided to pretend it didn't happen once I've finished typing this post, but I couldn't work out why there was a duplicate frame encoded, yet I couldn't see one looking at the script, until I remembered I indexed and decoded with ffms2 last time and Lsmash this time, so I tried ffms2 again and sure enough, the duplicate frame re-appeared. Back to Lsmash, no duplicate.

I'm using XP compatible versions of lsmash and ffms2, so hopefully it's just an "old ffms2" thing.

[colinhunt]

00:44.169 is the last frame, so I'm not sure it should count, especially as the video was cut at the end.
Yeah, good point.

It looks as though the duplicate frame around 00:27.110 might have been a decoding oddity.
I'll stick with Lsmash then; should have time to finally test this out today. Thanks!

[FranceBB]

I'm using XP compatible versions of lsmash and ffms2, so hopefully it's just an "old ffms2" thing.

Why old? ffms2 C plugin XP compatible was last updated on the 3rd of May 2020 here: https://rwijnsma.home.xs4all.nl/files/ffms2/
You'll find next updated builds on that website.
Reino keeps both ffmpeg and ffms2 updated and XP Compatible.

[manolito]

Reino keeps both ffmpeg and ffms2 updated and XP Compatible.

Not only XP compatible, Reino's builds do not even require a SSE2 capable CPU. Plus these builds are extremely well tested and totally reliable.

Now that the Zeranoe forum has disappeared it is a little bit hard to find Reino's builds. I hope that he will open a new thread about his builds right here at Doom9... :D

[StainlessS]

FranceBB,
Methinks that you are just the guy to maintain thread/list of all things XP compatible,
wadya think HH, is he the guy ?
EDIT: Same Q to Mani.

[colinhunt]

Back to Lsmash, no duplicate.
For some unfathomable reason LSMASH refuses to open the source .m2ts. I can't understand why. An issue with Staxrip 2.1.1.4?

LWLibavVideoSource opens it fine, but micmatching=0 doesn't produce the results I hoped for: a duplicate frame raises its ugly head at 00:21.355. Did not bother to check the rest of the file, tbh.

Tested DSS2 as a source filter; opens .m2ts fine but same duplicate frame pops up. I even gave VapourSynth a shot, with VFM and VDecimate, to a horrible result of duplicate frames everywhere.