[FFmpeg-devel] [PATCH] lavc/vaapi_encode: Async the encoding and output procedure of encoder
Dennis Mungai
dmngaie at gmail.com
Sun Nov 17 05:38:21 EET 2019
On Sun, 17 Nov 2019, 06:36 Dennis Mungai, <dmngaie at gmail.com> wrote:
>
>
> On Thu, 14 Nov 2019, 18:29 Fu, Linjie, <linjie.fu at intel.com> wrote:
>
>> > -----Original Message-----
>> > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Fu,
>> > Linjie
>> > Sent: Monday, November 11, 2019 17:43
>> > To: ffmpeg-devel at ffmpeg.org
>> > Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: Async the
>> > encoding and output procedure of encoder
>> >
>> > > -----Original Message-----
>> > > From: Fu, Linjie <linjie.fu at intel.com>
>> > > Sent: Friday, November 8, 2019 00:32
>> > > To: ffmpeg-devel at ffmpeg.org
>> > > Cc: Fu, Linjie <linjie.fu at intel.com>
>> > > Subject: [PATCH] lavc/vaapi_encode: Async the encoding and output
>> > > procedure of encoder
>> > >
>> > > Currently, vaapi encodes a pic if all its references are ready,
>> > > and then outputs it immediately by calling vaapi_encode_output.
>> > >
>> > > However, while working on output procedure, hardware is be able to
>> > > cope with encoding tasks in the meantime to have the better
>> performance.
>> > >
>> > > So a more efficient way is to send all the pics with available refs to
>> > > hardware to allow encoding while output.
>> > >
>> > > It's what vaapi originally did before the regression, and the
>> performance
>> > > could be improved for ~20%.
>> > >
>> > > CMD:
>> > > ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128
>> > > -hwaccel_output_format vaapi -i
>> > bbb_sunflower_1080p_30fps_normal.mp4
>> > > -c:v h264_vaapi -f h264 -y /dev/null
>> > >
>> > > Source:
>> > > https://download.blender.org/demo/movies/BBB/
>> > >
>> > > Before:
>> > > ~164 fps
>> > > After:
>> > > ~198 fps
>> > >
>> > > Fix #7706.
>> > >
>> > > Signed-off-by: Linjie Fu <linjie.fu at intel.com>
>> > > ---
>> > > libavcodec/vaapi_encode.c | 27 +++++++++++++++++++--------
>> > > 1 file changed, 19 insertions(+), 8 deletions(-)
>> > >
>> > > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
>> > > index 3be9159d37..aceb268315 100644
>> > > --- a/libavcodec/vaapi_encode.c
>> > > +++ b/libavcodec/vaapi_encode.c
>> > > @@ -1109,17 +1109,28 @@ int
>> > > ff_vaapi_encode_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
>> > > return AVERROR(EAGAIN);
>> > > }
>> > >
>> > > +pick_next:
>> > > pic = NULL;
>> > > err = vaapi_encode_pick_next(avctx, &pic);
>> > > - if (err < 0)
>> > > - return err;
>> > > - av_assert0(pic);
>> > > + if (!err) {
>> > > + av_assert0(pic);
>> > >
>> > > - pic->encode_order = ctx->encode_order++;
>> > > + pic->encode_order = ctx->encode_order++;
>> > >
>> > > - err = vaapi_encode_issue(avctx, pic);
>> > > - if (err < 0) {
>> > > - av_log(avctx, AV_LOG_ERROR, "Encode failed: %d.\n", err);
>> > > + err = vaapi_encode_issue(avctx, pic);
>> > > + if (err < 0) {
>> > > + av_log(avctx, AV_LOG_ERROR, "Encode failed: %d.\n", err);
>> > > + return err;
>> > > + }
>> > > + goto pick_next;
>> > > + } else if (err == AVERROR(EAGAIN)) {
>> > > + for (pic = ctx->pic_start; pic; pic = pic->next)
>> > > + if (pic->encode_issued && !pic->encode_complete &&
>> > > + pic->encode_order == ctx->output_order)
>> > > + break;
>> > > + if (!pic)
>> > > + return err;
>> > > + } else {
>> > > return err;
>> > > }
>> > >
>> > > @@ -1143,7 +1154,7 @@ int
>> > > ff_vaapi_encode_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
>> > > av_log(avctx, AV_LOG_DEBUG, "Output packet: pts %"PRId64"
>> > > dts %"PRId64".\n",
>> > > pkt->pts, pkt->dts);
>> > >
>> > > - ctx->output_order = pic->encode_order;
>> > > + ctx->output_order++;
>> > > vaapi_encode_clear_old(avctx);
>> > >
>> > > return 0;
>> >
>> > Ping.
>>
>> Ping for this.
>> Any advice or comment would be appreciated.
>>
>> Thanks,
>> Linjie
>>
>
> The drop is even more severe on AMD hardware with VAAPI.
>
Without this patch, perf regression on AMD VAAPI is almost 40%. On Intel
hardware (HSW+) it's closer to 30% in the worst case scenarios.
>
>
More information about the ffmpeg-devel
mailing list