[x265] Adaptove GoP sizes - not sure if its working
Deepthi Nandakumar
deepthi at multicorewareinc.com
Tue Oct 6 03:27:46 CEST 2015
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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20151006/752c6051/attachment.html>
More information about the x265-devel
mailing list