> From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of Fu, > Linjie > Sent: Tuesday, April 14, 2020 17:15 > To: FFmpeg development discussions and patches <ffmpeg- > de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: add > low_delay_b option for HEVC > > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > > Mark Thompson > > Sent: Monday, April 13, 2020 20:20 > > To: ffmpeg-devel@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...@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). > > > + > > > +@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...@intel.com/ - Linjie _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
