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

[Marton Balint]

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

Thanks,
Marton