<div dir="ltr">I understand that it is not really a problem in a reel broadcast transmission.<div style>I have just to take this behaviour into account for my tests.</div><div style><br></div><div style>Thanks!!</div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">2013/2/1 Jason Garrett-Glaser <span dir="ltr"><<a href="mailto:jason@x264.com" target="_blank">jason@x264.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Fri, Feb 1, 2013 at 2:19 AM, eloise vidal <<a href="mailto:eloise.vidal@gmail.com">eloise.vidal@gmail.com</a>> wrote:<br>
> Ok, You're right, it is entirely du to the number of threads, but that does<br>
> not explain me why so few bits are allocated.<br>
<br>
</div>If I had to guess, I would say "The predictors at the start haven't<br>
adapted to the video yet, but for some reason, the effect of that<br>
adaptation isn't getting applied until threads finish encoding their<br>
frames, thus making the adaptation window at least as large as the<br>
number of threads. This probably isn't a bug per se (i.e. it's by<br>
design), but of course should be fixed."<br>
<br>
Issues like this probably got largely ignored because the main focus<br>
of x264's CBR was broadcast CBR (where the start of the video isn't a big<br>
deal), but they still come up even there, e.g. if there's 20 seconds<br>
of black screen and then the video starts again.<br>
<div class="HOEnZb"><div class="h5"><br>
Jason<br>
_______________________________________________<br>
x264-devel mailing list<br>
<a href="mailto:x264-devel@videolan.org">x264-devel@videolan.org</a><br>
<a href="http://mailman.videolan.org/listinfo/x264-devel" target="_blank">http://mailman.videolan.org/listinfo/x264-devel</a><br>
</div></div></blockquote></div><br></div>