[x265] Adaptove GoP sizes - not sure if its working
Xinyue Lu
maillist at 7086.in
Tue Oct 6 22:17:52 CEST 2015
Hello,
I think they've found the issues in their patch. Maybe you can
directly try their latest patch.
And talking about version number, I have some ruby code that
generating the same thing, which should be easier to read:
ver = `hg log -r. --template "{latesttag}"`
rev = `hg log -rdefault --template "{latesttagdistance}"`
hash = `hg log -rdefault --template "{node|short}"`
v = "#{ver}+#{rev}-#{hash}"
Basically 512 is the distance to the latest tag, calculated by the hg
command line above.
Hope this helps.
Xinyue
On Tue, Oct 6, 2015 at 2:56 PM, Roshantha Mendis <hrm506 at york.ac.uk> wrote:
> Hi,
>
> I would like to help test this bug further in my spare time.
>
> But I used to use SVN and still transitioning to mercurial/git.
> how do I checkout/clone a particular version of x265 ? say 1.7+400 ?
> Assuming 1.7+400 = 400 commits from 1.7 right ?
> But when I check the actual revision number on the latest version, it says :
>
> $ hg identify -nibtB
> f8b8ebdc5457 11036 default tip
>
> How does 11036 translate to 1.7+512 ??
>
> thanks
> Rosh
>
>
>
> On 6 October 2015 at 12:38, Deepthi Nandakumar
> <deepthi at multicorewareinc.com> wrote:
>>
>> Thank you for this test case.
>>
>> 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.
>>
>> On Tue, Oct 6, 2015 at 7:10 AM, Xinyue Lu <maillist at 7086.in> wrote:
>>>
>>> Hi,
>>>
>>> I think maybe it's better for me to leave comment in this thread.
>>>
>>> Here you are, including my builds, test video clips and the results.
>>>
>>> https://www.dropbox.com/s/6axpqr9wozeeqsu/x265%20patch%20test.tgz?dl=0
>>>
>>> It should be clear to see that in rev437, I frames are inserted at 0,
>>> 250, 500, while in rev436, they are inserted at 0, 37, 77, 113, 151,
>>> 302, 350, 397 and 569, where most of them are real scene cut.
>>>
>>> Disclaimer: the video clips are commercials that are randomly picked,
>>> and if violate any copyright, will be removed.
>>>
>>> Thanks.
>>>
>>> On Mon, Oct 5, 2015 at 9:27 PM, Deepthi Nandakumar
>>> <deepthi at multicorewareinc.com> wrote:
>>> > Sorry - in b) below, it should be icost is greater than pcost.
>>> >
>>> > On Tue, Oct 6, 2015 at 6:56 AM, Deepthi Nandakumar
>>> > <deepthi at multicorewareinc.com> wrote:
>>> >>
>>> >> We recently modified the scenecut logic slightly. There are 2 levels
>>> >> of
>>> >> scenecuts detected
>>> >>
>>> >> 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.
>>> >>
>>> >> 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.
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Oct 6, 2015 at 1:54 AM, Roshantha Mendis <hrm506 at york.ac.uk>
>>> >> wrote:
>>> >>>
>>> >>> Hi Deepthi,
>>> >>>
>>> >>> 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 :
>>> >>>
>>> >>> x265 [debug]: scene cut at 102 Icost:160729 Pcost:153370 ratio:0.0458
>>> >>> bias:5394.1909 gop:102 (imb:983 pmb:479)
>>> >>> x265 [debug]: scene cut at 161 Icost:567007 Pcost:558367 ratio:0.0152
>>> >>> bias:7230.2905 gop:161 (imb:1015 pmb:447)
>>> >>> x265 [debug]: scene cut at 286 Icost:329587 Pcost:316290 ratio:0.0403
>>> >>> bias:3340.2490 gop:36 (imb:1018 pmb:444)
>>> >>> ...
>>> >>> ...
>>> >>> ...
>>> >>>
>>> >>>
>>> >>> Each of the frames above notified by the debug (102, 161, 286..) are
>>> >>> P-frames.
>>> >>>
>>> >>> The debug is coming from slicetype::scenecutInternal, and 'res' is
>>> >>> returned as follows:
>>> >>>
>>> >>> bool res = pcost >= (1.0 - bias) * icost;
>>> >>> if (res && bRealScenecut)
>>> >>> {
>>> >>> int imb = frame->intraMbs[p1 - p0];
>>> >>> int pmb = m_8x8Blocks - imb;
>>> >>> 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",
>>> >>> frame->frameNum, icost, pcost, 1. - (double)pcost /
>>> >>> icost, bias, gopSize, imb, pmb);
>>> >>> }
>>> >>> return res;
>>> >>>
>>> >>> And in slicetype::slicetypeAnalyse, scenecut() gets called and it
>>> >>> does
>>> >>> this :
>>> >>>
>>> >>> if (m_param->bFrameAdaptive)
>>> >>> {
>>> >>> bool isScenecut = scenecut(frames, 0, 1, true,
>>> >>> origNumFrames);
>>> >>> /* When scenecut threshold is set, use scenecut detection for
>>> >>> I
>>> >>> frame placements */
>>> >>> if (!m_param->scenecutThreshold && isScenecut)
>>> >>> {
>>> >>> frames[1]->sliceType = X265_TYPE_I;
>>> >>> return;
>>> >>> }
>>> >>> }
>>> >>>
>>> >>>
>>> >>>
>>> >>> 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.
>>> >>>
>>> >>>
>>> >>> I am using the following :
>>> >>>
>>> >>> ../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
>>> >>>
>>> >>>
>>> >>> Many thanks
>>> >>> Rosh
>>> >>>
>>> >>>
>>> >>> On 24 August 2015 at 05:27, Deepthi Nandakumar
>>> >>> <deepthi at multicorewareinc.com> wrote:
>>> >>>>
>>> >>>> If you need more details, you can look through
>>> >>>> slicetype.cpp::scenecut.
>>> >>>> We recently changed the algorithm slightly.
>>> >>>>
>>> >>>> a) A scenechange flag is set based purely on frame content changes
>>> >>>> and
>>> >>>> scenecut threshold.
>>> >>>> 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).
>>> >>>>
>>> >>>> You can log how these flags change, and see how the adaptive GOP is
>>> >>>> determined for each video.
>>> >>>>
>>> >>>> On Sun, Aug 23, 2015 at 9:39 PM, Steve Borho <steve at borho.org>
>>> >>>> wrote:
>>> >>>>>
>>> >>>>> On 08/22, Roshantha Mendis wrote:
>>> >>>>> > Thanks Steve and Deepthi, for explaining things and for that
>>> >>>>> > link.
>>> >>>>> >
>>> >>>>> > 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
>>> >>>>> > ?
>>> >>>>> >
>>> >>>>> > However in the docs it says :
>>> >>>>> > --scenecut <integer>, --no-scenecut
>>> >>>>> >
>>> >>>>> > How aggressively I-frames need to be inserted. *The higher the
>>> >>>>> > threshold
>>> >>>>> > value, the more aggressive the I-frame placement*. --scenecut
>>> >>>>> >
>>> >>>>> >
>>> >>>>> > <https://x265.readthedocs.org/en/default/cli.html#cmdoption--scenecut> 0 or
>>> >>>>> > --no-scenecut
>>> >>>>> >
>>> >>>>> >
>>> >>>>> > <https://x265.readthedocs.org/en/default/cli.html#cmdoption--no-scenecut>
>>> >>>>> > disables adaptive I frame placement. Default 40
>>> >>>>> >
>>> >>>>> > So I thought , increasing this *'--scenecut <int>'* param would
>>> >>>>> > cause
>>> >>>>> > the
>>> >>>>> > encoder to insert I-frames instead of P-frames. is there an upper
>>> >>>>> > limit to
>>> >>>>> > the scenecut param ?
>>> >>>>> >
>>> >>>>> > and on the x265 website (https://x265.com/about-x265/) it says :
>>> >>>>> > Scenecut:
>>> >>>>> > Insert I-frames at scene changes
>>> >>>>> > 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.
>>> >>>>>
>>> >>>>> That is what the scenecut bias does, but increasing --scenecut does
>>> >>>>> not
>>> >>>>> necessarily make the encoder always use I frames for scene-cuts.
>>> >>>>> The
>>> >>>>> keyframe adaption function uses a bias that increases the
>>> >>>>> likelyhood of
>>> >>>>> an I (vs a P) the closer it gets to the max keyframe interval. The
>>> >>>>> --scenecut bias adds to that bias, making early keyframes more
>>> >>>>> likely.
>>> >>>>>
>>> >>>>> FWIW: x264 has almost the exact same logic
>>> >>>>>
>>> >>>>> > 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 ?
>>> >>>>>
>>> >>>>> GOP size is generally the distance between keyframes.
>>> >>>>>
>>> >>>>> > 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
>>> >>>>> > ?
>>> >>>>>
>>> >>>>> no, closed-GOP only means that at the keyframes the decoded picture
>>> >>>>> buffer is cleared, so pictures decoded after the keyframe cannot
>>> >>>>> use
>>> >>>>> any
>>> >>>>> references that were coded before the keyframe. It has nothing to
>>> >>>>> do
>>> >>>>> with keyframe cadence.
>>> >>>>>
>>> >>>>> fixed keyframe interval is achieved by --no-scenecut
>>> >>>>>
>>> >>>>> --
>>> >>>>> Steve Borho
>>> >>>>> _______________________________________________
>>> >>>>> x265-devel mailing list
>>> >>>>> x265-devel at videolan.org
>>> >>>>> https://mailman.videolan.org/listinfo/x265-devel
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> x265-devel mailing list
>>> >>>> x265-devel at videolan.org
>>> >>>> https://mailman.videolan.org/listinfo/x265-devel
>>> >>>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Rosh Mendis
>>> >>> Research Student - EngD in LSCITS
>>> >>> Dept. of Computer Science
>>> >>> University of York
>>> >>>
>>> >>> Disclaimer: http://www.york.ac.uk/docs/disclaimer/email.htm
>>> >>>
>>> >>> _______________________________________________
>>> >>> x265-devel mailing list
>>> >>> x265-devel at videolan.org
>>> >>> https://mailman.videolan.org/listinfo/x265-devel
>>> >>>
>>> >>
>>> >
>>> >
>>> > _______________________________________________
>>> > x265-devel mailing list
>>> > x265-devel at videolan.org
>>> > https://mailman.videolan.org/listinfo/x265-devel
>>> >
>>> _______________________________________________
>>> x265-devel mailing list
>>> x265-devel at videolan.org
>>> https://mailman.videolan.org/listinfo/x265-devel
>>
>>
>>
>> _______________________________________________
>> x265-devel mailing list
>> x265-devel at videolan.org
>> https://mailman.videolan.org/listinfo/x265-devel
>>
>
>
>
> --
> Rosh Mendis
> Research Student - EngD in LSCITS
> Dept. of Computer Science
> University of York
>
> Disclaimer: http://www.york.ac.uk/docs/disclaimer/email.htm
>
> _______________________________________________
> x265-devel mailing list
> x265-devel at videolan.org
> https://mailman.videolan.org/listinfo/x265-devel
>
More information about the x265-devel
mailing list