<div dir="ltr"><div class="gmail_quote">On Sun, Jan 29, 2012 at 17:42, Steven Walters <span dir="ltr"><<a href="mailto:kemuri9@gmail.com">kemuri9@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><div class="gmail_quote"><div class="im">On Sun, Jan 29, 2012 at 8:32 AM, aviad rozenhek <span dir="ltr"><<a href="mailto:aviadr1@gmail.com" target="_blank">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>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><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></div></blockquote><div><br></div><div>Hi,</div><div>thanks for your input. </div><div>
<br></div><div>we re-transcoded the video without using vbv constraints, but still got the same hiccup in playback :-(</div><div>aside from VBV constraints, are you aware of any additional conceptual hurdles to doing fragmented, multi-process encodings?
</div><div><br></div><div>Currently, The single instance method simply isnt fast enough for us.</div><div>I am not aware of any demuxer thread patch floating around, I thought decoding was threaded by default.</div><div>
I am using builds from <a href="http://x264.nl/">http://x264.nl/</a>
</div><div><br></div><div>I think I heard somewhere that youtube are also doing fragmented encoding of video in order to massively speed up transcoding of a single title over multiple CPUs and indeed machines. multi-threaded encoding is great, but sometimes you need the additional horsepower of multi-processing.</div>
<div><br></div><div>I have attached a link to very small [3Mb] zip containing input sample, transcoded output sample and log file.
</div><div><a href="http://www.datafilehost.com/download-c04d7c3f.html">http://www.datafilehost.com/download-c04d7c3f.html</a></div><div><br></div><div><br></div><div>Appreciate your help,</div><div>A.</div><div><br></div>
</div>
</div>