>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 <[email protected]> wrote:
On Oct 8, 2013, at 12:05 PM, James Board <[email protected]> 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
[email protected]
http://ffmpeg.org/mailman/listinfo/libav-user
_______________________________________________
Libav-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/libav-user
