[gst-devel] faac does not seem to respect bitrate

Mark Nauwelaerts manauw at skynet.be
Fri Jan 29 14:46:38 CET 2010



Francis Rammeloo wrote:
> 2010/1/29 LRN <lrn1986 at gmail.com>:
>> On 29.01.2010 15:06, Francis Rammeloo wrote:
>>> It seems that faac does not always the requested respect bitrates. I
>>> have tested this on my Windows machine (using the WinBuilds) by
>>> converting a 128kbps mp3 to several mp4 files with different bitrates:
>>>
>>> gst-launch-0.10 filesrc location=kylie.mp3 ! decodebin2 ! faac
>>> bitrate=16000 ! mp4mux ! filesink location=16.mp4
>>>
>>> gst-launch-0.10 filesrc location=kylie.mp3 ! decodebin2 ! faac
>>> bitrate=32000 ! mp4mux ! filesink location=32.mp4
>>>
>>> gst-launch-0.10 filesrc location=kylie.mp3 ! decodebin2 ! faac
>>> bitrate=64000 ! mp4mux ! filesink location=64.mp4
>>>
>>> gst-launch-0.10 filesrc location=kylie.mp3 ! decodebin2 ! faac
>>> bitrate=128000 ! mp4mux ! filesink location=128.mp4
>>>
>>> gst-launch-0.10 filesrc location=kylie.mp3 ! decodebin2 ! faac
>>> bitrate=256000 ! mp4mux ! filesink location=256.mp4
>>>
>>> gst-launch-0.10 filesrc location=kylie.mp3 ! decodebin2 ! faac
>>> bitrate=320000 ! mp4mux ! filesink location=320.mp4
>>>
>>>
>>> The resulting filesizes show the issue:
>>>
>>> 29/01/2010  12:57    <DIR>          .
>>> 29/01/2010  12:57    <DIR>          ..
>>> 29/01/2010  12:55         4.402.912 32.mp4
>>> 29/01/2010  11:57         5.071.153 kylie.mp3
>>> 29/01/2010  12:58         4.403.427 64.mp4
>>> 29/01/2010  12:59         5.164.493 128.mp4
>>> 29/01/2010  12:59         8.918.765 256.mp4
>>> 29/01/2010  13:00         8.918.881 320.mp4
>>> 29/01/2010  13:01         4.402.803 16.mp4
>>>
>>>
>>> Is there a way to make it respect the requested bitrates?
>>>
>> Try encoding kylie.mp3 with 1,2,3,4,5,6,7,8,9...318,319,320 kbps (you'll
>> need a batch file or a special shell command), then look at the file
>> sizes (sorted by bitrate you've used). My prediction is that you'll see
>> that filesize(bitrate) function is monotonely rising, but will do that
>> by leaping at some points instead of raising steadily.
>>
> 
> I believe what you're saying. In my samples you can also see the
> filesizes raising. However it's not reasonable: the original file
> encoded at 128k takes 5 MB, the aac encoded one at 32k takes 4 MB. I
> should be around 1 to 2 MB.
> 

Basically see bug https://bugzilla.gnome.org/show_bug.cgi?id=606726, along with 
appropriately recent faac, etc

Mark.




More information about the gstreamer-devel mailing list