[FFmpeg-user] Decimation with ppsrc=1 malfunctions

[Paul B Mahol]

On Sun, Dec 27, 2020 at 7:53 PM Mark Filipak (ffmpeg) <markfilipak at bog.us>
wrote:

> 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.
>

I dunno what is your issue with decimate filter, but I just fixed behavior
with ppsrc=1 handling when output would not match VIVTC from VDecimate
filter.
Previously wrong frames would be dropped, the spots for dropped frames are
still at correct place and works as intended.



> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".