How to spcify encoding parameters with v4l2h264enc for DragonBoard 410c

Yeah, I got that from the error…

It doesn’t seem like any of the video interfaces are. On the DB410c how would I properly encode from the camera with ffmpeg? Is this supported?

can you open a terminal and type
$ dmesg -w -d
then plug your camera and provide the new lines printed from dmesg and the output from:

$ v4l2-ctl --list-devices

I’m sorry, I still want to implement with GStreamer instead of FFmpeg as my implementation.
There is no change in the present condition that some required parameters are not valid.
So I will rewrite them, please take care that the setting of the following parameters becomes effective.

  • h264_entropy_mode
  • h264_loop_filter_mode
  • video_gop_size
  • video_b_frames
  • h264_cpb_size

Best regards.

If I understand your problem, even if these capabilities are reported as supported, they have no effect on your stream when using gstreamer ? could you please provide the gstreamer command/pipeline you apply ?

For example, let’s focus on h264_entropy_mode.
As for the binary data resulting from encoding and encoding the following two types of pipeline, there is no difference other than the time field of the header of .mp4.

The following example is expected to be encoded by CAVLC:

gst-launch-1.0 filesrc location=test.nv12 ! \
	rawvideoparse width=1280 height=960 framerate=15/1 format=23 ! \
	v4l2h264enc extra-controls="controls,h264_entropy_mode=0,h264_profile=4,h264_level=10,video_bitrate=256000;" ! \
	h264parse ! video/x-h264,stream-format="avc",alignment="au" ! \
	mp4mux fragment-duration=10 ! filesink location=test0.mp4

Next example is expected to be encoded by CABAC, but it seems same as CAVLC.

gst-launch-1.0 filesrc location=test.nv12 ! \
	rawvideoparse width=1280 height=960 framerate=15/1 format=23 ! \
	v4l2h264enc extra-controls="controls,h264_entropy_mode=1,h264_profile=4,h264_level=10,video_bitrate=256000;" ! \
	h264parse ! video/x-h264,stream-format="avc",alignment="au" ! \
	mp4mux fragment-duration=10 ! filesink location=test1.mp4

Could you please try it?

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:

  • with h264_entropy_mode=0
    Format settings, CABAC : No
  • with h264_entropy_mode=1
    Format settings, CABAC : Yes

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:

  • video_b_frames=0,video_gop_size=13
    give the gop sequence [IPPPPPPPPPPPP]*
  • video_b_frames=1,video_gop_size=13
    give the gop sequence [IBPBPBPBPBPBP]*

*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… :confused: