> 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
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-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
