[x264-devel] Clipping min-keyint

[Pradeep Ramachandran]

On Thu, Sep 22, 2016 at 11:10 PM, BugMaster <BugMaster at narod.ru> wrote:

> 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->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.
>

Some of my tests are showing that coding scenecut as I-frame is more
efficient than P-frame. So when I want to do fixed GOP length, enabling
scenecut to insert an I-frame at the scenecut seems to be a good option.
Will share some data from my tests in a bit...


>
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> https://mailman.videolan.org/listinfo/x264-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20160923/e71f6a61/attachment.html>