[FFmpeg-user] Decimation with ppsrc=1 malfunctions

[Mark Filipak (ffmpeg)]

On 12/27/2020 01:23 PM, Paul B Mahol wrote:
> On Sun, Dec 27, 2020 at 6:45 PM Mark Filipak (ffmpeg) <markfilipak at bog.us>
> wrote:
> 
>> On 12/27/2020 06:19 AM, Paul B Mahol wrote:
>>> On Sun, Dec 27, 2020 at 5:00 AM Mark Filipak (ffmpeg) <
>> markfilipak at bog.us>
>>> wrote:
>>>
>>>> Decimation with ppsrc=1 malfunctions.
>>
>>>> Paul fixed this somewhat, but it's still in trouble.
>>>> Since I eliminated threading and decimation as the cause, I suspect that
>>>> frames numbers are being
>>>> bollixed.
>>>>
>>>> The report package is here:
>>>> https://www.dropbox.com/t/zu4cezneCJIsdmUu
>>
>>> decimate filter only drops frames, it never fixes combing.
>>
>> Of course.
>>
>>> Do you know exact telecine pattern used in your samples?
>>
>> Look at 'source.mkv frames 1018-1029.png'. I have a scenario that explains
>> why a sober engineer
>> would be forced to do what was done, but what's the point? Combing is not
>> the issue. The issue is
>> that the duplicate (modulo 5) frames found in preprocessed.mkv are not
>> being removed from source.mkv.
>>
>> source.mkv & preprocessed.mkv are 172 frames. target.mkv should be 138
>> frames. It is 138 frames, but
>> they are the wrong frames. Worse, the frames removed are not modulo 5 but
>> vary instead. The only
>> cause I could imagine was a mixup due to a threading mixup but
>> single-threading didn't solve the
>> problem.
> 
> I really wonder what is your real motivation to write so long text
> basically saying nothing.

My motivation (as always) is to get the best possible transcode given the existing source video.

> Decimate filter removes duplicated decombed frames from field match
> processing.

Combed or decombed, what does that matter? What matters is duplicated frames.

> Using it for anything other is pointless.
> 
> For default cycle of 5 it removes single frame from every 5 frames than
> have the lowest threshold.

In preprocessed.mkv every 5th frame is a repeat of frame 4. This is confirmed because decimating 
prepreocessed.mkv succeeds. However, applying decimate=ppsrc=1 does not remove the correct frames 
from source.mkv. How can that happen?

> If you wish to drop every fixed X-th frame from every cycle frames of 5 use
> shuffleframes or select filter.

I can't (easily) predict in advance which frame is the repeat. Simply removing it via decimate 
solves the first step of the problem no matter which frame is the repeated frame.

Decimate would work with source.mkv if source.mkv didn't have frame numbers burned in. But 
source.mkv does have frame numbers burned in. My approach is to cut out the burned-in frame numbers 
from source.mkv and save the target as 'preprocessed.mkv', then use preprocessed.mkv as the template 
(via decimate=ppsrc=1) to drop the correct frames from source.mkv. Bbut that didn't work. It appears 
that between preprocessed.mkv and the decimation of source.mkv, the frame numbers are getting mixed up.

Now, I know that the problem isn't with preprocessed.mkv. I know that because if I decimate 
preprocessed.mkv, the correct frames are dropped. So the problem must be the communication between 
decimate=ppsrc=1 and the handler that's dropping frames from source.mkv.