Mark Filipak (ffmpeg) wrote > 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. Only then will > fps=fps=48000/1001 actually > double each frame without dropping any -- without such assurance, if any > particular frame happens to > have a PTS that's 'faster' than 24000/1001fps, then the shift to > 48000/1001fps would drop it because > the fps filter works solely at the frame level.
<sorry I was using a web client, sometimes message not posted correctly > 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 normal MKV pts: 42 pts_time:0.042 pts: 83 pts_time:0.083 pts: 125 pts_time:0.125 -vf fps=24000/1001 pts: 1 pts_time:0.0417083 pts: 2 pts_time:0.0834167 pts: 3 pts_time:0.125125 -vf "fps=24000/1001,settb=1/720000,setpts=N*30030" pts: 30030 pts_time:0.0417083 pts: 60060 pts_time:0.0834167 pts: 90090 pts_time:0.125125 -- 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".