Problem controlling the bitrate on the New Vim4 h264 encoder

VIM4
1

Which system do you use? Android, Ubuntu, OOWOW or others?

Ubuntu 24

Which version of system do you use? Please provide the version of the system here:

Welcome to Fenix 1.7.3 Ubuntu 24.04.2 LTS Linux 5.15.137

Please describe your issue below:

@numbqq

I’m using the encoder API in libvpcodec.so and /usr/include/vp_multi_codec_1_0.h
I’m getting weird error messages that I don’t remember were there on the old VIM4.

Can you please help me port my software to the new VIM4 (with NPU)?
I can use a different h264 hardware encoder library if needed.

When I try and change the bitrate on the encoder by calling vl_video_encoder_change_bitrate()
I get no error back, but when the next frame is encoded this (see log) appears on stderr

Post a console log of your issue below:


Encoder changed to bitrate 2950000
[vdi_sys_sync_inst_param:673] [VDI] fail to deliver sync instance param inst_idx=0

[AML_MultiEncNAL:2283] VPU instance param sync with change param failed!
2

Hello @steely-glint

Can you check this ?

3

Hi @numbqq Unfortunately I get the same error message,

Encoder changed to bitrate 2000000
[vdi_sys_sync_inst_param:673] [VDI] fail to deliver sync instance param inst_idx=0

[AML_MultiEncNAL:2272] VPU instance param sync with change param failed!

And no change in the encoded bitrate (Which is what I set when I inited the encoder).

By the way, I am not using gstreamer - I’m accessing the encoder via the libvpcodec.so API - that deb doesn’t seem to update the library. Please let me know if I need to use a different API.

Thanks.

4

Hello @steely-glint

Could you share your steps to us to reproduce this issue?

5

Sure - I will need to build a small standalone app - at the moment it is part of a larger app.
I will let you know when I have it.

6

@numbqq I’ve got the exact same problem, I’ve been making use of dynamic bitrate changes via the api too, below are my findings.

I confirmed this is a real userspace/kernel ABI mismatch.

The tested VIM4 stack is kernel 5.15.137 with linux-image-amlogic-5.15 1.7.4, libamvenc 0.2-202406 and libmultienc 0.7-202406.

After opening the encoder, and again on the frame following amvenc_change_bitrate(), libamvenc_api.so sends this ioctl to /dev/amvenc_multi:

ioctl(…, 0x40685612, …) = -1 EFAULT (Bad address)

This decodes as _IOW(‘V’, 18, 104). Userspace expects command 18 with a 104-byte vpudrv_inst_param_t structure.

The running amvenc_multi driver defines ioctl commands 0 through 17 and then 20. Command 18 and the corresponding structure are absent. Unknown commands enter the driver’s default case, which returns -EFAULT. Therefore, “Bad address” is misleading here: the pointer is not the problem; the driver does not
implement the command.

The vendor library then prints:

VPU instance param sync with open param failed

After a live bitrate request it prints:

VPU instance param sync with change param failed!

amvenc_change_bitrate() still returns success because it only queues the request. The later failure is ignored and never propagated to the application. In my test, changing from 1 Mbps to 4 Mbps produced the sync failure and no reliable output-bitrate change.

There is an important second issue: the vendor source queues ENC_SET_PARA_CHANGE separately before performing this ioctl. Command 18 appears to mirror parameters for driver/proc diagnostics. Adding command 18 may remove the error but would not, by itself, prove that the firmware applies the new bitrate.

Could Khadas confirm whether libmultienc 0.7-202406 is intended to be ABI-compatible with the 5.15.137 amvenc_multi driver, and provide either the missing command-18 implementation or a matched userspace library? We also need a way for applications to receive the eventual result of an asynchronous parameter change.

Until this is fixed and verified by measuring encoded output, applications must treat live bitrate changes as unsupported and restart the encoder with the new bitrate.

7

Have you checked the latest 1.7.5 image ?

8

I’ll reflash and have a check, thanks for getting back to me.