<div dir="ltr">Then that sounds like it should work.<div>Thanks!</div><div>Adi</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 3, 2013 at 12:22 AM, Michael Chisholm <span dir="ltr"><<a href="mailto:chisholm@mitre.org" target="_blank">chisholm@mitre.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
Regarding the packet question, I found the following commentary in avformat.h (from ffmpeg 2.0.1):<br>
<br>
* If AVPacket.buf is set on the returned packet, then the packet is<br>
* allocated dynamically and the user may keep it indefinitely.<br>
* Otherwise, if AVPacket.buf is NULL, the packet data is backed by a<br>
* static storage somewhere inside the demuxer and the packet is only valid<br>
* until the next av_read_frame() call or closing the file. If the caller<br>
* requires a longer lifetime, av_dup_packet() will make an av_malloc()ed copy<br>
* of it.<br>
* In both cases, the packet must be freed with av_free_packet() when it is no<br>
* longer needed.<br>
<br>
I think you can make this work. As far as I've seen, the code has been written with concurrency in mind.<br>
<br>
Andy<div class="HOEnZb"><div class="h5"><br>
<br>
On 12/2/2013 4:46 PM, Bruce Wheaton wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Dec 1, 2013, at 2:43 AM, Adi Shavit <<a href="mailto:adishavit@gmail.com" target="_blank">adishavit@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Does anyone have any insights or some references I should follow regarding this issue?<br>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
Bruce<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On Tue, Nov 26, 2013 at 9:15 PM, Adi Shavit <<a href="mailto:adishavit@gmail.com" target="_blank">adishavit@gmail.com</a>> wrote:<br>
Hi,<br>
<br>
I am consuming a multi-program transport stream with several video streams and decoding them simultaneously. This works well.<br>
<br>
I am currently doing it al on a single thread.<br>
Each AVPacket received by av_read_frame() is checked for the relevant stream_index and passed to a corresponding decoder.<br>
Hence, I have one AVCodecContext per decoded elementary stream. Each such AVCodecContext handles one elementary stream, calling avcodec_decode_video2() etc.<br>
<br>
The current single threaded design means that the next packet isn't decoded until the one before it is decoded.<br>
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).<br>
Note that each elementary stream is always decoded by the same single thread.<br>
<br>
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.<br>
AVPacket is a pointer to internal and external data. Are there any such data that are shared between elementary streams?<br>
What should I beware of?<br>
Please advise,<br>
Thanks,<br>
Adi<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Libav-user mailing list<br>
<a href="mailto:Libav-user@ffmpeg.org" target="_blank">Libav-user@ffmpeg.org</a><br>
<a href="http://ffmpeg.org/mailman/listinfo/libav-user" target="_blank">http://ffmpeg.org/mailman/<u></u>listinfo/libav-user</a><br>
</blockquote>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Libav-user mailing list<br>
<a href="mailto:Libav-user@ffmpeg.org" target="_blank">Libav-user@ffmpeg.org</a><br>
<a href="http://ffmpeg.org/mailman/listinfo/libav-user" target="_blank">http://ffmpeg.org/mailman/<u></u>listinfo/libav-user</a><br>
<br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
Libav-user mailing list<br>
<a href="mailto:Libav-user@ffmpeg.org" target="_blank">Libav-user@ffmpeg.org</a><br>
<a href="http://ffmpeg.org/mailman/listinfo/libav-user" target="_blank">http://ffmpeg.org/mailman/<u></u>listinfo/libav-user</a><br>
</div></div></blockquote></div><br></div>