[x265] Adaptove GoP sizes - not sure if its working

[Deepthi Nandakumar]

If you need more details, you can look through slicetype.cpp::scenecut. We
recently changed the algorithm slightly.

a) A scenechange flag is set based purely on frame content changes and
scenecut threshold.
b) At the time of slicetype decision, for all "scene changed" frames the
distance from last keyframe is taken into account. The further away it is,
the more likely the current "scene changed" frame will be an I frame. If
this condition is not satisfied, it may become a P frame (with a likely
large framesize).

You can log how these flags change, and see how the adaptive GOP is
determined for each video.

On Sun, Aug 23, 2015 at 9:39 PM, Steve Borho <steve at borho.org> wrote:

> On 08/22, Roshantha Mendis wrote:
> > Thanks Steve and Deepthi, for explaining things and for that link.
> >
> > I understand now, that the encoder will always attempt to use P-frames at
> > scene-cuts, whenever possible. Is this to improve on compression
> efficiency
> > ?
> >
> > However in the docs it says :
> > --scenecut <integer>, --no-scenecut
> >
> > How aggressively I-frames need to be inserted. *The higher the threshold
> > value, the more aggressive the I-frame placement*. --scenecut
> > <https://x265.readthedocs.org/en/default/cli.html#cmdoption--scenecut>
> 0 or
> > --no-scenecut
> > <https://x265.readthedocs.org/en/default/cli.html#cmdoption--no-scenecut
> >
> > disables adaptive I frame placement. Default 40
> >
> > So I thought , increasing this *'--scenecut <int>'* param would cause the
> > encoder to insert I-frames instead of P-frames. is there an upper limit
> to
> > the scenecut param ?
> >
> > and on the x265 website (https://x265.com/about-x265/) it says :
> Scenecut:
> > Insert I-frames at scene changes
> > which is why I thought the encoder would insert I-frames rather than
> > P-frames. Initially I was going to use x264 to get GoP size distribution
> > results. But when I saw those lines in the docs/website I thought of
> trying
> > out x265 instead.
>
> That is what the scenecut bias does, but increasing --scenecut does not
> necessarily make the encoder always use I frames for scene-cuts.  The
> keyframe adaption function uses a bias that increases the likelyhood of
> an I (vs a P) the closer it gets to the max keyframe interval.  The
> --scenecut bias adds to that bias, making early keyframes more likely.
>
> FWIW: x264 has almost the exact same logic
>
> > For, the purpose of presenting results in an academic paper - do you
> think
> > calculating a GoP size as distance between : [ I-SLICE <--> I/PP SLICE]
> is
> > correct ?
>
> GOP size is generally the distance between keyframes.
>
> > Finally - with respect to closed-GOPs (IDR is being used) - Is it right
> to
> > say that in this case, GoP size (I to I distance), will always be fixed
> at
> > the --keyint inverval : no variation, not even slight. Is this because
> with
> > closed-gops it is not possible to have adaptive GoPs ? (i.e. it doesn't
> > specify in the standards) or just the x265 encoder doesn't support it ?
>
> no, closed-GOP only means that at the keyframes the decoded picture
> buffer is cleared, so pictures decoded after the keyframe cannot use any
> references that were coded before the keyframe. It has nothing to do
> with keyframe cadence.
>
> fixed keyframe interval is achieved by --no-scenecut
>
> --
> Steve Borho
> _______________________________________________
> x265-devel mailing list
> x265-devel at videolan.org
> https://mailman.videolan.org/listinfo/x265-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20150824/75b131d9/attachment.html>