After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 632861 - [x264enc] really bad quality with tune=zerolatency
[x264enc] really bad quality with tune=zerolatency
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
git master
Other Linux
: Normal blocker
: 0.10.17
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-10-22 08:27 UTC by Tim-Philipp Müller
Modified: 2010-10-30 11:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
picture (24.10 KB, image/png)
2010-10-22 08:30 UTC, Tim-Philipp Müller
  Details
x264enc: Work around a rate control issue in libx264 (2.27 KB, patch)
2010-10-22 10:14 UTC, Robert Swain
needs-work Details | Review
x264enc: Work around a rate control issue in libx264 (2.30 KB, patch)
2010-10-22 13:57 UTC, Robert Swain
committed Details | Review

Description Tim-Philipp Müller 2010-10-22 08:27:03 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...
Comment 1 Tim-Philipp Müller 2010-10-22 08:30:21 UTC
Created attachment 172978 [details]
picture
Comment 2 Olivier Crête 2010-10-22 10:07:46 UTC
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
Comment 3 Olivier Crête 2010-10-22 10:12:27 UTC
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
Comment 4 Robert Swain 2010-10-22 10:14:43 UTC
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.
Comment 5 Olivier Crête 2010-10-22 10:21:56 UTC
Review of attachment 172990 [details] [review]:

::: ext/x264/gstx264enc.c
@@ +1160,3 @@
   }
 
+#if X264_BUILD >= 81

Should be X264_BUILD >= 81 && X264_BUILD < 106
Comment 6 Robert Swain 2010-10-22 13:57:07 UTC
Created attachment 173004 [details] [review]
x264enc: Work around a rate control issue in libx264

Added x264 build version less than 106 check. Thanks Olivier.
Comment 7 Robert Swain 2010-10-22 14:02:14 UTC
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