On Sun, Nov 09, 2014 at 02:11:37PM +0100, Marton Balint wrote: > > 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
merged thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
