[Libav-user] Is libav thread-safe?
jpboard2 at yahoo.com
Wed Oct 9 15:28:01 CEST 2013
>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
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.
Libav-user mailing list
Libav-user at ffmpeg.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libav-user