CiNcH
26th September 2008, 18:21
Hey guys,
maybe you have recognized that Access Unit parsing has been added to ffdshow-tryouts (check (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&revision=2146)). So it does not rely on demuxers any longer that submit a whole Access Unit within one DirectShow sample (only MPC and Haali did that).
I have tested the whole thing within a live DVB streaming (push) environment and it works perfectly for 720p (ORF 1 HD) content on a C2D 2.13 GHz. Load on both cores is perfectly balanced.
However, with 1080i, situation is somewhat difference. Decoding does not seem to be multithreaded in this case and pretty much stresses my C2D to the max on one core. I then disabled H.264 deblocking which brings down CPU load to 60-80% on one core and results in perfect playback (without deinterlacing applied however..).
I have now read a post by Dark Shikari and I would like to quote him:
libavcodec is now actually significantly faster decoding in singlethreaded mode (and the mt branch provides multithreading, which will be merged soon)
Does anybody have more information on that? libavcodec seems to be pretty well multithreaded when it comes to decoding progressive content. For interlaced material it falls back to a single thread. Will the multithreading "patch" address this "issue"?
maybe you have recognized that Access Unit parsing has been added to ffdshow-tryouts (check (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&revision=2146)). So it does not rely on demuxers any longer that submit a whole Access Unit within one DirectShow sample (only MPC and Haali did that).
I have tested the whole thing within a live DVB streaming (push) environment and it works perfectly for 720p (ORF 1 HD) content on a C2D 2.13 GHz. Load on both cores is perfectly balanced.
However, with 1080i, situation is somewhat difference. Decoding does not seem to be multithreaded in this case and pretty much stresses my C2D to the max on one core. I then disabled H.264 deblocking which brings down CPU load to 60-80% on one core and results in perfect playback (without deinterlacing applied however..).
I have now read a post by Dark Shikari and I would like to quote him:
libavcodec is now actually significantly faster decoding in singlethreaded mode (and the mt branch provides multithreading, which will be merged soon)
Does anybody have more information on that? libavcodec seems to be pretty well multithreaded when it comes to decoding progressive content. For interlaced material it falls back to a single thread. Will the multithreading "patch" address this "issue"?