[Libav-user] Using the libav* libraries in a thread-safe manner?

Joe Flowers joe.flowers at nofreewill.com
Wed May 15 18:02:04 CEST 2013


Hi Brad,

Very interesting comments. I am worrying more about the speed hit of
putting it in a wrapper. We're in a real-time audio processing situation.
Your experience is most appreciated.




On Wed, May 15, 2013 at 11:43 AM, Brad O'Hearne
<brado at bighillsoftware.com>wrote:

> On May 15, 2013, at 8:19 AM, Joe Flowers <joe.flowers at nofreewill.com>
> wrote:
>
> > Does anyone know how to make (enable) the libav* APIs to be thread-safe?
>
> This may sound a little ridiculous, but in general with any third-party
> library, make a thread-safe wrapper around it. I would guess that your
> dilemma centers on wanting to reuse resources like codecs / contexts,
> output formats / contexts, to keep the memory footprint low. But for
> whatever its worth, in throwing my FFmpeg processing on Instruments (Xcode
> profiling tool) that footprint is likely going to be a blip on the radar
> compared to the resources used when processing each frame (not because
> these consume a lot of memory, but because this processing will be executed
> many times a second).
>
> So if the motivation for multithreading is to reuse resources, I wouldn't
> worry about that. If you truly need more than one object accessing the same
> processing resources, then put a wrapper around it that makes multiple
> threads play nice. Without knowing exactly what you are trying to do, can't
> say what is the best route, but that's my best guess.
>
> Brad
>
>
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20130515/38b8ae67/attachment.html>


More information about the Libav-user mailing list