[x264-devel] Initial high bitrate bug(?) in single-pass x264

[Mister K-bar]

Found the problem.Some research shows that without a specified bit buffer size ("-bufsize"), single-pass bitrate-centric encoding/rate control can (and has) produce(d) some very strange bitrate profiles. I do not know what it uses when not specified, but apparently it's not the right thing.
By specifying a bufsize in the 0.5 to 2 seconds of video works quite well (i.e. bitrate=4.5Mbps, bufsize between 2.25 megabits and 9 megabits).
If this facet is already in the FFMPEG documentation (by that I mean the black pages with the green text), can someone please point it out? If not, can someone please add it?
<thread closed>-Mark 


     On Friday, August 28, 2015 11:53 AM, Mister K-bar <misterkbar at yahoo.com> wrote:
   

 I am seeing a problem in the single-pass version of the x264 encoder where there appears to be a huge bitrate at the beginning, resulting in unacceptable amounts of compression to maintain the bitrate in the video that follows the initial high bitrate.
>From what I can tell, the issue appears to be a bug, and SEEMS to be related to some kind of 1/2 second wallclock timer within the encoder: any encoding performed in that wallclock time has an ridiculously high bitrate. And once that time period has passed, massive compression follows. It can take several seconds for the resultant artifacts to clear up.
If you slow down the encoding process (such as reducing the number of threads severely, or using a slower machine), the amount of playtime high bitrate goes down, with the simple formula:
NumberOfHighRateFrames = ~0.5  seconds  / NumberFramesProcessedPerSecond
Running a 2-pass encoding of course fixes this, but such a solution clearly won't scale: it increases the wallclock time of the encoding process severely about 40% on an unloaded machine, and cannot be used with any sort of live stream (easily).
For complete information on this topic, complete with a timeline of research into this issue (it was originally posted as "Linux quality worse than Mac"), graphs supporting the current theory, and links to MP4 files to reproduce the issue, please see this FFMPEG thread:
Buggy, unacceptably high initial bitrate with libx264 codec • FFmpeg Support Forum

|   |
|   |  |   |   |   |   |   |
| Buggy, unacceptably high initial bitrate with libx264 co...Buggy, unacceptably high initial bitrate with libx264 codec - FFmpeg support forum |
|  |
| View on ffmpeg.gusari.org | Preview by Yahoo |
|  |
|   |



As an aside, it was mentioned that a large number of threads is a BAD thing in the x264 codec. Can someone please explain why this is? Without knowing implementation details, this seems highly counter-intuitive.
Thanks!-Mark





  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20150829/37b0a149/attachment.html>