Statick
18th April 2020, 16:25
I've got a DVD source which I've indexed using DGIndex and I'm opening using MPEG2Source(file, CPU2="ooooxx"). It's an animation source which plays at 23.976fps. I've selected "force film" in DG as every episode is over 95% film, using this method the first few episodes opened and encoded cleanly. I've just reached one episode which has some bad frames in, some are obvious blends between two frames, some just exhibit very bad aliasing like the fields are mismatched. They aren't consistent throughout the video, they just come up occasionally and are annoying when they do.
I've also tried indexing with Honor Pulldown Flags and using TFM to frame match instead and this produces identical results. It would appear that these bad frames are encoded in there - the worst of it happens when the credits are on top of the image, which I suspect caused problems with the original process.
These are the problems I'm having :
The frames that are obvious blends and which have obvious clean neighbours, I'm using SRestore() to find and fix these, by replacing the bad frame with a clean neighbour. It's not doing any decimation (it's already at 23.976) and there are no double blends, it's just replacing bad frames with neighbouring good ones
sRestore(omode = 3, speed = -25, thresh = 44, dclip=last.crop(16,16,-16,-16))
This is doing a good job of finding the bad frames but it's also detecting blends where there are none, no matter what settings I use. I've tried with the threshold at max (44 according to the doc) as well as even higher values, but it still detects too many false positives. Changing the speed value from the lowest of -25 also results in too many false positives
The worst problem is a simple panning scene, in the source every frame has a small amount of movement where the scene pans across. It's a perfectly clean scene with no bad frames, but SRestore is detecting blends randomly and replacing them with neighbours, resulting in a jerky movement as one in every 5-8 frames is removed. It doesn't seem to matter how high I set the threshold.
I'm also having a similar problem with fades turning jerky as well
I've tried a few other blend removal plugins (like ExBlend and FixBlendIVTC) and these seem to come up with new problems (inserting weird messy frames) without even getting rid of the bad frames
At the moment I'm using Trim() to run SRestore() only on the worst bits but I'm worried with several hundred episodes to go, that if this is an ongoing problem on many episodes then this won't be a sustainable method
If anyone has any guidance on how to improve SRestores detection, or any better suggestions for removing blended frames, that would be great
With the badly aliased frames, these all look like what you would expect a IVTC post processor to deal with, and I've tried FieldDeinterlace(), TDeint(), IsCombedTIVTC(), but nothing seems to detect the bad frames at all, until I get the threshold low enough that it detects everything. I can hit these frames quite hard with anti aliasing and smoothing, and I've got some script that works really well to clean them up, but it kills too mcuh detail to use on the whole video. I'd like to be able to identify these frames, or at least the very worst of them, but nothing I have tried so far works. The problem seems to be that because it's showing as combing along thin lines, they don't get detected as combed areas, as really they're just badly aliased lines. I can't find any way to detect these?
I've uploaded a small clip in m2v format, the bad frames that I need to remove are visible at frames 98-103, then there's a panning shot from frame 215 onwards, and whatever process can remove the bad frames needs to also not remove any frames from here
https://drive.google.com/file/d/1hJpfgHeMVURcvP_L_j7Hfr12vHx0azyh/view?usp=sharing
I've also attached a screenshot of the aliasing problem
Finally - I'm encoding using StaxRip
If I index the VOB using "honor pulldown flags" it creates a D2V file at 29.97fps as expected. But when I open this D2V using Mpeg2Source() in StaxRip it rewrites the D2V to 23.976fps and I get the same result as if I'd indexed using force film (it actually rewrites the d2v file too, I can watch it change in a text editor). I've had to open the 29.97fps file using MeGui in order to experiment with TFM(). Any ideas why? Using TFM didn't get me any improvement so I'm not desperate to figure this out, but I'm curious as to why StaxRip is doing this
I've also tried indexing with Honor Pulldown Flags and using TFM to frame match instead and this produces identical results. It would appear that these bad frames are encoded in there - the worst of it happens when the credits are on top of the image, which I suspect caused problems with the original process.
These are the problems I'm having :
The frames that are obvious blends and which have obvious clean neighbours, I'm using SRestore() to find and fix these, by replacing the bad frame with a clean neighbour. It's not doing any decimation (it's already at 23.976) and there are no double blends, it's just replacing bad frames with neighbouring good ones
sRestore(omode = 3, speed = -25, thresh = 44, dclip=last.crop(16,16,-16,-16))
This is doing a good job of finding the bad frames but it's also detecting blends where there are none, no matter what settings I use. I've tried with the threshold at max (44 according to the doc) as well as even higher values, but it still detects too many false positives. Changing the speed value from the lowest of -25 also results in too many false positives
The worst problem is a simple panning scene, in the source every frame has a small amount of movement where the scene pans across. It's a perfectly clean scene with no bad frames, but SRestore is detecting blends randomly and replacing them with neighbours, resulting in a jerky movement as one in every 5-8 frames is removed. It doesn't seem to matter how high I set the threshold.
I'm also having a similar problem with fades turning jerky as well
I've tried a few other blend removal plugins (like ExBlend and FixBlendIVTC) and these seem to come up with new problems (inserting weird messy frames) without even getting rid of the bad frames
At the moment I'm using Trim() to run SRestore() only on the worst bits but I'm worried with several hundred episodes to go, that if this is an ongoing problem on many episodes then this won't be a sustainable method
If anyone has any guidance on how to improve SRestores detection, or any better suggestions for removing blended frames, that would be great
With the badly aliased frames, these all look like what you would expect a IVTC post processor to deal with, and I've tried FieldDeinterlace(), TDeint(), IsCombedTIVTC(), but nothing seems to detect the bad frames at all, until I get the threshold low enough that it detects everything. I can hit these frames quite hard with anti aliasing and smoothing, and I've got some script that works really well to clean them up, but it kills too mcuh detail to use on the whole video. I'd like to be able to identify these frames, or at least the very worst of them, but nothing I have tried so far works. The problem seems to be that because it's showing as combing along thin lines, they don't get detected as combed areas, as really they're just badly aliased lines. I can't find any way to detect these?
I've uploaded a small clip in m2v format, the bad frames that I need to remove are visible at frames 98-103, then there's a panning shot from frame 215 onwards, and whatever process can remove the bad frames needs to also not remove any frames from here
https://drive.google.com/file/d/1hJpfgHeMVURcvP_L_j7Hfr12vHx0azyh/view?usp=sharing
I've also attached a screenshot of the aliasing problem
Finally - I'm encoding using StaxRip
If I index the VOB using "honor pulldown flags" it creates a D2V file at 29.97fps as expected. But when I open this D2V using Mpeg2Source() in StaxRip it rewrites the D2V to 23.976fps and I get the same result as if I'd indexed using force film (it actually rewrites the d2v file too, I can watch it change in a text editor). I've had to open the 29.97fps file using MeGui in order to experiment with TFM(). Any ideas why? Using TFM didn't get me any improvement so I'm not desperate to figure this out, but I'm curious as to why StaxRip is doing this