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.c...@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
_______________________________________________
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".

Reply via email to