Greetings Martin et al,
I've been trying to resubmit this patch based on your earlier suggestions. Most
of the tools in the toolchain for this are new to me, so it's been awkward
going.
I did finally get the email sent with the new patch, but for some reason I
haven't been able to figure out
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
On Fri, 23 Feb 2024, Allan Cady via ffmpeg-devel wrote:
[Apologies for the awful mess in the previous email. Trying again with straight
text.]
On Thursday, February 22, 2024 at 01:16:19 AM PST, Marton Balint
wrote:
For starters, I'm curious why there are two functions & macros:
[Apologies for the awful mess in the previous email. Trying again with straight
text.]
On Thursday, February 22, 2024 at 01:16:19 AM PST, Marton Balint
wrote:
>> For starters, I'm curious why there are two functions & macros:
>>
>> av_ts2str/av_ts_make_string (which used "%" format specifier)
On Thursday, February 22, 2024 at 01:16:19 AM PST, Marton Balint
wrote:
>> 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 >
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
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
On Tue, 20 Feb 2024, Allan Cady via ffmpeg-devel wrote:
When the silencedetect audio 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 format specifier ("%.6g" in
libavutil/timestamp.h)
When the silencedetect audio 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 format specifier ("%.6g" in
libavutil/timestamp.h) limits the total field width to six significant
digits. As the
I prepared this patch a year ago but never followed through to get it accepted.
Thought I would give it another try. I've been using a local copy with these
changes, and for me it makes the difference between silencedetect being usable
or not.
Brief description: The existing implementation of
On 4/7/2019 4:47 AM, Allan Cady via ffmpeg-devel wrote:
> [Second try submitting to the list. This patch now passes fate.]
>
> 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
[Second try submitting to the list. This patch now passes fate.]
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
12 matches
Mail list logo
