Opened 13 months ago
Last modified 7 weeks ago
#11576 new defect
amrwb constant bitrate wrong time estimation
| Reported by: | LanMarc77 | Owned by: | |
|---|---|---|---|
| Priority: | important | Component: | avcodec |
| Version: | 8.0 | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | Reproduced by developer: | no | |
| Analyzed by developer: | no |
Description
ffprobe (5+) estimates the wrong time for an .amr wide band file
the error seems to be relative to the runtime of the file so one does not might notice for small files
the last version that correctly estimates is 4.4.1 everything above estimated differently
using ffmpeg to encode the file into an .mp3 results in a correct runtime length file
a file with a wrongfully estimated runtime of 09:22:39.05 is encoded into an mp3 with the correct runtime of 09:04:12.20 by ffmpeg 7.1
this is also the runtime ffprobe 4.4.1 estimates
Change History (4)
comment:1 by , 13 months ago
comment:2 by , 13 months ago
| Version: | unspecified → 7.1 |
|---|
comment:4 by , 7 weeks ago
| Version: | 7.1 → 8.0 |
|---|
Note:
See TracTickets
for help on using tickets.



Using this file https://github.com/anars/blank-audio/blob/master/30-minutes-of-silence.mp3 and the static builds from here: https://johnvansickle.com/ffmpeg/ I could verify that ffmpeg 4.4.1 and 7.0.2 encode the 30minutes silence using -acodec amr_wb -ar 16000 -ac 1 -ab 23850 into the exact same file. sha256sums match.
But ffprobe from 4.4.1 shows the correct 00:30:00.30 while version 7.0.2 shows 00:31:01.33.
Judging by these numbers it seems always 3.3% too long.
This pretty much aligns with the frame overhead. One frame for the above amr-wb bitsize is 61bytes containing 2bytes frame overhead and 59bytes data. 61/59 also boils down to 3.3%.