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

[Adi Shavit]

Then that sounds like it should work.
Thanks!
Adi


On Tue, Dec 3, 2013 at 12:22 AM, Michael Chisholm <chisholm at mitre.org>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 <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
>>
>>
>
> _______________________________________________
> 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/20131203/e2f06154/attachment.html>