<div dir="ltr"><div><div><div>If you need more details, you can look through slicetype.cpp::scenecut. We recently changed the algorithm slightly.<br><br></div>a) A scenechange flag is set based purely on frame content changes and scenecut threshold. <br></div>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). <br><br></div>You can log how these flags change, and see how the adaptive GOP is determined for each video.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 23, 2015 at 9:39 PM, Steve Borho <span dir="ltr"><<a href="mailto:steve@borho.org" target="_blank">steve@borho.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 08/22, Roshantha Mendis wrote:<br>
</span><span class="">> Thanks Steve and Deepthi, for explaining things and for that link.<br>
><br>
> I understand now, that the encoder will always attempt to use P-frames at<br>
> scene-cuts, whenever possible. Is this to improve on compression efficiency<br>
> ?<br>
><br>
> However in the docs it says :<br>
> --scenecut <integer>, --no-scenecut<br>
><br>
</span>> How aggressively I-frames need to be inserted. *The higher the threshold<br>
> value, the more aggressive the I-frame placement*. --scenecut<br>
> <<a href="https://x265.readthedocs.org/en/default/cli.html#cmdoption--scenecut" rel="noreferrer" target="_blank">https://x265.readthedocs.org/en/default/cli.html#cmdoption--scenecut</a>> 0 or<br>
> --no-scenecut<br>
> <<a href="https://x265.readthedocs.org/en/default/cli.html#cmdoption--no-scenecut" rel="noreferrer" target="_blank">https://x265.readthedocs.org/en/default/cli.html#cmdoption--no-scenecut</a>><br>
<span class="">> disables adaptive I frame placement. Default 40<br>
><br>
</span>> So I thought , increasing this *'--scenecut <int>'* param would cause the<br>
<span class="">> encoder to insert I-frames instead of P-frames. is there an upper limit to<br>
> the scenecut param ?<br>
><br>
> and on the x265 website (<a href="https://x265.com/about-x265/" rel="noreferrer" target="_blank">https://x265.com/about-x265/</a>) it says : Scenecut:<br>
> Insert I-frames at scene changes<br>
> which is why I thought the encoder would insert I-frames rather than<br>
> P-frames. Initially I was going to use x264 to get GoP size distribution<br>
> results. But when I saw those lines in the docs/website I thought of trying<br>
> out x265 instead.<br>
<br>
</span>That is what the scenecut bias does, but increasing --scenecut does not<br>
necessarily make the encoder always use I frames for scene-cuts.  The<br>
keyframe adaption function uses a bias that increases the likelyhood of<br>
an I (vs a P) the closer it gets to the max keyframe interval.  The<br>
--scenecut bias adds to that bias, making early keyframes more likely.<br>
<br>
FWIW: x264 has almost the exact same logic<br>
<span class=""><br>
> For, the purpose of presenting results in an academic paper - do you think<br>
> calculating a GoP size as distance between : [ I-SLICE <--> I/PP SLICE] is<br>
> correct ?<br>
<br>
</span>GOP size is generally the distance between keyframes.<br>
<span class=""><br>
> Finally - with respect to closed-GOPs (IDR is being used) - Is it right to<br>
> say that in this case, GoP size (I to I distance), will always be fixed at<br>
> the --keyint inverval : no variation, not even slight. Is this because with<br>
> closed-gops it is not possible to have adaptive GoPs ? (i.e. it doesn't<br>
> specify in the standards) or just the x265 encoder doesn't support it ?<br>
<br>
</span>no, closed-GOP only means that at the keyframes the decoded picture<br>
buffer is cleared, so pictures decoded after the keyframe cannot use any<br>
references that were coded before the keyframe. It has nothing to do<br>
with keyframe cadence.<br>
<br>
fixed keyframe interval is achieved by --no-scenecut<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Steve Borho<br>
_______________________________________________<br>
x265-devel mailing list<br>
<a href="mailto:x265-devel@videolan.org">x265-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/x265-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/x265-devel</a><br>
</div></div></blockquote></div><br></div>