From: Allan Cady via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Cc: Allan Cady <allancady@yahoo.com>
Subject: Re: [FFmpeg-devel] [PATCH] change av_ts_make_time_string precision
Date: Tue, 19 Mar 2024 22:46:52 +0000 (UTC)
Message-ID: <326935557.3685434.1710888412937@mail.yahoo.com> (raw)
In-Reply-To: <2399b2fa-b1d5-272a-8df6-885861a5c74a@passwd.hu>
On Sunday, March 17, 2024 at 04:43:31 PM PDT, Marton Balint <cus@passwd.hu> wrote:
> On Wed, 13 Mar 2024, Allan Cady via ffmpeg-devel wrote:>> On Tuesday, March 12, 2024 at 02:24:47 PM PDT, Marton Balint <cus@passwd.hu> wrote:>>> On Tue, 12 Mar 2024, Allan Cady via ffmpeg-devel wrote:>>>> On Monday, March 11, 2024 at 12:11:45 PM PDT, Marton Balint <cus@passwd.hu> wrote:>>>>> On Mon, 11 Mar 2024, Andreas Rheinhardt wrote:>>>>> Allan Cady via ffmpeg-devel:>>>>>> From: "Allan Cady" <allancady@yahoo.com>>>>>>>> > [...]> >>>>>>> One thing to notice is that you will not need to use the scientific>>> representation at all, because maximum value this function prints is the>>> product of an INT32 and an INT64, and that is 96 bit, which is at most 29>>> chars. Adding the optional sign and the decimal point, that is still only>>> 31. So we can be sure that by using %.6f, the first character of>>> the decimal point is going to be present in the output.>>>>>> I had done some similar calculation and came to a similar conclusion. >>>>>> Which is great,>>> because that means we only have to>>> - do a single snprintf("%.6f")>>> - calculate last char position by subtracting 1 from the minimum of>>> AV_TS_MAX_STRING_SIZE-1 and the result of the snprintf() call.>>> - decrement string length while last char is '0' to remove trailing 0s>>> - decrement string length while last char is non-digit to remove decimal>>> point (which can be a multiple chars for some locales).>>> - update last+1 char to \0.>>> Ot is it still too complex to keep it inline?>>>>>> I'll give your suggestion a spin tomorrow. Thanks.>>> > In the end I posted a patch myself, sorry if you were working on it too,> it just looked a bit too complex for a new developer, since it touched> API/build system/etc... I hope you don't mind.> > Regards,> > Marton
No problem at all. I was just getting ready to resubmit, but I'm happyto see you beat me to the punch. And I'm delighted that I won't need tokeep dragging around my own customized copy of ffmpeg going forward.
Any idea how soon this will show up on the master branch?
_______________________________________________
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-03-19 22:47 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 ` [FFmpeg-devel] [PATCH] libavutil/timestamp.h: Fix loss of precision in timestamps for silencedetect on long files 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
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 [this message]
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=326935557.3685434.1710888412937@mail.yahoo.com \
--to=ffmpeg-devel@ffmpeg.org \
--cc=allancady@yahoo.com \
/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