[x264-devel] Clipping min-keyint

BugMaster BugMaster at narod.ru
Wed Sep 28 21:01:57 CEST 2016


On Wed, 28 Sep 2016 09:38:11 -0700, Tom Vaughan wrote:
> Hi Bugmaster,
> You tested min-keyint=keyint vs. no-scenecut.  You can't achieve fixed GOP
> with x264 unless you set min-keyint=keyint AND you disable scenecut.  If
> scenecut is not disabled, x264 overrides your min-keyint setting, forcing
> min-keyint=(keyint/2)+1.

> Without our patch it's not possible to enable scenecut for fixed GOP length
> encoding, and you certainly won't see any benefits from setting
> min-keyint=keyint while leaving scenecut enabled.

Of course this testing was done with this limit removed. I don't need
to wait for you for such simple patch as http://pastebin.com/809uAvbt.

> Variable GOP is always going to be more efficient and have better quality at
> scene changes than fixed GOP encoding.   The question is whether, for fixed
> GOP, it is better to detect scene changes or not.  Today, if someone
> requires fixed GOPs with x264, they are forced to disable scenecut. The
> patches we've developed for x265 improve encoding of fixed GOPs by allowing
> scene detection to function, inserting I frames as needed at scene changes,
> and optimizing slice types before and after the scene change.  These
> improvements aren't final, but our users are already seeing significant
> benefits.  We'll share the x264 patch and our results as soon as they're
> ready.

> By the way... 4 or 5 second GOPs would be more typical than 1 second GOPs.

Here are results for 4-5 seconds GOP (120 frames instead of 30):

SourceCode (768x432):
     |    SSIM   |    APSNR   |    OPSNR  |
-------------------------------------------
base | 0.9836293 | 47.0880000 | 45.2890000|
v0   | 0.9836064 | 47.0357534 | 45.2721300|
v1   | 0.9834342 | 47.0258712 | 45.2178712|
v2   | 0.9833332 | 46.9708424 | 45.1828424|
v3   | 0.9831040 | 46.9256577 | 45.0946577|
-------------------------------------------

As you can see not much have changed. Values are lower then 30-frame
GOP because base (non-fixed GOP) encode at --crf 18 resulted in lower
bitrate than before: 856.58 kb/s vs 965.74 kb/s



More information about the x264-devel mailing list