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

[Mister K-bar]

multiply, not divide of course

Sent from Yahoo Mail on Android

From:"Mister K-bar" <misterkbar at yahoo.com>
Date:Fri, Aug 28, 2015 at 11:53 AM
Subject:Initial high bitrate bug(?) in single-pass x264

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/881c4880/attachment-0001.html>