<div dir="ltr"><br><div class="gmail_quote">On Tue, Jan 31, 2012 at 18:53, aviad rozenhek <span dir="ltr"><<a href="mailto:aviadr1@gmail.com">aviadr1@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="im"><div class="gmail_quote">On Sun, Jan 29, 2012 at 17:42, Steven Walters <span dir="ltr"><<a href="mailto:kemuri9@gmail.com" target="_blank">kemuri9@gmail.com</a>></span> wrote:</div></div>
<div class="gmail_quote"><div class="im"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="gmail_quote"><div>I would instead suggest going back to using a single instance, but apply the demuxer thread patch so you can tell the demuxer that is decoding your original .mpg file to multithread the decode.</div>

<div><div>
This would alleviate the decode bottleneck problem, though it would not alleviate a downscale bottleneck...</div></div><div> </div></div></div></blockquote><div><br></div></div><div>I followed your suggestion and used an x264 build with threaded demuxer from <a href="http://komisar.gin.by/" target="_blank">http://komisar.gin.by/</a></div>

<div>unfortunately, I only reached about ~30% cpu utilization on my 8 core Xeon E5520 machine, so it doesn't solve the bottleneck.</div><div>is fragmented encoding really such a bad idea?</div></div><span class="HOEnZb"><font color="#888888"><div>
<br></div>-- <br>
Aviad Rozenhek<br>
</font></span></div>
</blockquote></div><br>does x264 output an "End of Stream NAL"?<br clear="all"><div><br></div>-- <br>Aviad Rozenhek<br>
</div>