[HEVCe] RC method forced to CBR with HRD param, overwrites previous RC method

[uartie]

1. In gstreamer-vaapi, the base encoder always sends a HRD parameter to the driver if RC method != CQP (https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/blob/bf2299279f61/gst-libs/gst/vaapi/gstvaapiencoder.c#L75).
2. In the driver, when it parses the HRD parameter, it forces the RC method to CBR

   media-driver/media_driver/linux/common/codec/ddi/media_ddi_encode_hevc.cpp

   Lines 1023 to 1030 in dad4030

   	case VAEncMiscParameterTypeHRD:
   	{
   	VAEncMiscParameterHRD *vaEncMiscParamHRD = (VAEncMiscParameterHRD *)miscParamBuf->data;
   	seqParams->VBVBufferSizeInBit = vaEncMiscParamHRD->buffer_size;
   	seqParams->InitVBVBufferFullnessInBit = vaEncMiscParamHRD->initial_buffer_fullness;
   	seqParams->RateControlMethod = RATECONTROL_CBR;
   	break;
   	}

3. In gstreamer-vaapi, RC parameter is added before the HRD parameter.
4. In the driver, the RC parameter will be parsed before the HRD parameter. Thus, the requested RC method is lost.

Based on the behavior in 1 thru 4, HEVC encoding with gst-vaapi will always use CBR in driver when user sets rate-control to any method != CQP. If ICQ/QVBR was requested, this causes ICQ quality setting to be ignored in the codechal. Also, this causes same encode output when user requests either QVBR or VBR.

QVBR/ICQ are added in gst-vaapi at https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/292

[XinfengZhang]

@Xiaogang-Li , HRD parameter should be valid with other BRC mode, such as VBR, should not just set it to CBR

[uartie]

@Xiaogang-Li any progress on fixing this?

[Xiaogangli-intel]

@uartie Sorry for late response. HRD should not limited to CBR, will correct it ASAP.

[Xiaogangli-intel]

Hi @uartie, could you provide several test cases to us, then we can validate it.

[uartie]

We added a workaround in gstreamer-vaapi to temporarily fix this (https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/307). Unfortunately, the workaround does not seem to fix issue #723 (so that must be a different bug).

In order to test a driver level fix for this bug, you will want to revert gstreamer-vaapi commit 861b4cc4b63a

gst-launch-1.0 -vf videotestsrc num-buffers=100 \
 ! video/x-raw,format=NV12,width=320,height=240 \
 ! filesink location=test.yuv

gst-launch-1.0 -vf filesrc location=test.yuv \
 ! rawvideoparse width=320 height=240 format=nv12 \
 ! vaapih265enc rate-control=qvbr ! h265parse \
 ! filesink location=qvbr.h265

gst-launch-1.0 -vf filesrc location=test.yuv \
 ! rawvideoparse width=320 height=240 format=nv12 \
 ! vaapih265enc rate-control=vbr ! h265parse \
 ! filesink location=vbr.h265

...without any fix/workaround, the above results are something like this:

md5sum *.h265
0e03b23b029dae845422fe624d2eb815  qvbr.h265
0e03b23b029dae845422fe624d2eb815  vbr.h265

Also, without a fix/workaround, you can try setting different vaapih265enc quality-factor parameter for icq and qvbr modes and observe the output is always the same.

[Xiaogangli-intel]

Thank you.
Code ready, in validation and code review

[uartie]

Do you have a link to the new code?

[Xiaogangli-intel]

Not yet, we are in the internal review. It should not take more time.

[Xiaogangli-intel]

@uartie This issue is fixed, please help to check it on your side.

[uartie]

Please point me to the commit/PR that fixes this please!

[uartie]

Confirmed this is fixed by d9ce426