<div dir="ltr"><div>Thank you for this test case.<br><br></div>We have identified a series of bugs on this, and are focused on closing this asap and tagging 1.8. I have sent one patch - would be good to get feedback. <br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 6, 2015 at 7:10 AM, Xinyue Lu <span dir="ltr"><<a href="mailto:maillist@7086.in" target="_blank">maillist@7086.in</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I think maybe it's better for me to leave comment in this thread.<br>
<br>
Here you are, including my builds, test video clips and the results.<br>
<br>
<a href="https://www.dropbox.com/s/6axpqr9wozeeqsu/x265%20patch%20test.tgz?dl=0" rel="noreferrer" target="_blank">https://www.dropbox.com/s/6axpqr9wozeeqsu/x265%20patch%20test.tgz?dl=0</a><br>
<br>
It should be clear to see that in rev437, I frames are inserted at 0,<br>
250, 500, while in rev436, they are inserted at 0, 37, 77, 113, 151,<br>
302, 350, 397 and 569, where most of them are real scene cut.<br>
<br>
Disclaimer: the video clips are commercials that are randomly picked,<br>
and if violate any copyright, will be removed.<br>
<br>
Thanks.<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, Oct 5, 2015 at 9:27 PM, Deepthi Nandakumar<br>
<<a href="mailto:deepthi@multicorewareinc.com">deepthi@multicorewareinc.com</a>> wrote:<br>
> Sorry - in b) below, it should be icost is greater than pcost.<br>
><br>
> On Tue, Oct 6, 2015 at 6:56 AM, Deepthi Nandakumar<br>
> <<a href="mailto:deepthi@multicorewareinc.com">deepthi@multicorewareinc.com</a>> wrote:<br>
>><br>
>> We recently modified the scenecut logic slightly. There are 2 levels of<br>
>> scenecuts detected<br>
>><br>
>> a) One is where the I-frame cost is less than P-frame cost (with bias<br>
>> factor). This inserts an I-frame and is the scenecut everyone is familiar<br>
>> with.<br>
>><br>
>> b) This next case is also logged as a scenecut - while the slicetype<br>
>> remains P (because the icost is lesser than pcost), ratecontrol realises<br>
>> that there's some scene transition going on, and so uses extra logic to<br>
>> retain quality. Without this, we found that there was blocking at the start<br>
>> of a new scene, fade-ins/fade-outs etc.<br>
>><br>
>><br>
>><br>
>> On Tue, Oct 6, 2015 at 1:54 AM, Roshantha Mendis <<a href="mailto:hrm506@york.ac.uk">hrm506@york.ac.uk</a>><br>
>> wrote:<br>
>>><br>
>>> Hi Deepthi,<br>
>>><br>
>>> I'm very sorry to open up this thread again after so long, but I tried<br>
>>> enabling the debug log as you've said. And I get scenecut notifications such<br>
>>> as :<br>
>>><br>
>>> x265 [debug]: scene cut at 102 Icost:160729 Pcost:153370 ratio:0.0458<br>
>>> bias:5394.1909 gop:102 (imb:983 pmb:479)<br>
>>> x265 [debug]: scene cut at 161 Icost:567007 Pcost:558367 ratio:0.0152<br>
>>> bias:7230.2905 gop:161 (imb:1015 pmb:447)<br>
>>> x265 [debug]: scene cut at 286 Icost:329587 Pcost:316290 ratio:0.0403<br>
>>> bias:3340.2490 gop:36 (imb:1018 pmb:444)<br>
>>> ...<br>
>>> ...<br>
>>> ...<br>
>>><br>
>>><br>
>>> Each of the frames above notified by the debug (102, 161, 286..) are<br>
>>> P-frames.<br>
>>><br>
>>> The debug is coming from slicetype::scenecutInternal, and 'res' is<br>
>>> 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<br>
>>> Pcost:%d ratio:%.4f bias:%.4f gop:%d (imb:%d pmb:%d)\n",<br>
>>>                  frame->frameNum, icost, pcost, 1. - (double)pcost /<br>
>>> icost, bias, gopSize, imb, pmb);<br>
>>>     }<br>
>>>     return res;<br>
>>><br>
>>> And in slicetype::slicetypeAnalyse, scenecut() gets called and it does<br>
>>> 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<br>
>>> frame placements */<br>
>>>         if (!m_param->scenecutThreshold && isScenecut)<br>
>>>         {<br>
>>>             frames[1]->sliceType = X265_TYPE_I;<br>
>>>             return;<br>
>>>         }<br>
>>>     }<br>
>>><br>
>>><br>
>>><br>
>>> So I am very confused, technically when the scene-cut debug appears it<br>
>>> means there should be an I-frame at that point right ?? (by calculating the<br>
>>> 'res' bool : res = pcost >= (1.0 - bias) * icost;). But this does not seem<br>
>>> the case.<br>
>>><br>
>>><br>
>>> I am using the following :<br>
>>><br>
>>> ../HEVC_x265/x265/build/linux/x265 --input vid_576p_extracted.y4m<br>
>>> --rc-lookahead 250 --scenecut 1000000 -i 9 -F 0 -I 250 -o vid.x265 --csv<br>
>>> temp.csv --csv-log-level 2 --log-level 4 --b-adapt 2 --bframes 4<br>
>>> --no-weightp --no-weightb --no-open-gop --b-intra --ref 1 --frames 10000000<br>
>>> > temp_debug.log 2>&1<br>
>>><br>
>>><br>
>>> Many thanks<br>
>>> Rosh<br>
>>><br>
>>><br>
>>> On 24 August 2015 at 05:27, Deepthi Nandakumar<br>
>>> <<a href="mailto:deepthi@multicorewareinc.com">deepthi@multicorewareinc.com</a>> wrote:<br>
>>>><br>
>>>> If you need more details, you can look through slicetype.cpp::scenecut.<br>
>>>> We recently changed the algorithm slightly.<br>
>>>><br>
>>>> a) A scenechange flag is set based purely on frame content changes and<br>
>>>> scenecut threshold.<br>
>>>> b) At the time of slicetype decision, for all "scene changed" frames the<br>
>>>> distance from last keyframe is taken into account. The further away it is,<br>
>>>> the more likely the current "scene changed" frame will be an I frame. If<br>
>>>> this condition is not satisfied, it may become a P frame (with a likely<br>
>>>> large framesize).<br>
>>>><br>
>>>> You can log how these flags change, and see how the adaptive GOP is<br>
>>>> determined for each video.<br>
>>>><br>
>>>> On Sun, Aug 23, 2015 at 9:39 PM, Steve Borho <<a href="mailto:steve@borho.org">steve@borho.org</a>> wrote:<br>
>>>>><br>
>>>>> On 08/22, Roshantha Mendis wrote:<br>
>>>>> > Thanks Steve and Deepthi, for explaining things and for that link.<br>
>>>>> ><br>
>>>>> > I understand now, that the encoder will always attempt to use<br>
>>>>> > P-frames at<br>
>>>>> > scene-cuts, whenever possible. Is this to improve on compression<br>
>>>>> > efficiency<br>
>>>>> > ?<br>
>>>>> ><br>
>>>>> > However in the docs it says :<br>
>>>>> > --scenecut <integer>, --no-scenecut<br>
>>>>> ><br>
>>>>> > How aggressively I-frames need to be inserted. *The higher the<br>
>>>>> > threshold<br>
>>>>> > value, the more aggressive the I-frame placement*. --scenecut<br>
>>>>> ><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>
>>>>> ><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>
>>>>> > disables adaptive I frame placement. Default 40<br>
>>>>> ><br>
>>>>> > So I thought , increasing this *'--scenecut <int>'* param would cause<br>
>>>>> > the<br>
>>>>> > encoder to insert I-frames instead of P-frames. is there an upper<br>
>>>>> > 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 :<br>
>>>>> > 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<br>
>>>>> > distribution<br>
>>>>> > results. But when I saw those lines in the docs/website I thought of<br>
>>>>> > trying<br>
>>>>> > out x265 instead.<br>
>>>>><br>
>>>>> 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>
>>>>><br>
>>>>> > For, the purpose of presenting results in an academic paper - do you<br>
>>>>> > think<br>
>>>>> > calculating a GoP size as distance between : [ I-SLICE <--> I/PP<br>
>>>>> > SLICE] is<br>
>>>>> > correct ?<br>
>>>>><br>
>>>>> GOP size is generally the distance between keyframes.<br>
>>>>><br>
>>>>> > Finally - with respect to closed-GOPs (IDR is being used) - Is it<br>
>>>>> > right to<br>
>>>>> > say that in this case, GoP size (I to I distance), will always be<br>
>>>>> > fixed at<br>
>>>>> > the --keyint inverval : no variation, not even slight. Is this<br>
>>>>> > because with<br>
>>>>> > closed-gops it is not possible to have adaptive GoPs ? (i.e. it<br>
>>>>> > doesn't<br>
>>>>> > specify in the standards) or just the x265 encoder doesn't support it<br>
>>>>> > ?<br>
>>>>><br>
>>>>> no, closed-GOP only means that at the keyframes the decoded picture<br>
>>>>> buffer is cleared, so pictures decoded after the keyframe cannot use<br>
>>>>> 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>
>>>>><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>
>>>><br>
>>>><br>
>>>><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>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Rosh Mendis<br>
>>> Research Student - EngD in LSCITS<br>
>>> Dept. of Computer Science<br>
>>> University of York<br>
>>><br>
>>> Disclaimer: <a href="http://www.york.ac.uk/docs/disclaimer/email.htm" rel="noreferrer" target="_blank">http://www.york.ac.uk/docs/disclaimer/email.htm</a><br>
>>><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>
>><br>
><br>
><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>
_______________________________________________<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>