#481 closed defect (worksforme)
mpeg4 codec encoding bitrate (-b) is not honored
Reported by: | George Yohng | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avcodec |
Version: | git | Keywords: | asp bitrate |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
Please check this example:
http://pvtftp.trueinstruments.com/ffmpeg_bug.zip
The example .bat file is for Windows, but it should equally work under Linux. This is tested on Sep 15 snapshot of the GIT.
Running the command as such:
- ffmpeg -i video-2011-09-07-12-02-58.mp4 -b 18000k -an a.avi
Does not honor 18M bit rate, and instead encodes the file with 3-4Mbps bit rate with q constantly equal to 31.
Also, -qmin/-qmax spec is not honored, and if qmin/qmax is specified to, for example, 2-8, q still stays at 31.0
qscale is the only thing that works fine.
Jul 31 2010 doesn't seem to have this problem and encodes everything correctly.
Attachments (1)
Change History (6)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
Priority: | important → normal |
---|
Since I cannot reproduce this issue (bitrate for minimal quantizer is <16Mb, quantizer is shown as 1-2 for -b18000k): Please add complete, uncut output of ffmpeg.
(Please do not offer FFmpeg binaries for download!)
comment:3 by , 13 years ago
I just did a refresh from git and cannot reproduce it either.
Please check the attached output of the affected Windows build of ffmpeg (and I had the same with Android with ffmpeg-HEAD-8af64e1 archive, whichever is that).
Apologies for submitting, if this is no longer valid.
comment:4 by , 13 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
Please reopen if this is reproducible with current git head, oldabi, 0.8.3 or 0.7.4.
comment:5 by , 13 years ago
Keywords: | asp added; mpeg4 removed |
---|
There is a sample video, ffmpeg Sep 15 Windows build and a batch file under the link in the original bug description, but it doesn't seem to depend on this particular video. I tested it with several 1280x720 cellphone h264 input videos, and the problem is reproducible on ARM-Linux (Android) as well as on Windows.