[Libav-user] Multithreaded decoding of multi-program transport streams

[Michael Chisholm]

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 <adishavit at gmail.com> 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 <adishavit at gmail.com> 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
>> 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
>