Then that sounds like it should work. Thanks! Adi
On Tue, Dec 3, 2013 at 12:22 AM, Michael Chisholm <[email protected]>wrote: > Sounds like he wants multiple decoders running simultaneously on different > threads, and you're saying that a single decoder can use multiple threads. > Not quite the same thing. > > I use multiple encoders, in my case, simultaneously in different threads, > and it works fine. I think decoders should work fine too. One thing I do > is register a custom locking function via av_lockmgr_register() just in > case some bit of internal library code wants to serialize threads through a > critical section. > > Regarding the packet question, I found the following commentary in > avformat.h (from ffmpeg 2.0.1): > > * If AVPacket.buf is set on the returned packet, then the packet is > * allocated dynamically and the user may keep it indefinitely. > * Otherwise, if AVPacket.buf is NULL, the packet data is backed by a > * static storage somewhere inside the demuxer and the packet is only valid > * until the next av_read_frame() call or closing the file. If the caller > * requires a longer lifetime, av_dup_packet() will make an av_malloc()ed > copy > * of it. > * In both cases, the packet must be freed with av_free_packet() when it is > no > * longer needed. > > I think you can make this work. As far as I've seen, the code has been > written with concurrency in mind. > > Andy > > > On 12/2/2013 4:46 PM, Bruce Wheaton wrote: > >> On Dec 1, 2013, at 2:43 AM, Adi Shavit <[email protected]> wrote: >> >> Does anyone have any insights or some references I should follow >>> regarding this issue? >>> >> >> Adi, are you aware that ffmpeg does/can employ multi-threaded decoding >> already? If you set the correct number of threads by setting thread_count >> in your avcodeccontext before opening the codec, it will do exactly what >> you propose. >> >> In effect, the first few decode calls will return immediately, then your >> frames will start to come out, having been delayed by the number of threads >> you requested. >> >> Bruce >> >> >> >>> >>> On Tue, Nov 26, 2013 at 9:15 PM, Adi Shavit <[email protected]> wrote: >>> Hi, >>> >>> I am consuming a multi-program transport stream with several video >>> streams and decoding them simultaneously. This works well. >>> >>> I am currently doing it al on a single thread. >>> Each AVPacket received by av_read_frame() is checked for the relevant >>> stream_index and passed to a corresponding decoder. >>> Hence, I have one AVCodecContext per decoded elementary stream. Each >>> such AVCodecContext handles one elementary stream, calling >>> avcodec_decode_video2() etc. >>> >>> The current single threaded design means that the next packet isn't >>> decoded until the one before it is decoded. >>> I'd like to move to a multi-threaded design where each AVCodecContext >>> resides in a separate thread with its own AVPacket (concurrent SPSC-)queue >>> and the master thread calls av_read_frame() and inserts the coded packet >>> into the relevant queue (Actor Model / Erlang style). >>> Note that each elementary stream is always decoded by the same single >>> thread. >>> >>> Before I refactor my code to do this, I'd like to know if there is >>> anything on the avlib side preventing me from implementing this approach. >>> AVPacket is a pointer to internal and external data. Are there any such >>> data that are shared between elementary streams? >>> What should I beware of? >>> Please advise, >>> Thanks, >>> Adi >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> > > _______________________________________________ > 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
