[Libav-user] Is libav thread-safe?

[Bruce Wheaton]

On Oct 9, 2013, at 6:28 AM, James Board <jpboard2 at yahoo.com> wrote:

Actually I have already wasted several weeks or months of coding time doing what you suggested: assume ffmpeg/libav works the way you want it, then start coding.  

I didn't say that at all. Based on my experience, it's highly unlikely ffmpeg works the way you want. It works the way it works. Rather, I suggested building an app that does playback, then see if it will do what you want it to. 
> 
> I want to have multiple threads decoding different parts of the AVI file concurrently.  No encoding will occur.  Seems like it should be thread-safe.  But I'd like to know for sure before I start coding.  That's all.  Ask questions first, code later.  That stops me from complaining when libav doesn't do what I want.  I'll just choose another route.

Not sure anything would do that. There's too many assumptions about the file. File access doesn't even really work that way. Codecs that aren't i-frame only don't work that way. Even disk heads don't work that way.

If you're deadset on it, in order to solve the problem you think you might have, then use multiple instances of a whole ffmpeg pipeline - file context, audio and video codec contexts. That's multi-threaded safe. Use the lockmanager functions to protect access to specific calls (getting codec instances etc.).

My rule of thumb these days - is to assume that the collective intelligence of the people (not me, I'm just a 'user' of ffmpeg) who made the API I'm choosing is better than my singular, less specific experience. Every time I feel compelled to re-invent the wheel because I know better (coff, coff), it turns out the existing API decsions were better.

Bruce





> 
> 
> 
> 
> On , Bruce Wheaton <bruce at spearmorgan.com> wrote:
> On Oct 8, 2013, at 12:05 PM, James Board <jpboard2 at yahoo.com> wrote:
> 
>> I want to create several pthreads in a C++ program (assuming you can call
>> libav routines from a C++ program) that each call libav subroutines.  
> 
> Well, yes, you can call C from a C++ app. You need to mark the headers as C when you include them, but that's about it.
> 
>> Are the libav subroutines  thread-safe?  Specifically,
>> can several pthreads open the same AVI file and decode different video
>> frames concurrently?
> 
> No, not really. At least, you'd have to lock the access entirely, which would make it sequential. You can use each context in one thread, and there are a few overall functions that need locking, such as choosing the right codecs for a file.
> 
>> 
>> I'm doing this so I can write a real-time video that
>> can play the video forward and backwards, and the multiple threads will
>> help decode and process each frame quickly so there will be no delay when
>> I step through the video.
> 
> Most codecs are multi-threaded by now - so there already are threads running to decode frames. You can set the number of threads you want a codec to use when you open it.
> 
> There's a number of other things you could do... multiple codecs open etc. But with codecs that need B and P frames, you pretty much have to decode in order anyway, and file access is always going to be one at a time.
> 
> It sounds like you're trying to solve a problem that you don't have yet. Start with the basics - just getting going from a cold start in ffmpeg is enough trouble for most people, without trying to get clever.
> 
> Bruce
> 
> 
> 
> 
> 
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user
> 
> 
> 
> _______________________________________________
> 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/20131010/44de46d5/attachment.html>