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 <[email protected]>wrote: > On May 15, 2013, at 8:19 AM, Joe Flowers <[email protected]> > 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 > [email protected] > http://ffmpeg.org/mailman/listinfo/libav-user >
_______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
