[x264-devel] Clipping min-keyint

[Tom Vaughan]

Understood.  You tested a new condition that x264 has never allowed (scene
change detected in the middle of a fixed GOP).  It's never been designed to
handle this condition, and it's never been optimized for it.

Scenecut detection is just providing more information.  We believe that more
information is better, and that detecting scene changes is valuable, even
with fixed GOP encoding.  We believe the relevant question is - can the
encoder use this information to produce a better result, or not?

With variable GOP length, x264 would close the previous GOP and start a new
GOP with an IDR I frame.  But it can't do that with fixed GOP, or it would
change the GOP length.  So the question is, what can it do, and what should
it do?


-----Original Message-----
From: x264-devel [mailto:x264-devel-bounces at videolan.org] On Behalf Of
BugMaster
Sent: Wednesday, September 28, 2016 12:02 PM
To: Mailing list for x264 developers
Subject: Re: [x264-devel] Clipping min-keyint

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

_______________________________________________
x264-devel mailing list
x264-devel at videolan.org
https://mailman.videolan.org/listinfo/x264-devel