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

[Deepthi Nandakumar]

Greg,

I'm not so sure.

>From the HEVC book by Mathias Wein: " A CVS denotes the coded
representation of a sequence of pictures which can be decoded without
reference to pictures not belonging to the same coded video sequence. A
bitstream can consist of one or more coded video sequences".

This is the same as the distance between 2 consecutive IDR frames (e.g. the
case of a closed GOP). GOP has a looser definition - the distance between 2
consecutive I/IDR frames.


On Sat, Aug 22, 2015 at 10:17 PM, greg coppa <gcoppa at nyc.rr.com> wrote:

> I apologize for this comment in this forum and not to pick nits but GOP is
> not used in H.265 and suggest you use coded video sequence (CVS) instead.
>
> greg
>
> From: x265-devel <x265-devel-bounces at videolan.org> on behalf of Roshantha
> Mendis <hrm506 at york.ac.uk>
> Reply-To: Development for x265 <x265-devel at videolan.org>
> Date: Saturday, August 22, 2015 at 12:21 PM
> To: Development for x265 <x265-devel at videolan.org>
> Subject: Re: [x265] Adaptove GoP sizes - not sure if its working
>
> 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
> _______________________________________________ x265-devel mailing list
> x265-devel at videolan.org https://mailman.videolan.org/listinfo/x265-devel
>
> _______________________________________________
> 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/17a4d415/attachment-0001.html>