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".
[FFmpeg-user] v360: filling unmapped pixels with a color
Hello, In the v360 filter the alpha_mask option can be used to make unmapped pixels transparent. What's the simplest method for filling all transparent pixels with a color? Let's assume the size of the video isn't known in advance. This command line is working as expected: ffmpeg -i input.mp4 -f lavfi -i color=red -lavfi "[0]v360=e:ball:alpha_mask=1[a];[1][a]scale2ref,overlay=shortest=1" output.mp4 But it looks unnecessary complicated to use a second input, scale it to the same size, and then use overlay. Does anybody know a better solution? The job is simple: If a pixel is transparent, then fill it with a color. I know it can be done with the geq filter, but that's too slow. Michael ___ 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] How to properly escape a literal comma ", " in drawtext filter text?
Not sure about other OS's - For Windows, you don't need to escape commas inside the text field; but the paths for fonts needs to be escaped These work ok in windows one comma ffmpeg -f lavfi -r 24 -i color=c=green:s=640x480 -vf drawtext="fontfile='C\:\\Windows\\Fonts\\Arial.ttf':text='Room Temp Water, No Heat Mat':fontcolor=white:fontsize=24: box=1:boxcolor=black@0.5:boxborderw=5:x=(w-text_w)*0.05:y=(h-text_h)*0.05" -crf 20 -an -frames:v 120 test1.mp4 -y five commas ffmpeg -f lavfi -r 24 -i color=c=green:s=640x480 -vf drawtext="fontfile='C\:\\Windows\\Fonts\\Arial.ttf':text='Room Temp Water, , , , , No Heat Mat':fontcolor=white:fontsize=24: box=1:boxcolor=black@0.5:boxborderw=5:x=(w-text_w)*0.05:y=(h-text_h)*0.05" -crf 20 -an -frames:v 120 test2.mp4 -y -- 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: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".
[FFmpeg-user] How to properly escape a literal comma ", " in drawtext filter text?
I am attempting to overlay the text, “Room Temp Water, No Heat Mat” onto some video. If I use that exact string, the comma renders as a white box. According to the drawtext documentation, I should escape the comma, but depending on the context I may have to escape the escape character before the comma, etc. Values from 0 to 7 escape slashes do not work, as they each result in a white box where I want my comma. This results in 8 white boxes: ./ffmpeg -i /Users/steven/Documents/Baking/4Up.mp4 -vf "drawtext=fontfile=/System/Library/Fonts/Keyboard.ttf: text='Room Temp Water,\,\\,\\\,,\,\\,\\\ No Heat Mat': fontcolor=white: fontsize=24: box=1: boxcolor=black@0.5: boxborderw=5: x=(w-text_w)*0.05: y=(h-text_h)*0.05" -c:v libx264 /Users/steven/Documents/Baking/TextwOverlay.mp4 What is the proper way to insert a literal comma into the text argument of drawtext? Or should I continue adding slashes until it works? ;-) Thanks! ___ 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".
