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 <c...@passwd.hu> wrote:
Signed-off-by: Marton Balint <c...@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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
