On Wed, 13 Mar 2024, Allan Cady via ffmpeg-devel wrote:
On Tuesday, March 12, 2024 at 02:24:47 PM PDT, Marton Balint <c...@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 <c...@passwd.hu>
wrote:
On Mon, 11 Mar 2024, Andreas Rheinhardt wrote:
Allan Cady via ffmpeg-devel:
From: "Allan Cady" <allanc...@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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
