Incorrect timestamp handling in QuadMax vpu_malone driver

cancel
Showing results for 
Search instead for 
Did you mean: 

Incorrect timestamp handling in QuadMax vpu_malone driver

284 Views
crg7475
Contributor II

The vpu_malone V4L2 mem2mem driver sets the `V4L2_BUF_FLAG_TIMESTAMP_COPY` flag in the buffers that come out of the capture stream. That is OK.

However, that driver has some sort of "timestamp manager" that modifies these timestamps. This significantly violates the V4L2 spec, which explicitly states:

The CAPTURE buffer timestamp has been taken from the corresponding OUTPUT buffer. This flag applies only to mem2mem devices.

This means that either, the timestamp manager must be removed and replaced by code that does what the spec states (copy the timestamp from the output to the corresponding capture buffer), or some form of ioctl to conditionally enable/disable it must be added. If the timestamp manager is enabled, this flag must not be set. I strongly recommend to not just remove that flag, since the timestamp copy behavior is absolutely essential in projects like FFmpeg, which use some form of ID to associate encoded and decoded frames. (Using the timestamp field for an arbitrary ID _is_ valid.)

Or is true timestamp copy already available? I saw that changes were made to the driver in kernel releases newer than the one used in Yocto Dunfell.

Tags (3)
0 Kudos
2 Replies

199 Views
joanxie
NXP TechSupport
NXP TechSupport

what bsp version do you use? old bsp 4.14) has timestamp issue as I known, try to use the latest bsp which should be fixed this

 

0 Kudos

151 Views
crg7475
Contributor II

Sorry for the late reply. Not sure - I am using a Toradex board here, and my BSP is Yocto Dunfell. In the linux-imx logs I see this commit: "MLK-24960: [8QM_MEK/8QXP_MEK]mxc:vpu_malone: move timestamp manager to firmware" - is this what you mean? If so, this is already included. I need a way to turn the timestamp manager off and instruct the driver to pass along the timestamps that I specified from the encoded to the corresponding decoded frames.

0 Kudos