GNOME Bugzilla – Bug 632861
[x264enc] really bad quality with tune=zerolatency
Last modified: 2010-10-30 11:10:28 UTC
This has really bad quality (with libx264-104, svn20100918-0.2 and -ugly git): gst-launch-0.10 v4l2src ! video/x-raw-yuv,width=320,height=240 ! x264enc tune=zerolatency byte- stream=false ! ffdec_h264 ! ffmpegcolorspace ! ximagesink sync=false <robswain> tpm: it was due to a bug in x264enc <robswain> zerolatency disables vfr which then made x264 use some different parameters from its api for rate control <robswain> iirc it used the timebase instead or something <robswain> and we set the timebase to be 1/1000000000 <robswain> and i think x264 was ignoring the timestamps and just using frames or something <robswain> i did make a patch somewhere... <robswain> http://people.collabora.co.uk/~robswain/x264_timebase_fix.patch <robswain> try with that <robswain> maybe it's not totally safe as the fps fraction isn't always something useful <tpm> robswain, that makes it work <robswain> good good <robswain> don't commit it yet <robswain> i think perhaps there should be a check for the framerate from the caps being 0/1 <robswain> as that would result in a timebase of 1/0 in this case and probably screw everything up <robswain> not to mention that 0/1 means variable which isn't allowed when that b_vfr_blah isn't set <robswain> so i'll add a check for that and error out if it occurs <tpm> sounds like a plan <robswain> other than that i think it should be ok <robswain> however, perhaps it will break encoding for libx264 [after] the bug was fixed...
Created attachment 172978 [details] picture
Get newer libx264 for this bug... The problem I'm having is different, the image gets pulled out if sliced-threads=1... I'm investigating
The other bug is worked around by this patch http://people.collabora.co.uk/~robswain/x264_timebase_fix.patch The x264 bug was fixed in X264_BUILD >= 106
Created attachment 172990 [details] [review] x264enc: Work around a rate control issue in libx264 When variable framerate is disabled in libx264 (which occurs when using the zerolatency tuning), libx264 ignores timestamps but still uses the timebase leading to messed up rate control with our nanosecond timebase. We work around this issue by setting the timebase to the reciprocal of the framerate and we validate that the framerate is suitable. This has been fixed upstream in libx264 but there are non-fixed versions in the wild so this workaround is still needed.
Review of attachment 172990 [details] [review]: ::: ext/x264/gstx264enc.c @@ +1160,3 @@ } +#if X264_BUILD >= 81 Should be X264_BUILD >= 81 && X264_BUILD < 106
Created attachment 173004 [details] [review] x264enc: Work around a rate control issue in libx264 Added x264 build version less than 106 check. Thanks Olivier.
Committed as ordered by Tim. commit 6f2db739aed240d080b6a9cfe28ac1ec6d2c753c Author: Robert Swain <robert.swain@collabora.co.uk> Date: Fri Oct 22 11:29:55 2010 +0200 x264enc: Work around a rate control issue in libx264 When variable framerate is disabled in libx264 (which occurs when using the zerolatency tuning), libx264 ignores timestamps but still uses the timebase leading to messed up rate control with our nanosecond timebase. We work around this issue by setting the timebase to the reciprocal of the framerate and we validate that the framerate is suitable. This has been fixed upstream in libx264 but there are non-fixed versions in the wild so this workaround is still needed. Fixes bug #632861