[Libav-user] Is libav thread-safe?

[James Board]

>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.


Well, thanks for the help, but actually this isn't true.  I tried this with the demuxing.c example and that didn't work.


>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.

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 think it's better to ask up front if libav is threadsafe before I spend a week implementing a multi-threaded app and then find out it can't possibly work because ffmpeg and libav are not thread-safe.

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.





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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20131009/b96fdee9/attachment.html>