[FFmpeg-devel] Patch to WAV to accurately report duration

Michael Niedermayer michaelni
Wed Jan 12 17:04:26 CET 2011


On Mon, Jan 10, 2011 at 06:51:18PM -0800, Frank Barchard wrote:
> Patch to accurately report duration of a WAV.
> 
> Without the patch, ffmpeg reports a warning:
> 
> [wav @ 01a5d1b0] Estimating duration from bitrate, this may be inaccurate
> Input #0, wav, from 'bruce2.wav':
>   Duration: 00:00:00.25, bitrate: 1536 kb/s
> 
> and the duration would be slightly off.  I think because the 44 byte header
> was not accounted for?
> With the patch there is no warning and the duration is more accurate.
> 
> The inaccuracy most affects very short WAV's.  I made a test case of 0.25
> seconds:
> ffmpeg -y -i StEdwardsPNG.mov -ss 00:01:00 -t 00:00:00.25 -vn -ac 2 -acodec
> pcm_s16le bruce2.wav
> 
> Without patch
> >media_bench.exe --stream=audio d:\mediatests\bruce\bruce2.wav
> * Stream #0: pcm_s16le (PCM signed 16-bit little-endian)
>      Frames:         12
>    Duration:     256.23 ms
> 
> With patch
> >media_bench.exe --stream=audio d:\mediatests\bruce\bruce2.wav
> * Stream #0: pcm_s16le (PCM signed 16-bit little-endian)
>      Frames:         12
>    Duration:     256.00 ms

>  wav.c |    7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> bbbf5dcf0a8dfc45f5f1ee7ab8a4298e11bf8017  22_wav_duration.patch
> diff -wurp -N orig/libavformat/wav.c ffmpeg-mt/libavformat/wav.c
> --- orig/libavformat/wav.c	2011-01-10 17:33:10 -0800
> +++ ffmpeg-mt/libavformat/wav.c	2011-01-10 17:36:18 -0800
> @@ -231,8 +231,13 @@ static int wav_read_header(AVFormatConte
>          return -1;
>      if (!size) {
>          wav->data_end = INT64_MAX;
> -    } else
> +    } else {
>          wav->data_end= url_ftell(pb) + size;
> +        st->nb_frames = size /
> +            (st->codec->channels * (st->codec->bits_per_coded_sample >> 3));
> +        st->duration = st->codec->frame_size ?
> +            st->nb_frames * st->codec->frame_size : st->nb_frames;
> +    }

this is wrong, iam not even sure its guranteed to work with PCM

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110112/87a92ba2/attachment.pgp>



More information about the ffmpeg-devel mailing list