VAAPI profile determination seems to not take hardware limits into account
Volker Vogelhuber
v.vogelhuber at digitalendoscopy.de
Wed May 2 16:26:18 UTC 2018
I currently have a pipeline where I connect vaapipostproc with
vaapih264enc. The pipeline runs without problems on an apollo lake
module but vaapih264enc rejected the caps on a baytrail one. If I
explicitly define the profile to be high profile it works also on the
baytrail module. I debugged into the code and it seems like
encoder->profile_idc is set to encoder->max_profile_idc in
gstvaapiencoder_h264.c. And max_profile_idc is not taking into account
the hardware capabilities. Later the profile_idc is used to decide which
profile should be used in the negotiation phase which is now based on
the max_profile_idc (set to GST_H264_PROFILE_STEREO_HIGH, for whatever
reason). But because the baytrail hardware does not support it the
negotiation phase fails within ensure_profile_and_level in
gstvaapiencoder_h264.c where now the hardware is taken into account when
calling ensure_hw_profile_limits. So for me it seems like the
max_profile_idc is set based only on the vaapi encoder (implementation)
limits, while it should also take into account the current hardware
limits, shouldn't it? Or did I miss anything?
Maybe also the initial value within the negotiation phase shouldn't be
GST_H264_PROFILE_STEREO_HIGH and the error is within the initial list of
profiles. I'm not sure why get_available_caps(encode) seems to return
GST_H264_PROFILE_STEREO_HIGH, while the later call to
ensure_hw_profile_limits does not seem to support it.
I can workaround the problem for now by explicitly defining the profile
used, but it seems like a bug to me.
More information about the gstreamer-devel
mailing list