[x265] Adaptove GoP sizes - not sure if its working
Deepthi Nandakumar
deepthi at multicorewareinc.com
Tue Oct 6 13:38:10 CEST 2015
Thank you for this test case.
We have identified a series of bugs on this, and are focused on closing
this asap and tagging 1.8. I have sent one patch - would be good to get
feedback.
On Tue, Oct 6, 2015 at 7:10 AM, Xinyue Lu <maillist at 7086.in> wrote:
> 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
> >
> _______________________________________________
> 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/7f713b96/attachment-0001.html>
More information about the x265-devel
mailing list