<div dir="ltr"><div><div><div>Greg,<br><br></div>I'm not so sure.<br></div><br>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".<br><br></div>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.<br><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 22, 2015 at 10:17 PM, greg coppa <span dir="ltr"><<a href="mailto:gcoppa@nyc.rr.com" target="_blank">gcoppa@nyc.rr.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif"><div>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.</div><div><br></div><div>greg</div><div><br></div><span><div style="font-family:Calibri;font-size:11pt;text-align:left;color:black;BORDER-BOTTOM:medium none;BORDER-LEFT:medium none;PADDING-BOTTOM:0in;PADDING-LEFT:0in;PADDING-RIGHT:0in;BORDER-TOP:#b5c4df 1pt solid;BORDER-RIGHT:medium none;PADDING-TOP:3pt"><span style="font-weight:bold">From: </span> x265-devel <<a href="mailto:x265-devel-bounces@videolan.org" target="_blank">x265-devel-bounces@videolan.org</a>> on behalf of Roshantha Mendis <<a href="mailto:hrm506@york.ac.uk" target="_blank">hrm506@york.ac.uk</a>><br><span style="font-weight:bold">Reply-To: </span> Development for x265 <<a href="mailto:x265-devel@videolan.org" target="_blank">x265-devel@videolan.org</a>><br><span style="font-weight:bold">Date: </span> Saturday, August 22, 2015 at 12:21 PM<br><span style="font-weight:bold">To: </span> Development for x265 <<a href="mailto:x265-devel@videolan.org" target="_blank">x265-devel@videolan.org</a>><br><span style="font-weight:bold">Subject: </span> Re: [x265] Adaptove GoP sizes - not sure if its working<br></div><div><div class="h5"><div><br></div><div dir="ltr"><div><div>Thanks Steve and Deepthi, for explaining things and for that link. <br><br></div>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 ?<br><br></div>However in the docs it says : <br><dl><dt><code>--scenecut</code><code> <integer></code><code>, </code><code>--no-scenecut</code><code></code></dt><dd><p>How aggressively I-frames need to be inserted. <b>The higher the
threshold value, the more aggressive the I-frame placement</b>.
<a href="https://x265.readthedocs.org/en/default/cli.html#cmdoption--scenecut" target="_blank"><code><span>--scenecut</span></code></a> 0 or <a href="https://x265.readthedocs.org/en/default/cli.html#cmdoption--no-scenecut" target="_blank"><code><span>--no-scenecut</span></code></a> disables adaptive
I frame placement. Default 40</p></dd></dl><div><br><div></div><div>So I thought , increasing this <b>'--scenecut <int>'</b> param would cause the encoder to insert I-frames instead of P-frames. is there an upper limit to the scenecut param ? <br><br><div><div>and on the x265 website (<a href="https://x265.com/about-x265/" target="_blank">https://x265.com/about-x265/</a>) it says : Scenecut: Insert I-frames at scene changes<br></div></div>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. <br><br></div><div>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 ? </div><br><div>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 ?<br><br><br></div><div>I am sorry for so many questions, just trying to understand implementation specific issues with HEVC. <br><br></div><div>Thank you for all your help.<br></div><div><br><br><br><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 22 August 2015 at 15:27, 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>On 08/22, Roshantha Mendis wrote:<br>
> Okay I will try to find a video like that. If you have a good appropriate<br>
> test sequence for me to test, that will give that behaviour, please let me<br>
> know.  Thank you.<br>
><br>
> The strange thing is, the original vid clip was encoded in mp4 (downloaded<br>
> from YouTube) and when I used ffprobe to inspect it, the GOP sizes (I to I)<br>
> seemed to be different to the sizes generated by x265. Maybe it's to do<br>
> with the way frames are identified..<br><br></span>You're conflating two or three topics.<br><br>
The encoder will only insert keyframes to satisfy a keyframe interval<br>
(max) limit, and the keyframe max interval is generally specified by<br>
your target use case (web streaming, video conferencing, file<br>
transcoding, etc). For instance:<br><br><a href="https://developer.apple.com/library/ios/technotes/tn2224/_index.html#//apple_ref/doc/uid/DTS40009745-CH1-DECIDEONYOURVARIANTS" rel="noreferrer" target="_blank">https://developer.apple.com/library/ios/technotes/tn2224/_index.html#//apple_ref/doc/uid/DTS40009745-CH1-DECIDEONYOURVARIANTS</a><br><br>
Our lookahead will use P frames at scene cuts unless the current<br>
keyframe interval is approaching the user-specified max interval, and<br>
even then only if scenecut detection is enabled (--scenecut, which is<br>
enabled by default). If scenecut detection is disabled, then keyframes<br>
will always be at the max interval distance from each other.  In short,<br>
a scene cut does not always result in a keyframe.<br><br>
The keyframe interval used in the source video has no bearing on the<br>
keyframe interval given to the output encoder.<br><span><font color="#888888"><br>
--<br>
Steve Borho<br></font></span><div><div>_______________________________________________<br>
x265-devel mailing list<br><a href="mailto:x265-devel@videolan.org" target="_blank">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><br clear="all"><br>-- <br><div>Rosh Mendis<div>Research Student - EngD in LSCITS</div><div>Dept. of Computer Science</div><div>University of York<br><br><span><font color="#888888">Disclaimer: <a href="http://www.york.ac.uk/docs/disclaimer/email.htm" target="_blank">http://www.york.ac.uk/docs/disclaimer/email.htm</a></font></span><br></div></div></div>
_______________________________________________
x265-devel mailing list
<a href="mailto:x265-devel@videolan.org" target="_blank">x265-devel@videolan.org</a>
<a href="https://mailman.videolan.org/listinfo/x265-devel" target="_blank">https://mailman.videolan.org/listinfo/x265-devel</a>
</div></div></span></div>
<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>
<br></blockquote></div><br></div>