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

[Roshantha Mendis]

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.

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 ?

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 ?


I am sorry for so many questions, just trying to understand implementation
specific issues with HEVC.

Thank you for all your help.





On 22 August 2015 at 15:27, Steve Borho <steve at borho.org> wrote:

> On 08/22, Roshantha Mendis wrote:
> > Okay I will try to find a video like that. If you have a good appropriate
> > test sequence for me to test, that will give that behaviour, please let
> me
> > know.  Thank you.
> >
> > The strange thing is, the original vid clip was encoded in mp4
> (downloaded
> > from YouTube) and when I used ffprobe to inspect it, the GOP sizes (I to
> I)
> > seemed to be different to the sizes generated by x265. Maybe it's to do
> > with the way frames are identified..
>
> You're conflating two or three topics.
>
> The encoder will only insert keyframes to satisfy a keyframe interval
> (max) limit, and the keyframe max interval is generally specified by
> your target use case (web streaming, video conferencing, file
> transcoding, etc). For instance:
>
>
> https://developer.apple.com/library/ios/technotes/tn2224/_index.html#//apple_ref/doc/uid/DTS40009745-CH1-DECIDEONYOURVARIANTS
>
> Our lookahead will use P frames at scene cuts unless the current
> keyframe interval is approaching the user-specified max interval, and
> even then only if scenecut detection is enabled (--scenecut, which is
> enabled by default). If scenecut detection is disabled, then keyframes
> will always be at the max interval distance from each other.  In short,
> a scene cut does not always result in a keyframe.
>
> The keyframe interval used in the source video has no bearing on the
> keyframe interval given to the output encoder.
>
> --
> Steve Borho
> _______________________________________________
> x265-devel mailing list
> x265-devel at videolan.org
> https://mailman.videolan.org/listinfo/x265-devel
>



-- 
Rosh Mendis
Research Student - EngD in LSCITS
Dept. of Computer Science
University of York

Disclaimer: http://www.york.ac.uk/docs/disclaimer/email.htm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20150822/340a67f1/attachment.html>