[x265] Adaptove GoP sizes - not sure if its working
Roshantha Mendis
hrm506 at york.ac.uk
Mon Oct 5 22:24:15 CEST 2015
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20151005/6b11b19f/attachment.html>
More information about the x265-devel
mailing list