[FFmpeg-devel] [PATCH 1/3] ffplay: implement separete audio decoder thread

Marton Balint cus at passwd.hu
Sun Nov 9 14:11:37 CET 2014

On Fri, 31 Oct 2014, Marton Balint wrote:

> On Thu, 30 Oct 2014, wm4 wrote:
>> On Thu, 30 Oct 2014 00:31:25 +0100
>> Marton Balint <cus at passwd.hu> wrote:
>>> Signed-off-by: Marton Balint <cus at passwd.hu>
>>> ---
>>>  ffplay.c | 265 
>>> ++++++++++++++++++++++++++++++++++++---------------------------
>>>  1 file changed, 153 insertions(+), 112 deletions(-)


>> Is there any actual advantage to this? Also, ffmpeg does support
>> multithreaded audio decoding; only for some codecs though.
> Not just the decoding, but the filtering as well will be done in the audio 
> decoder thread, so if that consumes a lot of CPU, ffplay should handle it 
> better and less audio buffer underruns should occur.
> Another benefit might be the future implementation of a non-blocking audio 
> callback where ffplay returns silence if no frames are available at the time 
> of the callback. (this would be useful on platforms where SDL or the 
> underlying audio driver API does not automatically reset the audio buffer to 
> avoid repeated sound on a buffer underrun)
> Obviously another reason is unification of the three decoding code paths to 
> allow further factorizations and extensions.

Hello Michael,

Please merge from my stable branch for the patch series:

631ac65 ffplay: implement separete audio decoder thread
cc47418 ffplay: fix indentation after last commit
7ba7277 ffplay: only output null packet once on EOF


More information about the ffmpeg-devel mailing list