Decimate - wrong sub-text

[Strunz]

I just found out about Decimate and I really like it. I noticed, that it says "won't change the reported framerate".
I don't know exactly what this should meant but I am happy to report that it will change the framerate reported by "everything" to the new framerate (FPS), for example from 30 > 24. 



avidemux_2.8.1 r220720_win64

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

Damn, in a second test the reported framerate wasn't changed indeed. But there are no double frames ether so how is this working?
And how can I achieve that the framerate is also reported as lower? Playing the file it says 24 FPS in the output renderer, which is good.
Do I need another filter? And why it was "corrected" in the first test.

[szlldm]

And why it was "corrected" in the first test.

I don't know, how that could happened.

The "Decimate" filter throws away duplicate frames, but it simply can not know in advance how many frames will be dropped, therefore it can't determine the resulting FPS. So it simply leave the FPS metadata unchanged (in the internal processing chain of Avidemux).

[Strunz]

The "Decimate" filter throws away duplicate frames, but it simply can not know in advance how many frames will be dropped, therefore it can't determine the resulting FPS. So it simply leave the FPS metadata unchanged (in the internal processing chain of Avidemux).

That does make sense, thank you.
There is also an "Evaluation Mode". Does anyone know what it is doing? Could be that I used it for the first test.

[szlldm]

Evaluation mode is for evaluation
In that mode no frame get dropped, instead it prints frame difference information at the top left corner. So in Preview you can check what the Threshold value should be (too low value will pass through duplicates, too high drops non-duplicate frames)

[Strunz]

So in Preview you can check what the Threshold value should be (too low value will pass through duplicates, too high drops non-duplicate frames)

Thanks again, does make sense too. I thought it maybe would determine the frame rate for a "second" pass, that would explain what I have seen first but now I doubt that.

[Strunz]

One question left. After I did a full reencode with Decimate, is there a filter anywhere, which can recreate the video with the actual new framerate, without introducing new frames or removing frames, and synced audio? Lets say the removed (doubled) frames where somewhat distributed evenly in the original file.
If not, there is not much won if I used Decimate in the first place. At least my experience was still juddering...

[Strunz]

So what I do now is reencode the file (with another encoder, haven't checked if it would be the same with using avidemux again) on which decimate was used before, so far so good: The resulting file has the new frame rate, instead of the old one.

One thing I noticed though, if I am using the evaluation Mode, it often shows to me, that a value of 51 would be correct, when in fact, in all of my resulting files, the correct value always is 10. So it might be a problem of the video displaying in avidemux, that might be fixable?
I know now, I can always stick with 10 and I am good.

[eumagga0x2a]

If you actually ask for a filter or a chain of filters which should revert telecined material to its original form and fps, you might want to have a look at the topic "No decimate plugin anymore?". The Decimate filter is a wrong tool for this purpose. I am not sure there is the right tool (video filter) in Avidemux at the present time, however.

[Strunz]

If you actually ask for a filter or a chain of filters which should revert telecined material to its original form and fps, you might want to have a look at the topic "No decimate plugin anymore?".

No I am not, what I use it for is video with random doubled frames. And for that it is working good, if I do it like described before. What I don't know is why those videos have those problems... but that is not on us I guess.
Thanks!

[eumagga0x2a]

what I use it for is video with random doubled frames.

This is a complicated topic. The first question which you need to answer for yourself is whether the current video stream with duplicated pictures (most probably not duplicated frames, unless the video is Xvid/DivX-style MPEG-4 with zero-sized placeholder frames which are always P-frames and really identical) has perfectly regular DTS (a constant frame rate video).

In such a case and if the frame rate matches a standard frame rate (one of "Film" (24000/1001), non-US "Film" (24 fps exactly), "PAL" (25 or 50 fps exactly), "NTSC" (30000/1001 or twice as high – 60000/1001), 30 or 60 fps exactly) you should count the frames which will be dropped and calculate the average fps of the remaining, non-duplicate frames. If the latter matches a different, lower standard frame rate, it would be possible, albeit with additional intermediate steps (or with a yet to be written new video filter), to spread remaining frames over that lower standard frame rate. This operation is always risky regarding A/V sync.

If remaining frames don't match a standard frame rate, your stream is probably a result of applying "resampleFps" to a variable frame rate source video. In this case you better leave it as-is as it is impossible to reconstruct original, irregular timestamps.

If your stream has a variable frame rate, it is up to you to drop or not to drop duplicate pictures. I'd consider doing the former only if you have to re-encoder the video anyway.

[eumagga0x2a]

If the latter matches a different, lower standard frame rate, it would be possible, albeit with additional intermediate steps

I assumed that the video doesn't contain multiple duplicated pictures in a row, which is probably not a valid approach unless the "Decimate" filter is configured to never drop more than a single picture in a row.

[Strunz]

I am not a pro when it comes to that. But your filter does the job, although the output still has the now wrong framerate. I then open it in staxrip and do another encode. This time the endfile has the new framerate. At least that is all I can say to that.
Staxrip has one filter called "SelectEvery" where you can decide what to keep and not to keep if it is evenly across the video. But that is not the case here.

But I came here to say thanks and that it is always 10, even if it looks otherwise in the preview.

[Strunz]

I was wrong, with my "method" audio becomes totally async... I should have checked before.