Thanks, I don’t see any obvious usage of entropy_mode in the venus driver, value seems retrieved by the driver but not really applied (ctr->h264_entropy_mode) (cf: drivers/media/platform/qcom/venus).
We are going to clarify the status (what is really supported and what is planned to support).
Obviously entropy mode is not applied in the driver. Could you open a bug with all controls which you think are not applied at bugs.96boards.org?
To clarify my words, I though the driver would use this entropy_mode value to configure the hardware for a certain entropy encoding usage. But yes, @medianoche, could you please open a bug for non-effective v4l2 controls.
I understand. I will post a bug report.
@medianoche , I’ve attached a first patch to the bug : https://bugs.96boards.org/attachment.cgi?id=213
This should fix the entropy issue, would you be able to test it on your side (kernel and modules rebuild)?
With this patch, mediainfo reports the following:
Thank you for providing the patch.
I could build the kernel and modules without problems.
And I also confirmed that h264_entropy_mode is enabled by installing these on DragonBoard 410c.
Thank you for your continued support and for other parameters as well.
One more patch here which should give you some control on GOP size and b_frame. Note that it does not seem possible to have consecutive b_frames, not sure if it is a normal or fixable behavior.
I’ve performed some tests with the following parameters:
*I: I-frame; P: P-frame; B: B-frame
It looks like a correct sequence.
However, I would like to specify more than 2 value for video_b_frames.
I applied the patch uploaded here, then as long as you specify 0 or 1 it will certainly get the correct result.
But, this does not seem to have changed behavior before applying the patch.
Is it difficult to specify 2 or more for video_b_frames due to specifications?
This patch enables gop-size configuration which was not applied before and ensure gop-size conservation in case of b-frame enablement. However, you should be able to enable b-frames without it.
The encoder firmware reports support of 4 consecutive b-frames max, so this should be possible, for now I’m not able to configure it properly. maybe some incompatible parameters… we are going to have a look.
In the same time could you check this other patch. It enables the deblock filter configuration, allowing to use v4l2 controls h264_loop_filter_mode, h264_loop_filter_alpha_offset and h264_loop_filter_beta_offset.
h264_loop_filter_mode values: 0 (filter mode enabled); 1 (default? filter mode disable); 2 (disabled at slice boundary)
h264_loop_filter_alpha_offset: -6 to 6 (default 0)
h264_loop_filter_beta_offset: -6 to 6 (default 0)
I don’t know easy way to determine if it works as expected, but since you request this control I assume you can check and confirm if the control is correctly applied. let me know…
Thank you for providing a new patch.
h264_loop_filter_mode, h264_loop_filter_alpha_offset, h264_loop_filter_beta_offset, all of these parameters seem to work fine.
Also, the image quality has been improved visibly.
For each parameters, I will think about the final value again.
Thank you for your continuous support.
Would you mind sharing your parameters?
I’m dealing with some artifacting issues with these parameters:
controls,h264_profile=4,video_bitrate=2000000;
Of course there is no problem.
Would you happen to have those parameters?
So I’ve implemented the three patches in this thread and everything seemed normal until I tried encoding with the baseline profile. Now, I get the following errors when I attempt to encode anything with any parameters:
[ 32.811894] qcom-venus 1d00000.video-codec: no valid instance(pkt session_id:dead, pkt:21001)
[ 32.811941] qcom-venus-encoder 1d00000.video-codec:video-encoder: enc: event session error 0
[ 32.819544] qcom-venus 1d00000.video-codec: SFR message from FW: QC_IMAGE_VERSION_STRING=VIDEO.VE.1.8-00109, Err_Fatal - Z:\b\venus\encoders\src\venus_venc_host_driver.c:5038:
[ 32.922263] qcom-venus 1d00000.video-codec: system error has occurred, starting recovery!
[ 33.958383] 1d00000.video-codec:firmware: assigned reserved memory node venus@89900000
Any one ever get this? I feel like I am crashing venus in all sorts of new and exciting ways… 
Have you made symbolic links to the video drivers if you use the Linaro Linux release 17.09 ?
See also the workaround.
Hello,
I am using debian 17.06.1 and h264 encoder with v4l2h264enc and want to control the bitrate.
If I want to have the “extra-controls=…” working, what should I do? I saw a few patches in this thread, should I apply them?
Thank you
the following build is going to become our next release in the coming hours:
http://snapshots.linaro.org/96boards/dragonboard410c/linaro/debian/359/
it will be called ‘18.01’. feel free to use this one. It has quite a bit of changes compared to 17.06 though… new kernel, new user space, …
if you can’t upgrade all these parts now, then trying to backport the relevant patches should be doable…
Hello @anon91830841, thank you for your answer.
Does that mean that the problem is solved in 18.01? It is only indicated as “conf” here: https://bugs.96boards.org/show_bug.cgi?id=646
18.01 contains many fixes for the encoder (many of them from this thread) and is the best release for using extra encoder features. Having said that I’m not sure if gstreamer supports video_b_frames >= 2 (which is the specific topic discussed in bug 646.
