[x265] [PATCH] SEI: remove recovery point SEI messages inserted every keyframe

[Deepthi Nandakumar]

So, x265 defines a keyframe as an IDR frame (closed-gop), and all I-frames
in an open-gop are not keyframes.

A CRA frame is one where the frames following an I frame in display order
can only reference frames that follow CRA in encode order. However, there
could be frames that follow a CRA in encode order but precede the CRA in
display order.

In increasing order of strictness,
open GOP I frames -----> CRA frames ------> closed GOP IDR frames.

x265 does not support CRA frames as of now, and there is no reason to send
a recovery point SEI for very IDR frame. These are by definition random
access points.



On Thu, Sep 3, 2015 at 10:16 AM, Steve Borho <steve at borho.org> wrote:

> On 09/03, deepthi at multicorewareinc.com wrote:
> > # HG changeset patch
> > # User Deepthi Nandakumar <deepthi at multicorewareinc.com>
> > # Date 1441254830 -19800
> > #      Thu Sep 03 10:03:50 2015 +0530
> > # Branch stable
> > # Node ID 3ef81a6d10159335be6fce39801b290cdb06da39
> > # Parent  575bf6d52e151f7ca950224a7f8fd032dfaf5619
> > SEI: remove recovery point SEI messages inserted every keyframe
> >
> > It doesnt make sense to insert a recovery point SEI message for every
> keyframe.
> > An IDR is by definition a random access picture. Recovery point SEIs
> enable
> > CRA/BLA pictures, which x265 doesnt support as yet. Recovery Point SEIs
> are also
> > required when intra refresh is supported, to signal a point at which
> random
> > access is feasible.
>
> I was under the impression that an open-gop keyframe was the same as
> CRA?
>
> > diff -r 575bf6d52e15 -r 3ef81a6d1015 source/encoder/frameencoder.cpp
> > --- a/source/encoder/frameencoder.cpp Wed Sep 02 14:03:56 2015 +0530
> > +++ b/source/encoder/frameencoder.cpp Thu Sep 03 10:03:50 2015 +0530
> > @@ -418,25 +418,6 @@
> >
> >              m_top->m_lastBPSEI = m_rce.encodeOrder;
> >          }
> > -
> > -        // The recovery point SEI message assists a decoder in
> determining when the decoding
> > -        // process will produce acceptable pictures for display after
> the decoder initiates
> > -        // random access. The m_recoveryPocCnt is in units of
> POC(picture order count) which
> > -        // means pictures encoded after the CRA but precede it in
> display order(leading) are
> > -        // implicitly discarded after a random access seek regardless
> of the value of
> > -        // m_recoveryPocCnt. Our encoder does not use references prior
> to the most recent CRA,
> > -        // so all pictures following the CRA in POC order are
> guaranteed to be displayable,
> > -        // so m_recoveryPocCnt is always 0.
> > -        SEIRecoveryPoint sei_recovery_point;
> > -        sei_recovery_point.m_recoveryPocCnt = 0;
> > -        sei_recovery_point.m_exactMatchingFlag = true;
> > -        sei_recovery_point.m_brokenLinkFlag = false;
> > -
> > -        m_bs.resetBits();
> > -        sei_recovery_point.write(m_bs, *slice->m_sps);
> > -        m_bs.writeByteAlignment();
> > -
> > -        m_nalList.serialize(NAL_UNIT_PREFIX_SEI, m_bs);
> >      }
> >
> >      if (m_param->bEmitHRDSEI || !!m_param->interlaceMode)
> > _______________________________________________
> > x265-devel mailing list
> > x265-devel at videolan.org
> > https://mailman.videolan.org/listinfo/x265-devel
>
> --
> Steve Borho
> _______________________________________________
> 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/20150903/5db9601c/attachment-0001.html>