Issue with decoding live interlaced source

Hello DaneLLL,

As per your request I am creating this new thread regarding the issue with decoding live interlaced source. Here is the link to the original thread:

After encoding interlaced source using 00_video_decode with our patch that simulates live decoding, we see visual artifacts in the resulting video. See attached picture.

The same code and patch built for r32.2.3 works perfect and does not produce artifacts.

We prepared a patch to 00_video_decode sample that demonstrates the issue - with 40ms live sleep.

Below is the patch and steps on how to reproduce the issue on SDK r32.6.1.

--- a/00_video_decode/video_decode_main.cpp        2021-07-26 22:37:32.000000000 +0300
+++ b/00_video_decode/video_decode_main.cpp     2021-08-24 12:59:14.271718743 +0300
@@ -135,7 +135,7 @@
     buffer->planes[0].bytesused = 4;
     stream_ptr += 4;
-    if (ctx->copy_timestamp)
+    //if (ctx->copy_timestamp)
       if (ctx->decoder_pixfmt == V4L2_PIX_FMT_H264) {
         if ((IS_H264_NAL_CODED_SLICE(stream_ptr)) ||
@@ -1706,6 +1706,9 @@
         v4l2_buf.m.planes[0].bytesused = buffer->planes[0].bytesused;
+       if (ctx.flag_copyts)
+         usleep(40000);
         if (ctx.input_nalu && ctx.copy_timestamp && ctx.flag_copyts)
           /* Update the timestamp. */
./video_decode H264 --disable-rendering -o out_nv12.raw --input-nalu sample.h264
ffmpeg -y -f rawvideo -pixel_format nv12 -s 1920x1080 -i out_nv12.raw -c:v libx264 -preset fast -crf 28 -g 300 out.ts

sample.h264 from l4t2-demo/sample.h264 at main · maxlapshin/l4t2-demo · GitHub

Thanks for reporting the issue. We will do further investigation.

We have checked this and the symptom looks identical to the topic:
Possible multimedia api regression with decode interlace source

The recorded out.ts are identical. This looks to be duplicate. Could you confirm this? Not sure if you have different observation. Please advise.


sorry for the confusion.
You asked to open a new topic and share patch steps for cleanliness.

I was under the impression that you wanted us to make more concise description of the issue with interlaced live sources.

This feature is very important to us, for we cannot stay on the r32.2.3 after you improved the situation with flush deadlock in the recent version.

The solution is in this post:
Possible multimedia api regression with decode interlace source - #30 by DaneLLL

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.