[x265] Adaptove GoP sizes - not sure if its working
Xinyue Lu
maillist at 7086.in
Tue Oct 6 03:40:57 CEST 2015
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
>
More information about the x265-devel
mailing list