[FFmpeg-user] Bug in FFMPEG Alsa?
george at nsup.org
Sun Feb 19 12:06:23 EET 2017
Le nonidi 29 pluviôse, an CCXXV, christina zou a écrit :
> Here is the result of your two commands:
> 1. time ffmpeg -i temp_arecord.wav temp_ffmpeg.wav
> real 0m3.154s
> user 0m1.230s
> 2. time ffmpeg -i temp_arecord.wav -c copy temp_ffmpeg2.wav
> real 0m0.986s
> user 0m0.510s
(for a 27-seconds input)
Well, the issue is obviously not what I suspected, i.e. that the 32->16
bits conversion was too slow for the CPU, since it apparently takes less
than 12% of real-time.
I suspect the difference might be related to the period time. FFmpeg
uses the lowest possible period time to allow low-latency uses, but it
makes for heavier CPU consumption.
FFmpeg does not have an option to change the period time, but if you can
patch and build it yourself, you can hardcode something in
libavdevice/alsa.c near line 254.
You can also try lowering the period size in arecord and see if it
increases CPU consumption. But since arecord's work is simpler than
ffmpeg's, it may probably not be enough to observe similar results.
Still, it would be interesting.
For your next tests, I urge you to make sure no audio conversions
happens. You can do that with -c copy.
It would also be interesting to see the definition of the mic_sv PCM in
the ALSA configuration. It might be a little hard to find it in the
spaghetti configuration files.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: Digital signature
More information about the ffmpeg-user