[FFmpeg-devel] Patch request to timestamp.h for silencedetect filter

[Allan Cady]

 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 the process.

REQUESTED PATCH

The requested patch is to the function av_ts_make_time_string in ffmpeg_sources\ffmpeg\libavutil\timestamp.h:

Compare: (<) ffmpeg_sources\ffmpeg\libavutil\timestamp.h.orig (2617 bytes)
   with: (>) ffmpeg_sources\ffmpeg\libavutil\timestamp.h (2617 bytes)
68c68
<     else                      snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.6g", av_q2d(*tb) * ts);
---
>     else                      snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.3f", av_q2d(*tb) * ts);

The original function:

/**
 * Fill the provided buffer with a string containing a timestamp time
 * representation.
 *
 * @param buf a buffer with size in bytes of at least AV_TS_MAX_STRING_SIZE
 * @param ts the timestamp to represent
 * @param tb the timebase of the timestamp
 * @return the buffer in input
 */
static inline char *av_ts_make_time_string(char *buf, int64_t ts, AVRational *tb)
{
    if (ts == AV_NOPTS_VALUE) snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
    else                      snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.6g", av_q2d(*tb) * ts);
    return buf;
}

PROBLEM DESCRIPTION

The problem is with the format of the timestamp output, which is hardcoded in timestamp.h. The issue has been, for long audio files, as ffmpeg scans further into the file, the magnitude of the time offsets grows, and the output gradually loses decimal places off the right end, until eventually it's in whole seconds, which is not enough precision to be useful for me. Current code formats the output as "%.6g". Changing it to either "%.3f" or just "%f", ensures at least millisecond precision, which would serve my purposes.

EXAMPLE

For a sample scan on a file that's about 35 hours (126000 seconds) length:

$ /usr/bin/ffmpeg -i input.mp3 -filter_complex silencedetect=n=-30dB:d=3.5,ametadata=mode=print:file=silence-out.txt -f null -

NOTE: One might think, 35 hours is an unusually long audio file. That's true, but in fact it's the need to work with long files that brought me to ffmpeg for this. For smaller files, I often use Audacity, which works fine, but it's problematic to have to load entire large files into an Audacity project, so I went looking for a command line option. So anyway...

The output goes from this near the beginning:

frame:83085 pts:47856431 pts_time:2170.36
lavfi.silence_start=2166.86
frame:83139 pts:47887535 pts_time:2171.77
lavfi.silence_end=2171.77
lavfi.silence_duration=4.91061

to this somewhere in the middle:

frame:2450348 pts:1411399919 pts_time:64009.1
lavfi.silence_start=64005.6
frame:2450371 pts:1411413167 pts_time:64009.7
lavfi.silence_end=64009.7
lavfi.silence_duration=4.10082

to eventually this after it passes 100000 seconds:

frame:4738029 pts:2729104175 pts_time:123769
lavfi.silence_start=123765
frame:4738055 pts:2729119151 pts_time:123770
lavfi.silence_end=123770
lavfi.silence_duration=4.17918

As you can see, the start and end are eventually limited to whole-number precision, which is not sufficient for my needs. And it doesn't make sense logically to reduce precision for large numbers anyway; I can't think of a use where this would be desirable.

After making the above patch and building the code myself, I now get this output near the end:

frame:4738029 pts:2729104175 pts_time:123768.897
lavfi.silence_start=123765.411
frame:4738055 pts:2729119151 pts_time:123769.576
lavfi.silence_end=123769.584
lavfi.silence_duration=4.173

This gives me the output I want.

I haven't attempted to find if this routine is used elsewhere 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