From: Marton Balint <cus@passwd.hu> To: Allan Cady via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH] libavutil/timestamp.h: Fix loss of precision in timestamps for silencedetect on long files Date: Thu, 22 Feb 2024 10:16:07 +0100 (CET) Message-ID: <0430c2a6-2e6a-ec15-24b3-409c55055dd5@passwd.hu> (raw) In-Reply-To: <1143270169.3066257.1708564887911@mail.yahoo.com> On Thu, 22 Feb 2024, Allan Cady via ffmpeg-devel wrote: > I had a similar thought, as all timestamps would have the same issue. > > This is my first contribution here, and I don't know the code very well, > so I was being cautious. I'm open to expanding the scope, but I'm sure I > would need some help doing it right and not breaking things. > > For starters, I'm curious why there are two functions & macros: > > av_ts2str/av_ts_make_string (which used "%" format specifier) That takes a 64-bit integer timestamp and is actually using "%"PRId64 because that is the correct (portable) format string for an int64_t variable. > av_ts2timestr/av_ts_make_time_string (which used "%6g") That takes an integer timestamp and a rational time base. Float timestamps (in seconds) is calculated by multiplying the two, that is what is printed. > > Do you know the rationale for that? I see that only av_ts2timestr is used in silencedetect.c. > > And are you suggesting we should fold those two functions into one? No, they have different purpose. The first prints out a timestamps which can be in any time base. The second prints out a timestamp in seconds. > > I did notice something in the output from silencedetect. After I made my > change, I see the output is now: > > > frame:92404 pts:53224175 pts_time:2413.79 > lavfi.silence_start=2411.120272 > frame:92411 pts:53228207 pts_time:2413.98 > lavfi.silence_end=2413.992744 > lavfi.silence_duration=2.872472 > > > I see that the pts_time values still have the original formatting. I > don't know what pts_time is, or where those lines are coming from. Seems > like maybe those should have fixed precision as well. Well, that is likely using the same function, but you only fixed silencedetect, right? > > Guidance for a noob please? Thanks. > > (P.S. Can you tell me, when I reply to the list (as opposed to patch > submission using git send-email), how should I address the email? > Obviously it should go to ffmpeg-devel@ffmpeg.org, but should I include > you as a recipient, or as a cc:, or only to the list? or is there some > other way it gets directed to you? Any other guidance on how to format > email? Thanks.) I don't think there is a rule, I have seen it happen both with or without CC. You don't need to CC me though, as I am a regular on the list, but others may have other preference. Regards, Marton PS: Please avoid top positing in you replies. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2024-02-22 9:16 UTC|newest] Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <20240221073915.26055-1-allancady.ref@yahoo.com> 2024-02-21 7:39 ` Allan Cady via ffmpeg-devel 2024-02-21 20:25 ` Marton Balint 2024-02-22 1:21 ` Allan Cady via ffmpeg-devel 2024-02-22 9:16 ` Marton Balint [this message] 2024-02-23 21:44 ` Allan Cady via ffmpeg-devel 2024-02-23 21:48 ` Allan Cady via ffmpeg-devel 2024-02-23 22:47 ` Marton Balint 2024-03-11 2:56 ` [FFmpeg-devel] [PATCH] When the silencedetect filter is run against long files, the output timestamps gradually lose precision as the scan proceeds further into the file. This is because the output is formatted (in libavutil/timestamp.h) as "%.6g", which limits the total field length. Eventually, for offsets greater than 100000 seconds (about 28 hours), fractions of a second disappear altogether, and the timestamps are logged as whole seconds Allan Cady via ffmpeg-devel 2024-03-11 13:43 ` Andreas Rheinhardt 2024-03-11 14:26 ` Andreas Rheinhardt 2024-03-11 19:49 ` epirat07 2024-03-11 23:46 ` [FFmpeg-devel] [libavutil/timestamp.h: Fix loss of precision in timestamps for silencedetect on long files] Allan Cady via ffmpeg-devel 2024-03-11 19:11 ` [FFmpeg-devel] [PATCH] change av_ts_make_time_string precision Marton Balint 2024-03-12 2:57 ` Allan Cady via ffmpeg-devel 2024-03-12 21:24 ` Marton Balint 2024-03-13 6:03 ` Allan Cady via ffmpeg-devel 2024-03-17 23:40 ` [FFmpeg-devel] [PATCH] avutil/timestamp: keep microsecond precision in av_ts_make_time_string Marton Balint 2024-03-19 21:14 ` Marton Balint 2024-03-19 23:38 ` Andreas Rheinhardt 2024-03-20 12:44 ` Andreas Rheinhardt 2024-03-20 19:51 ` Marton Balint 2024-03-22 21:50 ` Marton Balint 2024-03-22 21:58 ` Andreas Rheinhardt 2024-03-23 11:14 ` [FFmpeg-devel] [PATCH v2 1/2] avutil/timestamp: introduce av_ts_make_time_string2 for better precision Marton Balint 2024-03-23 11:14 ` [FFmpeg-devel] [PATCH v2 2/2] avutil/timestamp: change precision of av_ts_make_time_string() Marton Balint 2024-03-25 18:27 ` [FFmpeg-devel] [PATCH v2 1/2] avutil/timestamp: introduce av_ts_make_time_string2 for better precision Marton Balint 2024-03-25 22:13 ` Allan Cady via ffmpeg-devel 2024-06-17 20:08 ` Hendrik Leppkes 2024-06-17 20:33 ` [FFmpeg-devel] [PATCH] avutil/timestamp: avoid possible FPE when 0 is passed to av_ts_make_time_string2() Marton Balint 2024-06-18 7:55 ` Rémi Denis-Courmont 2024-06-18 19:07 ` Marton Balint 2024-06-29 8:24 ` Marton Balint 2024-03-17 23:43 ` [FFmpeg-devel] [PATCH] change av_ts_make_time_string precision Marton Balint 2024-03-19 22:46 ` Allan Cady via ffmpeg-devel 2024-03-13 6:09 ` Allan Cady via ffmpeg-devel 2024-03-11 3:57 ` [FFmpeg-devel] [PATCH] libavutil/timestamp.h: Fix loss of precision in timestamps for silencedetect on long files Allan Cady via ffmpeg-devel 2024-03-11 4:13 ` Allan Cady via ffmpeg-devel
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=0430c2a6-2e6a-ec15-24b3-409c55055dd5@passwd.hu \ --to=cus@passwd.hu \ --cc=ffmpeg-devel@ffmpeg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git