HDMI Input capture tearing

Hi support,

We are using the HDMI to CSI-2 Bridge (From a third party manufacturer) on a Jetson TK1.
The driver tc358743 is used for this card.
We are getting tearing effect on V4L grabbed frames.

Here is a detail of our software works:
We have a thread which grabs V4L frames at 60Fps and places them into a fifo. The pixel format of these frames is UYVY.
A converter thread will take fifo’s frames and converts them into another pixel format. In our case we have 2 converters threads.
The first one converts frames from UYVY to RGB and the second one converts frames from UYVY to I420.
A H264 hardware encoder thread is used to encode I420 (retrieved from the converter) frames to H264.

Infos:
Kernel version : 3.10.40 R21.4
tc358743 chip (HDMI 2 CSI bridge).

We realized differents tests where V4L grabbed frames present tearing.

-Test 1: V4L capture at 60 Fps, Convertion UYVY->RGB at 30Fps
2 threads running: One for the V4L capture and the second for the convertion. Each thread runs on a distinct CPU.
No tearing on V4L grabbed frames

Here is the output of tegra_stats:

RAM 1053/1893MB (lfb 65x4MB) cpu [32%,1%,48%,2%]@2320 EMC 5%@924 AVP 0%@68 VDE 120 GR3D 0%@12 EDP limit 0
RAM 1053/1893MB (lfb 65x4MB) cpu [31%,1%,48%,0%]@2320 EMC 5%@924 AVP 0%@68 VDE 120 GR3D 0%@12 EDP limit 0
RAM 1053/1893MB (lfb 65x4MB) cpu [28%,2%,51%,1%]@2320 EMC 5%@924 AVP 0%@68 VDE 120 GR3D 0%@12 EDP limit 0
RAM 1053/1893MB (lfb 65x4MB) cpu [32%,0%,48%,2%]@2320 EMC 5%@924 AVP 0%@68 VDE 120 GR3D 0%@12 EDP limit 0


-Test 2
: V4L capture at 60 Fps, Convertion UYVY->RGB at 60Fps
2 threads running: One for the V4L capture and the second for the convertion. Each thread runs on a distinct CPU.
No tearing on V4L grabbed frames

Here is the output of tegra_stats:

RAM 1051/1893MB (lfb 66x4MB) cpu [57%,0%,95%,0%]@2320 EMC 8%@924 AVP 0%@68 VDE 120 GR3D 0%@12 EDP limit 0
RAM 1051/1893MB (lfb 66x4MB) cpu [52%,2%,96%,0%]@2320 EMC 8%@924 AVP 0%@68 VDE 120 GR3D 0%@12 EDP limit 0
RAM 1051/1893MB (lfb 66x4MB) cpu [35%,14%,94%,3%]@2320 EMC 8%@924 AVP 0%@68 VDE 120 GR3D 0%@12 EDP limit 0
RAM 1051/1893MB (lfb 66x4MB) cpu [52%,1%,98%,2%]@2320 EMC 8%@924 AVP 0%@68 VDE 120 GR3D 0%@12 EDP limit 0


-Test 3
: V4L capture at 60 Fps, Convertion UYVY->RGB at 30Fps, Convertion UYVY->I420 at 30Fps
3 threads running: One for the V4L capture and one for each converter. Each thread runs on a distinct CPU.

For this test, we get some tearing on grabbed frames.

Here is the output of tegra_stats:

RAM 1450/1893MB (lfb 6x4MB) cpu [83%,6%,47%,81%]@2320 EMC 9%@924 AVP 0%@68 VDE 120 GR3D 0%@12 EDP limit 0
RAM 1450/1893MB (lfb 6x4MB) cpu [81%,5%,47%,81%]@2320 EMC 9%@924 AVP 0%@68 VDE 120 GR3D 0%@12 EDP limit 0
RAM 1450/1893MB (lfb 6x4MB) cpu [78%,4%,47%,81%]@2320 EMC 9%@924 AVP 0%@68 VDE 120 GR3D 0%@12 EDP limit 0
RAM 1450/1893MB (lfb 6x4MB) cpu [79%,9%,47%,82%]@2320 EMC 9%@924 AVP 0%@68 VDE 120 GR3D 0%@12 EDP limit 0


-Test 4
: V4L capture at 60 Fps, Convertion UYVY->RGB at 15Fps, Convertion UYVY->I420 at 15Fps, H264 Hardware Encoder at 15Fps
4 threads running: One for the V4L capture, one for each converter and one for the H264 Hardware encoder. Each thread runs on a distinct CPU except H264
hardware encoder thread which is not configured to run on a choosen CPU.

The V4L grabbed frames tearing is increased

Here is the output of tegra_stats:

RAM 1449/1893MB (lfb 6x4MB) cpu [30%,2%,27%,40%]@2320 EMC 9%@924 AVP 0%@204 VDE 120 GR3D 0%@12 EDP limit 0
RAM 1449/1893MB (lfb 6x4MB) cpu [25%,2%,30%,40%]@2320 EMC 9%@924 AVP 0%@204 VDE 120 GR3D 0%@12 EDP limit 0
RAM 1449/1893MB (lfb 6x4MB) cpu [29%,1%,28%,42%]@2320 EMC 9%@924 AVP 0%@204 VDE 120 GR3D 0%@12 EDP limit 0
RAM 1449/1893MB (lfb 6x4MB) cpu [28%,3%,27%,39%]@2320 EMC 9%@924 AVP 0%@204 VDE 120 GR3D 0%@12 EDP limit 0


-Test 5
: V4L capture at 60 Fps, Convertion UYVY->RGB at 30Fps, Stress Linux Command
2 threads running: One for the V4L capture and the second for the convertion. Each thread runs on a distinct CPU.

In this test, the stress command is used when the software is running.
stress --vm 2 --vm-bytes 128M --timeout 60 -v

When this command is executed while our software running, V4L grabbed frames tearing appears.
However these tearing effect on grabbed frames appears in the first seconds of stress tool execution.
After the first seconds, tearing effect does not appear on V4L grabbed frames.

Questions:

  1. Is V4L grabbed frames with tearing a known issue on kernel 3.10.40 R21.4 ?
  2. If it is a known issue, was it solved on kernel 3.10.40 R21.5 (totaly or partially)?
    [b]

PS[/b]: We try to use the kernel 3.10.40 R21.5 in order to check if the tearing of V4L grabbed frames appears.

Hi Romary

  1. Those similar pipeline were verified with some use case like gstreamer preview and h264 encode. Could you try the gstreamer? The command should be like below. You may need to modify format and something else to make your case working.
gst-launch-1.0 -v v4l2src device=/dev/video0 \
   ! video/x-raw,format=YUY2,width=640,height=480 \
   ! tee name=t t. ! queue ! xvimagesink sync=false t. ! queue ! \
   videoconvert ! x264enc tune=zerolatency ! h264parse ! \
   matroskamux ! filesink location='raw_dual.mkv' sync=false

Have you try to boost the CPU to verify all of the test case. You can reference to below to boost the CPU.
http://elinux.org/Jetson/Performance

Hi Romary,

Has this issue been clarified and resolved?
Have helps on gstremer or CPU boost?

Thanks