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.
- Mark
_______________________________________________
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".
