comments.
New patch attached, and here is the last correspondence I had with y'all last
year.
https://ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242233.html
From 88866601cf6c6931846636fc5fee25dbbfe5ce52 Mon Sep 17 00:00:00 2001
From: Allan Cady
Date: Sat, 30 May 2020 21:06:45 -0700
Subjec
[Repeat submission. I really don't know my way around git tools... this time
I'm using "git imap-send" in hopes this will better please the ffmpeg
submission gods. Thank you for your patience.]
When the silencedetect filter is run against long files, the output
timestamps gradually lose
ewhere or if it might
have undesirable results. If there is further effort you would like me to make
before you will consider the change, please let me know and I can see what I
can do.
Thank you,
Allan Cady
Seattle WA
___
ffmpeg-devel mailing list
ffm
On 4/4/2019 5:52 PM, Carl Eugen Hoyos wrote:
2019-04-05 2:45 GMT+02:00, Allan Cady via ffmpeg-devel
Try for example:
$ make SAMPLES=fate-suite fate-xtea
$ make SAMPLES=fate-suite fate-h264
$ make fate-acodec-flac
$ make fate-vsynth1
and also
$ make SAMPLES=fate-suite fate-list
Excellent
Is it possible to run just a single FATE test against local code while doing
development, rather than running the entire test suite, to speed up the
iteration cycle? I expect it is, but I don't see how explained in the
documentation. Would appreciate a clue if this is possible.
Thanks.
Trying a desktop mail client instead of webmail.
On 3/27/2019 11:19 AM, Michael Niedermayer wrote:
this breaks make fate
also if fate is updated it should be ensured it still checks enough precission
and that it does produce the same results (fate passes) on all relevant
platforms. This
lence_end=123769.584
lavfi.silence_duration=4.173
This gives me the output I want.
Thank you,
Allan Cady
Seattle WA
0001-Fix-loss-of-precision-for-silencedetect-on-large-fil.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https:
On Tue, Mar 26, 2019 at 10:07:10PM +, Allan Cady via ffmpeg-devel wrote:
> When the silencedetect filter is run against very large files, the
> output timestamps gradually lose precision as the scan proceeds
> further into the file. This is because the output is formatted (in
&g
On Wednesday, March 27, 2019, 11:19:23 AM PDT, Michael Niedermayer
wrote: > this breaks make fate> > also if fate is
updated it should be ensured it still checks enough precission> and that it
does produce the same results (fate passes) on all relevant> platforms. This
change may bring non
Gck! Sorry guys about the formatting. Yahoo Mail sucks for anything
slightly out of the norm...
Let's try this again... if it doesn't work better, not sure what to do:
On Wednesday, March 27, 2019, 11:19:23 AM PDT, Michael Niedermayer
wrote: > this breaks make fate> > also if fate is
parameter, and left the original
macro interface as is for other usages, to limit the scope of this
change. The same or similar change could be made for other cases
where better precision is desired.
From 5492506534bf863cbf1ee8f09a5e59b4ee111226 Mon Sep 17 00:00:00 2001
From: Allan Cady
Date: Sun, 7 Apr
file filter-metadata-silencedetect has been updated
to match the new functionality.
Signed-off-by: Allan Cady
---
libavfilter/af_silencedetect.c | 12 +++
libavutil/timestamp.h| 34 +---
libavutil/version.h | 1 +
t
ny other guidance on how to format email? Thanks.)
On Wednesday, February 21, 2024 at 12:25:23 PM PST, Marton Balint
wrote:
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
[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 Monday, March 11, 2024 at 12:50:11 PM PDT, wrote:
> On 11 Mar 2024, at 15:26, Andreas Rheinhardt wrote:
>> Andreas Rheinhardt:
>>> Allan Cady via ffmpeg-devel:
>>>> From: "Allan Cady"
>>>>
>>>> I propose changing the f
On Monday, March 11, 2024 at 12:11:45 PM PDT, Marton Balint
wrote:
> On Mon, 11 Mar 2024, Andreas Rheinhardt wrote:
> Allan Cady via ffmpeg-devel:
>> From: "Allan Cady"
>>
>> I propose changing the format to "%.6f", which will
>> give mi
To test the patch I've been working on, I wrote a small standalone C program,
which I had saved in the project root. The file I'm patching is
libavutil/timestamp.h. At first I had duplicated a bunch of definitions out of
other include files (e.g. struct AVRational, in libavutil/rational.h) so I
From: "Allan Cady"
I propose changing the format to "%.6f", which will
give microsecond precision for all timestamps, regardless of
offset. Trailing zeros can be trimmed from the fraction, without
losing precision. If the length of the fixed-precision formatted
timestam
PM PST, Marton Balint
wrote:
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:
>
>>>
ts/ref/fate/filter-metadata-silencedetect to match the
new output.
Signed-off-by: Allan Cady
---
libavutil/timestamp.h| 53 +++-
tests/ref/fate/filter-metadata-scdet | 12 ++---
tests/ref/fate/filter-metadata-silencedetect | 2 +-
3 files changed, 58 ins
I've been meaning to ask -- what version of C are we using? I know it's at
least 99,
because of the compound literal (had to look that up).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To
On Tuesday, March 12, 2024 at 02:24:47 PM PDT, Marton Balint
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
>> wrote:
>>> On Mon, 11 Mar 2024, Andreas Rheinhardt wrote:
>>> Allan
On Sunday, March 17, 2024 at 04:43:31 PM PDT, Marton Balint
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 wrote:>>> On Tue,
> 12 Mar 2024, Allan Cady via ffmpeg-devel wrote:>&g
Could someone please have a look at an issue I'm having in resubmitting a
patch, trying to get the resubmission email to appear as a reply on an existing
thread? In order to conform to submission guidelines in ffmpeg-devel, I'm using
git format-patch and git send-email, using the --in-reply-to
in normal form.
>>
>> We somewhat imitate %g by trimming ending zeroes and the potential decimal
>> point characters. In order not to trim "inf" as well, we assume that the
>> decimal point string does not contain the letter "f". Note that depending o
26 matches
Mail list logo
