[x264-devel] Fwd: x264 rate control

[eloise vidal]

Ok, You're right, it is entirely du to the number of threads, but that does
not explain me why so few bits are allocated.
I just wanted to know if this behaviour was known.
I will use less threads and/or don't take into account the first secondes
for my tests.
I will certainly look in detail the x264 rate control in the next months and
 if I find the origin of this behaviour, I will obviously let you know.

Thank you for you help.


2013/2/1 Jason Garrett-Glaser <jason at x264.com>

> On Fri, Feb 1, 2013 at 12:59 AM, eloise vidal <eloise.vidal at gmail.com>
> wrote:
> > Hey Jason,
> >
> > You can download 2 sequences and a summary of my observations at :
> > http://www.digigram.com/DOWNLOADS/EVI
> > login : ftp_download
> > pwd : SMD2qcgY
>
> "and it spends all the sequence (200 frames) to increase the number of
> bit per frame to reach the target bitrate." is an incorrect
> description of what is happening here.  CBR doesn't have a target
> bitrate.  Ratecontrol is just reacting slowly in this case -- you can
> see it takes about 24 frames for ratecontrol to start reacting...
> which is not coincidentally the number of threads!
>
> As far as I can tell, the issue is almost entirely in the first 24
> frames of the video, and the encoder is largely fine after that.
>
> Again, might I suggest using fewer threads?  That, or submit a patch
> to improve the start of encoding with 1-pass CBR ratecontrol with
> insane thread counts, or at least figure out where the problem is
> occurring (updated predictors need to be propagated to past threads,
> maybe?)?
>
> Jason
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20130201/f8e824da/attachment-0001.html>