<div dir="ltr"><div><div><div><div><div><div><div>Okay thanks, I understand the versioning now. <br><br></div>But how do I checkout a specific version from the bitbucket repo ? e.g. If I want to checkout 1.7+400<br><br><br><br></div>So I checked the latest version : x265 [info]: HEVC encoder version 1.7+512-f8b8ebdc5457<br></div>And I tested against the test.mp4 you have given (I had to convert it to y4m first using ffmpeg, as x265 didn't recognise the format)<br><br></div>the the I-frames were at (POC): 0, 250, 500.<br><br></div>scenecut debug :<br>x265 [debug]: scene cut at 108 Icost:319097 Pcost:305903 ratio:0.0413 bias:0.2123 gop:108 (imb:1971 pmb:523)<br>x265 [debug]: scene cut at 151 Icost:1324811 Pcost:1318306 ratio:0.0049 bias:0.2692 gop:151 (imb:2470 pmb:24)<br>x265 [debug]: scene cut at 302 Icost:1505570 Pcost:1489614 ratio:0.0106 bias:0.1383 gop:52 (imb:2349 pmb:145)<br>x265 [debug]: scene cut at 397 Icost:3199040 Pcost:3189918 ratio:0.0029 bias:0.2639 gop:147 (imb:2344 pmb:150)<br><br><br></div>So I guess this is intentional as Deepthi explained: No I-frames are inserted at scene-cuts because Pcost < Icost at these points. But Psize becomes large at the scenecuts. Most of the time Pcost << Icost, so most of the time, there won't be I-frames at scene changes. <br><br></div><div>I am interested in obtaining the behaviour seen in r436 (in the test samples you gave) , but I using P frames instread of I frames make sense from a compression point.<br></div><div><br></div>I've tried varying the --scenecut bias, but this does not seem to have any effect, regardless of how high I increase it. <br><div><br></div><div>I did notice duplicate scenecut debug messages for another video I tested. But I didn't investigate this much.<br><br></div><div>Thank you for your support<br></div><div>Rosh<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 6 October 2015 at 21:17, 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">Hello,<br>
<br>
I think they've found the issues in their patch. Maybe you can<br>
directly try their latest patch.<br>
<br>
And talking about version number, I have some ruby code that<br>
generating the same thing, which should be easier to read:<br>
<br>
ver = `hg log -r. --template "{latesttag}"`<br>
rev = `hg log -rdefault --template "{latesttagdistance}"`<br>
hash = `hg log -rdefault --template "{node|short}"`<br>
v = "#{ver}+#{rev}-#{hash}"<br>
<br>
Basically 512 is the distance to the latest tag, calculated by the hg<br>
command line above.<br>
<br>
Hope this helps.<br>
<span class="HOEnZb"><font color="#888888"><br>
Xinyue<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Tue, Oct 6, 2015 at 2:56 PM, Roshantha Mendis <<a href="mailto:hrm506@york.ac.uk">hrm506@york.ac.uk</a>> wrote:<br>
> Hi,<br>
><br>
> I would like to help test this bug further in my spare time.<br>
><br>
> But I used to use SVN and still transitioning to mercurial/git.<br>
> how do I checkout/clone a particular version of x265 ? say 1.7+400 ?<br>
> Assuming 1.7+400 = 400 commits from 1.7 right ?<br>
> But when I check the actual revision number on the latest version, it says :<br>
><br>
> $ hg identify -nibtB<br>
> f8b8ebdc5457 11036 default tip<br>
><br>
> How does 11036 translate to 1.7+512 ??<br>
><br>
> thanks<br>
> Rosh<br>
><br>
><br>
><br>
> On 6 October 2015 at 12:38, Deepthi Nandakumar<br>
> <<a href="mailto:deepthi@multicorewareinc.com">deepthi@multicorewareinc.com</a>> wrote:<br>
>><br>
>> Thank you for this test case.<br>
>><br>
>> We have identified a series of bugs on this, and are focused on closing<br>
>> this asap and tagging 1.8. I have sent one patch - would be good to get<br>
>> feedback.<br>
>><br>
>> On Tue, Oct 6, 2015 at 7:10 AM, Xinyue Lu <<a href="mailto:maillist@7086.in">maillist@7086.in</a>> wrote:<br>
>>><br>
>>> 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>
>>><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<br>
>>> >> 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<br>
>>> >> 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<br>
>>> >> realises<br>
>>> >> that there's some scene transition going on, and so uses extra logic<br>
>>> >> to<br>
>>> >> retain quality. Without this, we found that there was blocking at the<br>
>>> >> 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<br>
>>> >>> tried<br>
>>> >>> enabling the debug log as you've said. And I get scenecut<br>
>>> >>> 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<br>
>>> >>> does<br>
>>> >>> this :<br>
>>> >>><br>
>>> >>> if (m_param->bFrameAdaptive)<br>
>>> >>> {<br>
>>> >>> bool isScenecut = scenecut(frames, 0, 1, true,<br>
>>> >>> origNumFrames);<br>
>>> >>> /* When scenecut threshold is set, use scenecut detection for<br>
>>> >>> 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<br>
>>> >>> it<br>
>>> >>> means there should be an I-frame at that point right ?? (by<br>
>>> >>> calculating the<br>
>>> >>> 'res' bool : res = pcost >= (1.0 - bias) * icost;). But this does not<br>
>>> >>> 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<br>
>>> >>> --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<br>
>>> >>> 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<br>
>>> >>>> slicetype.cpp::scenecut.<br>
>>> >>>> We recently changed the algorithm slightly.<br>
>>> >>>><br>
>>> >>>> a) A scenechange flag is set based purely on frame content changes<br>
>>> >>>> and<br>
>>> >>>> scenecut threshold.<br>
>>> >>>> b) At the time of slicetype decision, for all "scene changed" frames<br>
>>> >>>> the<br>
>>> >>>> distance from last keyframe is taken into account. The further away<br>
>>> >>>> it is,<br>
>>> >>>> the more likely the current "scene changed" frame will be an I<br>
>>> >>>> frame. If<br>
>>> >>>> this condition is not satisfied, it may become a P frame (with a<br>
>>> >>>> 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>><br>
>>> >>>> wrote:<br>
>>> >>>>><br>
>>> >>>>> On 08/22, Roshantha Mendis wrote:<br>
>>> >>>>> > Thanks Steve and Deepthi, for explaining things and for that<br>
>>> >>>>> > 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>
>>> >>>>> ><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>
>>> >>>>> ><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<br>
>>> >>>>> > 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<br>
>>> >>>>> > 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<br>
>>> >>>>> > of<br>
>>> >>>>> > trying<br>
>>> >>>>> > out x265 instead.<br>
>>> >>>>><br>
>>> >>>>> That is what the scenecut bias does, but increasing --scenecut does<br>
>>> >>>>> not<br>
>>> >>>>> necessarily make the encoder always use I frames for scene-cuts.<br>
>>> >>>>> The<br>
>>> >>>>> keyframe adaption function uses a bias that increases the<br>
>>> >>>>> 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<br>
>>> >>>>> likely.<br>
>>> >>>>><br>
>>> >>>>> FWIW: x264 has almost the exact same logic<br>
>>> >>>>><br>
>>> >>>>> > For, the purpose of presenting results in an academic paper - do<br>
>>> >>>>> > 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<br>
>>> >>>>> > 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<br>
>>> >>>>> use<br>
>>> >>>>> any<br>
>>> >>>>> references that were coded before the keyframe. It has nothing to<br>
>>> >>>>> 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>
>><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>
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><br clear="all"><br>-- <br><div class="gmail_signature">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>