[FFmpeg-trac] #6156(avdevice:reopened): Issue with FFMPEG ALSA CPU usage

[FFmpeg]

#6156: Issue with FFMPEG ALSA CPU usage
------------------------------------+------------------------------------
             Reporter:  mushm0m     |                    Owner:
                 Type:  defect      |                   Status:  reopened
             Priority:  normal      |                Component:  avdevice
              Version:  git-master  |               Resolution:
             Keywords:  alsa        |               Blocked By:
             Blocking:              |  Reproduced by developer:  0
Analyzed by developer:  0           |
------------------------------------+------------------------------------

Comment (by kainz):

 So after having done some profiling runs on ffmpeg, I think it's just
 ffmpeg's processing loop causing most of the cpu use in this case, via
 smaller buffers (but large enough to make malloc/free expensive) and an
 accordingly larger amount of allocations.

 I added some debugging code to print the selected ALSA pcm hw buffer size,
 and compared profiling runs between ffmpeg with alsa-direct and ffmpeg
 with alsa-jack.  What happens is on the raspberrypi hardware, the i2s/pcm
 input has a 128KB buffer, and ffmpeg ends up allocating/deallocating this
 on every frame.  For comparison, the alsapulse plugin ends up using a 1MB
 buffer, but provides larger frames, so the allocations dont happen as
 often.

 Given all of the interactions above, I'm not really sure how best to
 mitigate this, and my usecase was aggravated by trying to combine the
 above with a concurrent v4l2 capture, which has proven challenging for
 other people with ffmpeg in the past.

 If the above behavior is considered a design bug, I suppose I could help
 find and/or test a solution to it, but I think the fix would end up going
 deep into the ffmpeg/libavcodec/transcoding code base, probably more than
 is comfortable.  Otherwise, I suppose this is really an unfortunate
 sideeffect of the hardware implementation.

 An easy mitigation could be to add a commandline argument(s?) to tell the
 alsa demuxer to limit the buffer(or periods etc) sizes to better match the
 platform vs what the drivers report as the maximum permissible values.

 Thoughts?

--
Ticket URL: <https://trac.ffmpeg.org/ticket/6156#comment:11>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker