Re: [FFmpeg-devel] [PATCH 1/3] libavcodec/vaapi_encode: Change the way to call async to increase performance

["Chen, Wenbin" <wenbin.chen-at-intel.com@ffmpeg.org>]

> On 27/10/2021 09:57, Wenbin Chen wrote:
> > Fix: #7706. After commit 5fdcf85bbffe7451c2, vaapi encoder's performance
> > decrease. The reason is that vaRenderPicture() and vaSyncSurface() are
> > called at the same time (vaRenderPicture() always followed by a
> > vaSyncSurface()). When we encode stream with B frames, we need buffer
> to
> > reorder frames, so we can send serveral frames to HW at once to increase
> > performance. Now I changed them to be called in a
> > asynchronous way, which will make better use of hardware.
> > 1080p transcoding increases about 17% fps on my environment.
> >
> > Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
> > ---
> >   libavcodec/vaapi_encode.c | 41 ++++++++++++++++++++++++++++-----------
> >   libavcodec/vaapi_encode.h |  3 +++
> >   2 files changed, 33 insertions(+), 11 deletions(-)
> 
> The API does not allow this behaviour.
> 
> For some bizarre reason (I think a badly-written example combined with the
> Intel driver being synchronous in vaEndPicture() for a long time), the sync to
> a surface is to the /input/ surface of an encode rather than the output
> surface.
> 
> That means you can't have multiple encodes outstanding on the same
> surface and expect to sync usefully, because the only argument to
> vaSyncSurface() is the surface to sync to without anything about the
> associated context.
> 
> Therefore trying to make it asynchronous like this falls down when input
> surfaces might appear multiple times, or might be used in the input of
> multiple encoders, because you can't tell whether your sync means the thing
> you actually wanted to finish has finished.
> 
> (The commit you point to above as having decreased performance fixed this
> bug, since it became much more visible with decoupled send/receive.)
> 
> So: put this change after the switch to syncing on output buffers (since that
> operation does make sense for this), and leave the existing behaviour for
> cases where you have to sync on the input surface.
> 
> - Mark

Thanks for your advice. It makes sense to me. I will update the patches

Best Regards
Wenbin
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".