Timestamp tv_sec value goes to 0 when over 1844674407371

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

Hi, I’m using multimedia api in jetson tx2 (R32.6.1, R32.7.4)

I’m wrote code based on multimedia api sample. (video_decode_main)

Recently, I have decoding issue when v4l2_buf.timestamp.tv_sec over 1844674407370 decimal value.

When I queue v4l2_buf has timestamp.tv_sec 1844674407371 in output plane, (decoder->output_plane.qBuffer(v4l2_buf, nullptr))
v4l2_buffer in dequeued buffer at capture_plane has 0 in v4l2_buf.

everytime exactly tv_sec value is over than 1844674407371, problem occured.

timestamp.tv_sec allocates 8bytes, so it couldn’t be happen.

how can I resolve this problem?

thank you.

3

Please print the sof_timestamp in vi5_fops.c to confirm in kernel space.

#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 4, 0)
559  	ts = ns_to_timespec((s64)descr->status.sof_timestamp);
560  #else
561  	ts = ns_to_timespec64((s64)descr->status.sof_timestamp);
562  #endif
563  #if KERNEL_VERSION(5, 4, 0) > LINUX_VERSION_CODE
564  	trace_tegra_channel_capture_frame("sof", ts);
565  #else
566  	trace_tegra_channel_capture_frame("sof", &ts);
567  #endif
568  	vb->vb2_buf.timestamp = descr->status.sof_timestamp;
569
4

Hi, Thanks for reply.

I tried to print sof_timestamp in vi5_fops.c but nothing printed.

I found out that

this link says that I should modify vi4_fops.c because I’m using TX2 NX in xavier devkit based carrier board.

so I changed file like this, but I can’t see nothing in dmesg.

modified.patch (6.1 KB)

Where did I do wrong?

thanks.

*note: I’m facing this issue also, I tried to reproduce this issue and this issue happend.
Decoding stops after running “00_video_decode_test” for a long time - Jetson & Embedded Systems / Jetson TX2 - NVIDIA Developer Forums

5

Using the pr_info() instead of dev_dbg()

6

please confirm modify vi4_fops is correct or not?

7

Yes, vi4_fops.c for TX2

8

Please help me. I can’t see any logs in dmesg

only I get log from dmesg is like this.

root@VADevice_000322654554:/home/test# dmesg | grep vi4
[ 3.929528] tegra-vi4 15700000.vi: modified (only_pr_info) using default number of vi channels,15
[ 3.933643] tegra-vi4 15700000.vi: initialized
[ 3.934465] tegra-vi4 15700000.vi: subdev 150c0000.nvcsi–2 bound
[ 3.934544] tegra-vi4 15700000.vi: subdev 150c0000.nvcsi–1 bound

I changed print function as you suggested
modified.patch (9.2 KB)

I can see changes only in vi4.c

I build kerel instructed in this page.
NVIDIA Jetson Linux Driver Package Software Features : Kernel Customization | NVIDIA Docs
changed .config file (CONFIG_MESSAGE_LOGLEVEL_DEFAULT=7)

added “debug loglevel=8” in extlinux.conf

Regards

9

Did you confirm replace the kernel Image build by you?
Check the build date by below command.

uname -a

10

Hi,
results shows like this

image
image919×37 2.76 KB

Linux VADevice_000322654554 4.9.337 #12 SMP PREEMPT Wed Aug 30 17:23:55 KST 2023 aarch64 aarch64 aarch64 GNU/Linux
I used rootfs from tools/sampelfs/nv_build_samplefs.sh
and
I installed nvidia-cuda, nvidia-cudnn8, nvidia-l4t-jetson-multimedia-api, nvidia-opencv using apt

I edited vi4.c line 296 string from
“using default number of vi channels,%d\n” to
" modified (only_pr_info) using default number of vi channels"
I can see changes in dmesg but I can’t see vi4_fops change in dmesg

I’m receiving H.264 stream via ethernet. Also this uses vi4_fops?

11

Looks like you doesn’t using CSI YUV camera? The vi4_fops.c is for CSI YUV camera only. Does this topic relative camera?

12

Nope, I’m receiving H.264/H.265 from network and put it to NvVideoDecoder.

When program starts and receive frame, I put streams in v4l2_buf.

I manually put timestamp.tv_sec value starts with 0. (not use tv_usec)

every time I receive frame, put timestamp.tv_sec value of frame count.

I posted this issue because my program (runned almost a month) stopped like this issue.
Decoding stops after running “00_video_decode_test” for a long time - Jetson & Embedded Systems / Jetson TX2 - NVIDIA Developer Forums

I tried to find why program stopped, and I found timestamp goes back to 0 in v4l2_buf from dequed capture plane when I put 1844674407371 value in v4l2_buf.timestamp.tv_sec and queue buffer to output plane. (1 for 1844674407372, 2 for 1844674407373 …)

13

OK, than that doesn’t matter with the vi4_fops.c
You problem need to confirm the timestamp for the network source.

Thanks

14

Regardless of source, I manually put timestamp value in v4l2_buf.
I can’t upload full source, but this is how I manualy put timestamp and frame to v4l2_buf

struct v4l2_buffer v4l2_buf;
struct v4l2_plane planes[MAX_PLANES];
memset(&v4l2_buf, 0, sizeof(v4l2_buf));
memset(&(planes[0]), 0, sizeof(planes));
if (NvBuffer* buffer = getOutputBuffer(&v4l2_buf, &(planes[0]))) {
if ((v4l2_buf.flags & V4L2_BUF_FLAG_ERROR) != 0) {
printf(LP_ERR, L"V4L2_BUF_FLAG_ERROR"); //< for test.
}
if (_param.inputNalUnit()) {
/* read the input nal unit. /
}
else {
/ read the input chunks. /
read_decoder_input_chunk(frame, buffer);
}
v4l2_buf.m.planes[0].bytesused = buffer->planes[0].bytesused;
v4l2_buf.flags |= V4L2_BUF_FLAG_TIMESTAMP_COPY;
v4l2_buf.timestamp.tv_sec = frame.bufferCount();
v4l2_buf.timestamp.tv_usec = 0;
auto const decoder = _videoContext->decoder();
if (checkError(decoder->output_plane.qBuffer(v4l2_buf, nullptr), “Error Qing buffer at output plane”)) { //< enqueue.
_videoContext->abort();
return;
}

15

I mean you need to check the timestamp of the buffer from the network without problem. Suppose it could be the input buffer already set to 0 already.

16

Sorry, but I can’t understand what you exactly talking about.

The h.264/265 source from network I receive does not contain timestamp and I only use its frame data.

So it could not make trouble.

Also, I just tested it with your sample code video_decode_main.cpp and issue occurs.

changed context_t.start_ts data type to uint64_t and start_ts value starts with 1844674407365

result from dequeued buffer from capture_plane gives me 1844674407365 ~ 1844674407370, 0 ~ end.

17

OK, could be need to check the encod/decode driver.

20

Hi,
Please share a patch to 00_video_decode sample. So that we can replicate the issue and check further.

21

Hi, here’s patch. you can reproduce it easily
vide_decode.patch (60 Bytes)
video_decode_main.patch (3.0 KB)

  • used mmap option both capture plane and output plane
23

Hi,

sorry to jump in.

Can you check how you prepare the patch?
It should be like:

diff [options] [original filename] [changed filename]

It seems like the order of files is reversed so we are unable to apply the patch.

24

video_decode.patch (60 Bytes)
video_decode_main.patch (3.0 KB)
Hi, I made a mistake. I make patch file [diff changed original] this way.

uploaded new one. try this.

1 Like