Opened 8 months ago

Last modified 3 months ago

#7706 open defect

20-30% perf drop in FFmpeg (H264) transcode performance with VAAPI

Reported by: eero-t Owned by:
Priority: important Component: avcodec
Version: git-master Keywords: vaapi regression
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


Summary of the bug:

VAAPI H264 transcode performance dropped 20-30% between following commits:

There's no drop with QSV backend. Between the indicated commit range, there's a series of changes to FFmpeg VAAPI support (and couple of other changes).


  • Ubuntu 18.04
  • drm-tip kernel v4.20
  • FFmpeg and iHD driver built from git
  • HW supported by iHD driver

How to reproduce:

$ ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -hwaccel_output_format vaapi -i input.264 -c:v h264_vaapi -y output.h264

I see the drop on all platforms supported by iHD driver i.e. Broadwell and newer. With i965 driver (which supports also older platforms), the drop is visible on Braswell too, but I don't see it on Sandybridge or Haswell.

This drop may be there also for other codecs, but I've tested only H264.

GPU is running at full speed before and after the change, but it and CPU use less power, i.e. they're underutilized compared to earlier situation. If one runs many instances of FFmpeg at same time so that HW is definitely fully utilized, that still retains same perf => FFmpeg VAAPI usage seems to become more synchronous.

Change History (6)

comment:1 Changed 8 months ago by cehoyos

  • Keywords vaapi regression added
  • Version changed from unspecified to git-master

Please use git bisect to find the commit introducing the regression.

comment:2 Changed 8 months ago by eero-t

Did manual bisect (they go from newer to older commits):

=> encode perf regression came from:

commit 5fdcf85bbffe7451c227478fda62da5c0938f27d
Author:     Mark Thompson <>
AuthorDate: Thu Dec 20 20:39:56 2018 +0000
Commit:     Mark Thompson <>
CommitDate: Wed Jan 23 23:04:11 2019 +0000

    vaapi_encode: Convert to send/receive API
    This attaches the logic of picking the mode of for the next picture to
    the output, which simplifies some choices by removing the concept of
    the picture for which input is not yet available.  At the same time,
    we allow more complex reference structures and track more reference
    metadata (particularly the contents of the DPB) for use in the
    codec-specific code.
    It also adds flags to explicitly track the available features of the
    different codecs.  The new structure also allows open-GOP support, so
    that is now available for codecs which can do it.

comment:3 Changed 8 months ago by cehoyos

  • Component changed from undetermined to avcodec
  • Priority changed from normal to important
  • Status changed from new to open

comment:4 follow-up: Changed 8 months ago by eero-t

VAAPI transcode performance is now slower than with QSV, whereas it earlier was in most cases faster (at least for H264, on Intel).

Guilty commit is not codec specific, so it's likely to regress VAAPI encoding perf also with other codecs than H264.

comment:5 in reply to: ↑ 4 Changed 6 months ago by eero-t

Replying to eero-t:

Guilty commit is not codec specific, so it's likely to regress VAAPI encoding perf also with other codecs than H264.

Ticket #7797 could also be due to this regression, as there has been no improvement to VA-API performance since this regression in January (except from drm-tip kernel v4.20 -> 5.0 upgrade).

comment:6 Changed 3 months ago by hbommi

There is a 10 - 15% performance drop on HEVC(H265) transcoding using regression patch
test command:
ffmpeg -v verbose -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -hwaccel_output_format vaapi -c:v hevc -i hevc_inputstream -c:v hevc_vaapi -vframes 500 -y output.h265

Last edited 3 months ago by hbommi (previous) (diff)
Note: See TracTickets for help on using tickets.