On 12/27/2020 01:23 PM, Paul B Mahol wrote:
On Sun, Dec 27, 2020 at 6:45 PM Mark Filipak (ffmpeg) <markfili...@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) <
markfili...@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.
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
