<div><div class="gmail_quote">On Sun, Jan 29, 2012 at 8:32 AM, 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"><br><br><div class="gmail_quote"><div class="im">On Sun, Jan 29, 2012 at 13:06, Jason Garrett-Glaser <span dir="ltr"><<a href="mailto:jason@x264.com" target="_blank">jason@x264.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Sun, Jan 29, 2012 at 2:57 AM, aviad rozenhek <<a href="mailto:aviadr1@gmail.com" target="_blank">aviadr1@gmail.com</a>> wrote:<br>
> Dear Experts,<br>
><br>
> we're using x264 CLI to transcode 1080p video to 240p, using default setting<br>
> [--vf resize:432,240]<br>
> we noticed that the transcode was slow, achieving only ~70fps on an 2-cpu,<br>
> 8-core E5520 "Gainestown" machine, while utilizing only a very small portion<br>
> of the available CPU.<br>
> my analysis led me to think that the bottleneck is the down-scaling stage.<br>
<br>
</div>Transcode means to decode a video, then encode it.<br>
<br>
Decoding 1080p video is vastly more processor-intensive than encoding<br>
432x240 video.<br>
<br>
You're probably going to be massively bottlenecked by the decoding<br>
step, which x264 doesn't have anything to do with.<br>
<br>
Jason<br></blockquote><div><br></div></div><div>very true. </div><div><span>that's exactly why we are trying to solve the issue by running multiple instances of the x264 process, each working interdependently on a separate fragments of the source video.</span> by doing a 5X multi-process encode, we are effectively decoding and down-scaling with at least 5 threads, thus bypassing the decode/downscale bottleneck.</div>

<div><br></div><div>however, as I mentioned, we ran into issues with concatenation of the files, and the issue appears not to be related to timestamps.</div><div>is there anything else [such as some magic flags in the first keyframe] that can explain the "jitter" or "lag" that we experience when playing the sewn-together output file?</div>
</div></div>
<br></blockquote><div><br></div><div>Splitting an encode into segments with vbv constraints is a bad idea.<div>each segment of the file will be compliant within itself, but there is no guarantee that the concatenation of all the streams will still be compliant.</div>
<div><br></div><div>with these settings x264 is told to assume that the vbv buffer is 90% full (see the default value for --vbv-init) on each segment.</div><div>there's no guarantee that any of the segments will end with this occupancy which will then be likely to cause under or overflows upon their concatenation with the next segment.</div>
<div><br></div><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>
This would alleviate the decode bottleneck problem, though it would not alleviate a downscale bottleneck...</div></div><div> </div></div><br></div>