[x264-devel] Clipping min-keyint

[Tom Vaughan]

Hi Bugmaster,
There are many companies that use x264 and x265 in applications that require
a fixed GOP length.  This can be for a variety of reasons, but typically it
is either to comply with a system standard, or just to simplify adaptive
bitrate streaming (all audio, video and metadata segments will be the same
length, always).  Some of these users were puzzled as to why we forced them
to disable scene cut detection in order to enable a fixed GOP length.  So
we've made the change for x265, and we're developing a patch for x264 to do
the same thing.

So, what can scenecut do for you if you have a fixed GOP length?  Two
things.  First, we know that inter-prediction isn't effective across scene
boundaries.  So the last frame of a scene will not benefit from
bi-prediction, and the first frame of a new scene will need to be coded with
Intra prediction.  With scene detection working properly, x264 and x265 can
make better frame/slice type decisions before and after the scene cut,
choosing more optimal frame types and reference frames.  Second, I'm told by
experts that you can code a frame with intra-coded blocks more efficiently
if you encode it as an I frame (due to coding syntax).  So it's better to
make the first frame of a new scene a non-IDR I frame instead of a large P
frame.

The way we specify a fixed GOP is simply to specify the same value for
keyint and min-keyint.  These parameters are already in the API, and so no
API change is needed.

Optimizing slice types for all content is really key to encoding efficiency.
We're doing what we can to optimize this in our lookahead, and we'll
contribute any improvements back to x264.

Tom


-----Original Message-----
From: x264-devel [mailto:x264-devel-bounces at videolan.org] On Behalf Of
BugMaster
Sent: Thursday, September 22, 2016 10:40 AM
To: Mailing list for x264 developers
Subject: Re: [x264-devel] Clipping min-keyint

On Thu, 22 Sep 2016 15:37:36 +0530, Pradeep Ramachandran wrote:
> Hi all,I see in encoder/encoder.c, the following line


h->>param.i_keyint_min = x264_clip3( h->param.i_keyint_min, 1,
h->>h->param.i_keyint_max/2+1 );



> Essentially, the keyint_min is clipped to be a max of keyint_max/2
> +1. Now, this results in the problem that if scenecut detects a
> scene transition after keyint_min, it will insert IDR frame and break
> the GOP. So, if I were interested in a fixed GOP length (no, not max
> GOP length, but fixed GOP length for other reasons), I would have to
> disable scenecut detection which would result in a loss of efficiency.


> Can someone please help me understand why this clipping was done?
> It seems like losing the benefits of scenecut detection if I want
> fixed GOP isn't the best trade-off.


> Thanks,
> Pradeep.

If you want fixed GOP length than you SHOULD disable scenecut detection
otherwise it wouldn't be fixed. --min-keyint was introduced only to prevent
closing GOP due flashes almost immediately after previous key-frame. If you
meant "min-keyint == keyint" use case for fixed GOP than imho it is
incorrect way to force fixed GOP. It wouldn't result in any quality
improvement vs disabling scenecut imho.
Because main quality hit of fixed length GOP is due placing of IDR at
non-scenecut frame which happened not long before (which we already coded
almost as IDR). Coding scenecuts itself as I-frame instead of P-frame in
fixed GOP wouldn't really give you significant quality gain imho.

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