[x265] Adaptove GoP sizes - not sure if its working
Deepthi Nandakumar
deepthi at multicorewareinc.com
Tue Oct 6 03:26:47 CEST 2015
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/11522afd/attachment-0001.html>
More information about the x265-devel
mailing list