<div dir="ltr">Sorry - in b) below, it should be icost is greater than pcost.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 6, 2015 at 6:56 AM, Deepthi Nandakumar <span dir="ltr"><<a href="mailto:deepthi@multicorewareinc.com" target="_blank">deepthi@multicorewareinc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>We recently modified the scenecut logic slightly. There are 2 levels of scenecuts detected<br><br></div>a) One is where the I-frame cost is less than P-frame cost (with bias factor). This inserts an I-frame and is the scenecut everyone is familiar with. <br><br></div>b) This next case is also logged as a scenecut - while the slicetype remains P (because the icost is lesser than pcost), ratecontrol realises that there's some scene transition going on, and so uses extra logic to retain quality. Without this, we found that there was blocking at the start of a new scene, fade-ins/fade-outs etc. <br><br><br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 6, 2015 at 1:54 AM, Roshantha Mendis <span dir="ltr"><<a href="mailto:hrm506@york.ac.uk" target="_blank">hrm506@york.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi Deepthi,<br><br></div>I'm very sorry to open up this thread again after so long, but I tried enabling the debug log as you've said. And I get scenecut notifications such as :<br><br>x265 [debug]: scene cut at 102 Icost:160729 Pcost:153370 ratio:0.0458 bias:5394.1909 gop:102 (imb:983 pmb:479)<br>x265 [debug]: scene cut at 161 Icost:567007 Pcost:558367 ratio:0.0152 bias:7230.2905 gop:161 (imb:1015 pmb:447)<br>x265 [debug]: scene cut at 286 Icost:329587 Pcost:316290 ratio:0.0403 bias:3340.2490 gop:36 (imb:1018 pmb:444)<br>...<br>...<br>...<br><br><br></div><div>Each of the frames above notified by the debug (102, 161, 286..) are P-frames.<br><br></div>The debug is coming from slicetype::scenecutInternal, and 'res' is returned as follows:<br><br>bool res = pcost >= (1.0 - bias) * icost;<br>    if (res && bRealScenecut)<br>    {<br>        int imb = frame->intraMbs[p1 - p0];<br>        int pmb = m_8x8Blocks - imb;<br>        x265_log(m_param, X265_LOG_DEBUG, "scene cut at %d Icost:%d Pcost:%d ratio:%.4f bias:%.4f gop:%d (imb:%d pmb:%d)\n",<br>                 frame->frameNum, icost, pcost, 1. - (double)pcost / icost, bias, gopSize, imb, pmb);<br>    }<br>    return res;<br><br></div>And in slicetype::slicetypeAnalyse, scenecut() gets called and it does this :<br><br>if (m_param->bFrameAdaptive)<br>    {<br>        bool isScenecut = scenecut(frames, 0, 1, true, origNumFrames);<br>        /* When scenecut threshold is set, use scenecut detection for I frame placements */<br>        if (!m_param->scenecutThreshold && isScenecut)<br>        {<br>            frames[1]->sliceType = X265_TYPE_I;<br>            return;<br>        }<br>    }<br><div><br><br><br></div><div>So I am very confused, technically when the scene-cut debug appears it means there should be an I-frame at that point right ?? (by calculating the 'res' bool : res = pcost >= (1.0 - bias) * icost;). But this does not seem the case.<br></div><div><br><br></div><div>I am using the following :<br><br>../HEVC_x265/x265/build/linux/x265 --input vid_576p_extracted.y4m --rc-lookahead 250 --scenecut 1000000 -i 9 -F 0 -I 250 -o vid.x265 --csv temp.csv --csv-log-level 2 --log-level 4 --b-adapt 2 --bframes 4 --no-weightp --no-weightb --no-open-gop --b-intra --ref 1 --frames 10000000 > temp_debug.log 2>&1<br></div><div><br><br></div><div>Many thanks<br></div><div>Rosh<br></div><div><div><br></div></div></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">On 24 August 2015 at 05:27, Deepthi Nandakumar <span dir="ltr"><<a href="mailto:deepthi@multicorewareinc.com" target="_blank">deepthi@multicorewareinc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><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>On 08/22, Roshantha Mendis wrote:<br>
</span><span>> 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>> disables adaptive I frame placement. Default 40<br>
><br>
</span>> So I thought , increasing this *'--scenecut <int>'* param would cause the<br>
<span>> 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><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><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><div><br>
--<br>
Steve Borho<br>
_______________________________________________<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></div>
</div></div><br>_______________________________________________<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>
<br></blockquote></div><br><br clear="all"><br></div></div><span>-- <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>
</span></div>
<br>_______________________________________________<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>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>