On 2021-04-01 11:41, pdr0 wrote: > Mark Filipak (ffmpeg) wrote >> On 2021-04-01 07:13, Mark Filipak (ffmpeg) wrote: >>> The source is MKV. MKV has a 1/1000 TB, so any PTS variance should be >>> less than 0.1%. >>> >>> The filter complex is thinned down to just this: settb=1/720000,showinfo >>> >>> Here is selected lines from the showinfo report (with ...comments): >>> >>> [Parsed_showinfo_1 @ 00000247d719ef00] config in time_base: 1/720000, >>> frame_rate: 24000/1001 >>> ...So, deltaPTS (calculated: 1/TB/FR) should be 30030. >>> [Parsed_showinfo_1 @ 00000247d719ef00] n: 1 pts: 30240 ...should be >>> 30030 >>> [Parsed_showinfo_1 @ 00000247d719ef00] n: 2 pts: 59760 ...should be >>> 60060 >>> [Parsed_showinfo_1 @ 00000247d719ef00] n: 3 pts: 90000 ...should be >>> 90090 >>> [Parsed_showinfo_1 @ 00000247d719ef00] n: 4 pts: 120240 ...should be >>> 120120 >>> >>> The PTS variance is 0.7%. >>> >>> Why are PTS values different from what's expected? >>> >>> Note: If I force deltaPTS via setpts=N*30030, then of course I get >>> what's >>> expected. >>> >>> Thanks. This is critical and your explanation is greatly appreciated! >>> Mark. >> >> UPDATE >> >> If I change the filter complex to this: >> >> settb=1/720000,setpts=N*30030,fps=fps=48000/1001,showinfo >> >> all my follow-on processing goes straight into the toilet. >> >> Explanation of the factors in the filter complex: >> settb=1/720000 ...mandate 1.3[8..] ms time resolution >> setpts=N*30030 ...force the input to exactly 24000/1001fps cfr >> fps=fps=48000/1001 ...frame double >> >> However, fps=fps=48000/1001 does more than just frame double. It resets >> TB >> to 20.8541[6..] ms time >> resolution. Look: >> >> [Parsed_showinfo_3 @ 000001413bf0ef00] config in time_base: 1001/48000, >> frame_rate: 48000/1001 >> [Parsed_showinfo_3 @ 000001413bf0ef00] n: 0 pts: 0 >> [Parsed_showinfo_3 @ 000001413bf0ef00] n: 1 pts: 1 >> [Parsed_showinfo_3 @ 000001413bf0ef00] n: 2 pts: 2 >> [Parsed_showinfo_3 @ 000001413bf0ef00] n: 3 pts: 3 >> >> Gee, I wish the fps filter documention said that it changes TB and sets >> deltaPTS to '1'. >> >> My follow-on frame processing can't tolerate 20.8541[6..] ms time >> resolution -- that explains why my >> mechanical frame gynmastics have been failing! >> >> Explanation: My follow-on processing does fractional frame adjustment >> that >> requires at least >> 8.341[6..] ms resolution. >> >> Workaround: I can frame double by another method that's somewhat ugly but >> that I know works and >> doesn't trash time resolution. > > Did you try changing the order? ie. -vf fps first ?
Before the 'settb=1/720000,setpts=N*30030'? That wouldn't be appropriate because I need to guarantee that the input is forced to 24000/1001fps cfr, first. > That's what -vf fps=24000/1001 does. It forces 24000/1001 CFR. Use it first I'm sure it was mentioned in one of your other threads -vf fps=24000/1001 pts_time:0.0417083 pts_time:0.0834167 pts_time:0.125125 normal MKV pts_time:0.042 pts_time:0.083 pts_time:0.125 -- Sent from: http://ffmpeg-users.933282.n4.nabble.com/ _______________________________________________ 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".