Noob here. I would like to suggest a simple change to libavutil\timestamp.h,
that for me makes the difference between silencedetect being very useful, or
not useful at all. If there is a better way to submit this, I'm happy to jump
through proper hoops... this seems like a good place to start
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
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
libavutil/timestamp.h) as "%.6g", which limits the total field length.
Eventually, for offsets
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
[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
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
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
timestamp exceeds the length of
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:
>
>>>
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
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
> On Sat, 23 Mar 2024, Marton Balint wrote:
>> av_ts_make_time_string() used "%.6g" format, but this format was losing
>> precision even when the timestamp to be printed was not that large. For
>> example
>> for 3 hours (10800) seconds, only 1 decimal digit was printed, which made
>> this
>>
24 matches
Mail list logo
