Am 19.07.19 um 09:18 schrieb Moritz Barsnick: > On Fri, Jul 19, 2019 at 00:21:53 +0200, Ulf Zibis wrote: >> ./ffmpeg -y -v warning -i debug/CYD_1.5m_x264.mp4 -vf >> select='eq(t\,10.16)+eq(t\,10.2)+eq(t\,10.24)+eq(t\,10.28)+eq(t\,10.32)+eq(t\,10.36)+eq(t\,10.4)+eq(t\,10.44)+eq(t\,17.52)+eq(t\,47.96)+eq(t\,49.08)+eq(t\,49.2)+eq(t\,55.72)+eq(t\,83.0)' >> -q 5 -c:a copy -vsync vfr debug/outsides/CYD_1.5m_x264_%02d.png > [...] >> [Parsed_lineshiftrecover_0 @ 0x55798cbf8f80] frame: 255, pts: >> 130560, time: 0:10.2 - optimal shift in line 570 against 569 seems >> outside of span (-60 - 60), was: 60 >> [Parsed_lineshiftrecover_0 @ 0x55798cbf8f80] frame: 255, pts: >> 130560, time: 0:10.2 - optimal shift in line 572 against 571 seems >> outside of span (-60 - 60), was: 60 > I'm not sure how ffmpeg's expression evaluation calculates 't' (means I > couldn't find it in the source), but seeing that your av_ts2minutestr() > certainly does it differently, I may point out: floating point equality > is a bitch. ;-) I'm saying: 10.2 may not be equal to 10.2, > computer-mathematically speaking. Yes, this may be the source of the problem I am facing.
My av_ts2minutestr() does pure integer calculation, so the values I get from time_base 1/12800 should be exact. See my patch from 03.07.2019, 19:09 CEST in the ffmpeg-devel list. -Ulf _______________________________________________ ffmpeg-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
