Fast(er) transcoding from aac to mp3.
Simon Crisp
simon at potatochip.co.uk
Fri Mar 18 20:06:23 EDT 2011
Looking back at my script I wrote back at Christmas when the iphone
option stopped working and my programs started coming down in aac I seem
to have a faster solution which works for me;
time( ffmpeg -i You_and_Yours_-_16_03_2011_b00zf33w_default.aac
-map_meta_data
You_and_Yours_-_16_03_2011_b00zf33w_default.mp3:You_and_Yours_-_16_03_2011_b00zf33w_default.aac
You_and_Yours_-_16_03_2011_b00zf33w_default.mp3)
real 2m4.772s
user 2m2.440s
sys 0m1.580s
WRT to piping; I would guess that piping output of aac -> wav to wav ->
mp3 is marginally faster than writing to a file and then reading from a
file but surely it's faster to do everything in one go?
Sy
On 18/03/2011 16:22, Ian Stirling wrote:
> On 03/18/2011 03:50 PM, bat guano wrote:
>>
>>
>>
>> ----------------------------------------
>>
>>
>>> A test I did of
>>> time (ffmpeg -i You_and_Yours_-_16_03_2011_b00zf33w_default.aac -ab
>>> 128k test.wav; lame test.wav test.mp3)
>>>
>>> finished in 4:35 - this is on a core duo at 1.8GHz.
>>> So, 12* or so real-time.
>>
>> @ Ian
>> Surely you're performing two processes there?
>> First converting aac to wav...
>> then converting wav to mp3.
>>
>> Would it not be better to use a pipe?
>>
> Indeed it would, I couldn't be bothered working out how to get ffmpeg
> to write, and lame to read from a pipe, as I already knew the syntax
> to get it to do files.
> The time will change slightly, as the decoding and encoding canbe done
> on different cores, but not much, as the decoding is so enormously
> faster.
>
> _______________________________________________
> get_iplayer mailing list
> get_iplayer at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/get_iplayer
More information about the get_iplayer
mailing list