Re: [FFmpeg-user] Decimation with ppsrc=1 malfunctions
On 12/27/2020 04:26 PM, Paul B Mahol wrote: On Sun, Dec 27, 2020 at 7:56 PM pdr0 wrote: pdr0 wrote I don't know if it's the full explanation... The way it should work is ppsrc should disable everything else , given if input src ,and ppsrc have the exact same timecodes In theory, you should get same as -vf decimate on preprocessed.mkv ffmpeg -i preprocessed.mkv -vf decimate -c:v libx264 -crf 18 -an preprodec.mkv gives drops at - 1019,1024,1029... The interval is different and there are 2 more frames , 138 vs. 136 ffmpeg -i preprocessed.mkv -vf decimate=scthresh=0 -c:v libx264 -crf 18 -an preprodec2.mkv -y gives 138 frames when run alone, but 136 frames when run with 2 inputs and ppsrc=1 . It's still unexpected behaviour Should be fixed. Thank you, folks! It makes all the hours spent working to make a good submission worth the effort and time. So, I see this: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=89dcef90af5b444b446ed888486ea9326e9a1141 What's the logistics here? When will I see a commit and new build? What will I look for, or do I simply wait until tomorrow and download the latest build? I apologize for asking but this is all uncharted territory to me. Regards and Happy 2021 to everyone, Mark. ___ 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".
Re: [FFmpeg-user] Decimation with ppsrc=1 malfunctions
On Sun, Dec 27, 2020 at 7:56 PM pdr0 wrote: > pdr0 wrote > > I don't know if it's the full explanation... > > > > The way it should work is ppsrc should disable everything else , given if > > input src ,and ppsrc have the exact same timecodes > > > > > > In theory, you should get same as -vf decimate on preprocessed.mkv > > > > ffmpeg -i preprocessed.mkv -vf decimate -c:v libx264 -crf 18 -an > > preprodec.mkv > > > > gives drops at - 1019,1024,1029... > > > > > > > > The interval is different and there are 2 more frames , 138 vs. 136 > > ffmpeg -i preprocessed.mkv -vf decimate=scthresh=0 -c:v libx264 -crf 18 -an > preprodec2.mkv -y > > gives 138 frames when run alone, but 136 frames when run with 2 inputs and > ppsrc=1 . > > It's still unexpected behaviour > Should be fixed. > > > > -- > Sent from: http://www.ffmpeg-archive.org/ > ___ > 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". ___ 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".
Re: [FFmpeg-user] Decimation with ppsrc=1 malfunctions
On Sun, Dec 27, 2020 at 7:53 PM Mark Filipak (ffmpeg) wrote: > 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. > 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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". ___ 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".
Re: [FFmpeg-user] Decimation with ppsrc=1 malfunctions
pdr0 wrote > I don't know if it's the full explanation... > > The way it should work is ppsrc should disable everything else , given if > input src ,and ppsrc have the exact same timecodes > > > In theory, you should get same as -vf decimate on preprocessed.mkv > > ffmpeg -i preprocessed.mkv -vf decimate -c:v libx264 -crf 18 -an > preprodec.mkv > > gives drops at - 1019,1024,1029... > > > > The interval is different and there are 2 more frames , 138 vs. 136 ffmpeg -i preprocessed.mkv -vf decimate=scthresh=0 -c:v libx264 -crf 18 -an preprodec2.mkv -y gives 138 frames when run alone, but 136 frames when run with 2 inputs and ppsrc=1 . It's still unexpected behaviour -- Sent from: http://www.ffmpeg-archive.org/ ___ 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".
Re: [FFmpeg-user] Decimation with ppsrc=1 malfunctions
On 12/27/2020 01:23 PM, Paul B Mahol wrote: On Sun, Dec 27, 2020 at 6:45 PM Mark Filipak (ffmpeg) 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".
Re: [FFmpeg-user] Decimation with ppsrc=1 malfunctions
I don't know if it's the full explanation... The way it should work is ppsrc should disable everything else , given if input src ,and ppsrc have the exact same timecodes In theory, you should get same as -vf decimate on preprocessed.mkv ffmpeg -i preprocessed.mkv -vf decimate -c:v libx264 -crf 18 -an preprodec.mkv gives drops at - 1019,1024,1029... The interval is different and there are 2 more frames , 138 vs. 136 -- Sent from: http://www.ffmpeg-archive.org/ ___ 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".
Re: [FFmpeg-user] Decimation with ppsrc=1 malfunctions
On Sun, Dec 27, 2020 at 7:33 PM pdr0 wrote: > One issue is scene change is still active. When you crop to a region of > interest, a small change is effectively a larger % change. eg. The delta > between 1020 and 1021 is large when head is going up. If you disable scene > change, you get set intervals, it's no longer adaptive by scene change. > > -filter_complex "[0:0][1:0]decimate='ppsrc=1':scthresh=0" > > Drops become regular 1012,1017,1022,1027,1032 > > > > Other differences are preprocessed.mkv is a lossy version and encoded > progressively instead of interlaced or mbaff. There are motion vectors that > cross fields that shouldn't, so you get motion when you shouldn't when you > examine individual fields. ie. Fields are "muddied" in preprocessed.mkv . > > Also the chroma encoding is different when you encode progressively. You > can > see the colored edges are different on some fields. You can set chroma=0 to > disable, or use a proper prepreprocessed version (Lossless and encoded with > mbaff) > > These latter two aren't the explanation in this specific case, but you > should test with original source, or lossless versions > Exactly I completely overlooked this fact. > > > > > -- > Sent from: http://www.ffmpeg-archive.org/ > ___ > 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". ___ 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".
Re: [FFmpeg-user] Decimation with ppsrc=1 malfunctions
One issue is scene change is still active. When you crop to a region of interest, a small change is effectively a larger % change. eg. The delta between 1020 and 1021 is large when head is going up. If you disable scene change, you get set intervals, it's no longer adaptive by scene change. -filter_complex "[0:0][1:0]decimate='ppsrc=1':scthresh=0" Drops become regular 1012,1017,1022,1027,1032 Other differences are preprocessed.mkv is a lossy version and encoded progressively instead of interlaced or mbaff. There are motion vectors that cross fields that shouldn't, so you get motion when you shouldn't when you examine individual fields. ie. Fields are "muddied" in preprocessed.mkv . Also the chroma encoding is different when you encode progressively. You can see the colored edges are different on some fields. You can set chroma=0 to disable, or use a proper prepreprocessed version (Lossless and encoded with mbaff) These latter two aren't the explanation in this specific case, but you should test with original source, or lossless versions -- Sent from: http://www.ffmpeg-archive.org/ ___ 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".
Re: [FFmpeg-user] Decimation with ppsrc=1 malfunctions
On 12/27/2020 07:30 AM, Carl Eugen Hoyos wrote: Am 27.12.2020 um 12:19 schrieb Paul B Mahol : Do you know exact telecine pattern used in your samples? I don’t think the sample is telecined... It must have been. Now, bear with me. 1, The original video was p24: [A/a][B/b][C/c][D/d] 2, Later, it was telecined: [A/a][B/b][B/c][C/d][D/d] 3, Later, a modulo-5 frame was dropped [1]: [A/a][B/c][C/d][D/d] 4, Later, a modulo-4 frame was repeated: [A/a][B/c][C/d][D/d][D/d] [1] Dropping a frame in lieu of detelecine was a mistake. Perhaps the engineer was drunk. ... or at least whatever was done with it can’t be undone (even the description confirms this)... Ah! But it can be undone (sort of): Decimate to: [A/a][B/c][C/d][D/d] Then synthesize a frame: [A/a][B/B][B/c][C/d][D/d] Then detelecine: [A/a][B/B][C/c][D/d] ... so this part of the discussion seems moot. I agree. It's moot because it doesn't bear on why decimate=ppsrc=1 isn't working correctly. ___ 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".
Re: [FFmpeg-user] Decimation with ppsrc=1 malfunctions
On Sun, Dec 27, 2020 at 6:45 PM Mark Filipak (ffmpeg) 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. Decimate filter removes duplicated decombed frames from field match processing. 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. If you wish to drop every fixed X-th frame from every cycle frames of 5 use shuffleframes or select filter. > > Over to you... :-) > ___ > 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". ___ 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".
Re: [FFmpeg-user] Decimation with ppsrc=1 malfunctions
On 12/27/2020 06:19 AM, Paul B Mahol wrote: On Sun, Dec 27, 2020 at 5:00 AM Mark Filipak (ffmpeg) 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. Over to you... :-) ___ 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".
Re: [FFmpeg-user] Decimation with ppsrc=1 malfunctions
> Am 27.12.2020 um 12:19 schrieb Paul B Mahol : > > Do you know exact telecine pattern used in your samples? I don’t think the sample is telecined, or at least whatever was done with it can’t be undone (even the description confirms this), so this part of the discussion seems moot. My suspicion is that Mark wants a combination of select and setpts filters to drop certain frames. Carl Eugen ___ 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".
Re: [FFmpeg-user] Decimation with ppsrc=1 malfunctions
On Sun, Dec 27, 2020 at 5:00 AM Mark Filipak (ffmpeg) 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. Do you know exact telecine pattern used in your samples? > Expires Jan 2, 2021. > ___ > 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". ___ 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".
