Am 19.07.19 um 11:22 schrieb Stéphane Chauveau: > On 7/19/19 9:18 AM, Moritz Barsnick wrote: >> 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 >> 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. > > Using eq() on floating points is indeed a bad idea because of floating > point rounding. In the code of the select filter I've found: #define TS2D(ts) ((ts) == AV_NOPTS_VALUE ? NAN : (double)(ts)) select->var_values[VAR_T ] = TS2D(frame->pts) * av_q2d(inlink->time_base);
So there rounding happens twice. This could be avoided with: select->var_values[VAR_T ] = (frame->pts == AV_NOPTS_VALUE) ? NAN : frame->pts * inlink->time_base.num / inlink->time_base.den; But after applying this I got even worse results, so there must be another rounding counterpart somewhere which "heals" most rounding issues, but not all as I can see with "10.2" from my example. -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".
