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

Fu, Linjie linjie.fu at intel.com
Tue Apr 14 12:14:37 EEST 2020


> 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.

As to the performance/efficiency, I'm curious too and would take some experiments.

This patch is kind of insufficient, updated a new version, to distinguish low_delay_b
and reference B frames, thx.

- Linjie


More information about the ffmpeg-devel mailing list