[FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: add low_delay_b option for HEVC

[Fu, Linjie]

> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Fu,
> Linjie
> Sent: Tuesday, April 14, 2020 17:15
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: add
> low_delay_b option for HEVC
> 
> > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > Mark Thompson
> > Sent: Monday, April 13, 2020 20:20
> > To: ffmpeg-devel at ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: add
> > low_delay_b option for HEVC
> >
> > On 13/04/2020 05:32, Linjie Fu wrote:
> > > Low delay B-frame is supported on ICL+ platform.
> > >
> > > For low power encoding, low_delay_b should be enabled by default.
> > >
> > > Low delay B:
> > > <http://what-when-how.com/Tutorial/topic-397pct9eq3/High-Efficiency-
> > Video-Coding-HEVC-288.html>
> > >
> > > There is an on-going work in libva and media-driver to add querys
> > > support for low delay b, would add it once it's ready:
> > > https://github.com/intel/libva/pull/220
> > > https://github.com/intel/libva/pull/364
> > > https://github.com/intel/media-driver/issues/721
> > >
> > > Signed-off-by: Linjie Fu <linjie.fu at intel.com>
> > > ---
> > >  doc/encoders.texi              |  8 ++++++++
> > >  libavcodec/vaapi_encode_h265.c | 19 +++++++++++++++++--
> > >  2 files changed, 25 insertions(+), 2 deletions(-)
> >
> > My understanding was that the only reason for this stuff existing was to
> work
> > around broken hardware which didn't support P frames.  Is this no longer
> > true?
> >
> > >
> > > diff --git a/doc/encoders.texi b/doc/encoders.texi
> > > index e23b6b3..b0812be 100644
> > > --- a/doc/encoders.texi
> > > +++ b/doc/encoders.texi
> > > @@ -3089,6 +3089,14 @@ Some combination of the following values:
> > >  Include HDR metadata if the input frames have it
> > >  (@emph{mastering_display_colour_volume} and
> > @emph{content_light_level}
> > >  messages).
> > > +
> > > + at item low_delay_b
> > > +Use low delay B-frames instead of P frames. Reordering of pictures is
> > > +not allowed. The first picture is encoded as an I picture and subsequent
> > > +pictures are encoded as B pictures. Moreover, since past B pictures are
> > > +used for prediction, a low coding delay but with higher coding efficiency
> > > +(because of bi-prediction) is achieved.
> >
> > This sounds like a marketing blurb.
> >
> > Not for the manual, but can you explain in detail what might actually make
> > this better, with actual numbers if possible?  Intuitively the coding
> efficiency
> > will be worse, because a number of the B-picture syntax elements are just
> > redundant but still have to be coded (picking between two options which
> are
> > actually identical).  The gain of allowing biprediction between two identical
> > pictures doesn't seem like a useful feature.
> >
> The story is, this is kind of the hardware limitation for VDENC as we've
> discussed
> on IRC.

Since the dependency in LIBVA and media-driver is addressed,  updated and resent
the patch.

> As to the performance/efficiency, I'm curious too and would take some
> experiments.
Did some quick experiments on ICL with IBBPBBP reference structure (not official data,
just to show the possible benefits):

Bdrate : -1.570% based on normal IPB structure if we convert P frames to B frames.

biprediction between two identical pictures seem to benefit the quality slightly.

Please help to comment:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/1591019384-21910-1-git-send-email-linjie.fu@intel.com/

- Linjie