[x265] Adaptove GoP sizes - not sure if its working
Roshantha Mendis
hrm506 at york.ac.uk
Mon Oct 5 22:40:22 CEST 2015
Hi,
I noticed another person seeing the constant GoP artifact in another
thread..
I'm using version :
x265 [info]: HEVC encoder version 1.7+431-f63273fa3137
x265 [info]: build info [Linux][GCC 4.8.4][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2
FMA3 LZCNT BMI2
thanks
Rosh
On 5 October 2015 at 21:24, 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
>
--
Rosh Mendis
Research Student - EngD in LSCITS
Dept. of Computer Science
University of York
Disclaimer: http://www.york.ac.uk/docs/disclaimer/email.htm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20151005/92afaab1/attachment-0001.html>
More information about the x265-devel
mailing list