Dual video streaming 1080p+720p works okay on iMX6Q but not on iMX6QP

[frankba]

I use an ov5640 camera module for H.264 network streaming on two boards (nitrogen6_max): one with iMX6QP the other "only" with iMX6Q with a current Yocto morty image (Linux nitrogen6x 4.1.15-2.0.0-ga+yocto+gfc4f6c4, GStreamer 1.8.3).

GStreamer pipeline as follows:

gst-launch-1.0 imxv4l2videosrc device=/dev/video1 imx-capture-mode=5 queue-size=8 \
! "video/x-raw, width=1920, height=1080" ! tee name=t \
t. ! queue ! imxvpuenc_h264 gop-size=15 idr-interval=15 bitrate=5000 me-search-range=3 ! \
     queue ! rtph264pay config-interval=1 pt=96 ! \
     udpsink clients=192.168.2.108:5006 sync=false -v \
t. ! queue ! imxipuvideotransform ! "video/x-raw, width=1280, height=720" ! \
     queue ! imxvpuenc_h264 gop-size=15 idr-interval=15 bitrate=5000 me-search-range=3 ! \
     queue ! rtph264pay config-interval=1 pt=96 ! \
     udpsink clients=192.168.2.108:5004 sync=false -v

Using the iMX6Q board, I can watch both streams on my Ubuntu build host and see two smooth video streams at a  framerate of ~23 fps:

gst-launch-1.0 udpsrc port=5004 ! \
application/x-rtp,media=video,clock-rate=90000,encoding-name=H264,payload=96 ! \
rtph264depay ! decodebin ! fpsdisplaysink sync=false \
udpsrc port=5006 ! \
application/x-rtp,media=video,clock-rate=90000,encoding-name=H264,payload=96 ! \
rtph264depay ! decodebin ! fpsdisplaysink sync=false

The mmdc tool from imx-test shows the memory performance:

Avg. Read burst size: 17                                                                                  
Avg. Write burst size: 14                                                                                 
Read: 395.88 MB/s /  Write: 242.08 MB/s  Total: 637.96 MB/s                                               
Utilization: 8%                                                                                           
Overall Bus Load: 91%                                                                                     
Bytes Access: 16    

Now, I tried to repeat this setup on my iMX6QP board in hope for a reduced bus load and, maybe, enough headroom for a third (tiny preview) stream. But that failed. The bus load is a little lighter, as expected:

Avg. Read burst size: 17
Avg. Write burst size: 14
Read: 391.10 MB/s / Write: 299.60 MB/s Total: 690.70 MB/s
Utilization: 11%
Overall Bus Load: 76%
Bytes Access: 15

But both streams are showing bad artefacts from time to time.

It looks like missing bursts of uncompressed image data. Both streams are showing identical artefacts, so this could be errors (overruns?) in the stream from the ov5640 sensor to memory.

Btw: Dual 1080p streaming works fine, as there is no need for scaling. The VPU is not the bottleneck.

Is there a way to avoid this? Am I doing something wrong? Any debugging aid?

Frank

[Yuri]

Hello,

  Perhaps it makes sense to check i.MX6QP memory, using the DDR Stress Test.
Also, please verify if proper for i.MX6DP .dtb file is applied.

Have a great day,

Yuri

------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer

button. Thank you!

[frankba]

Hi Yuri,

stress test runs fine on my board. I doubt that a memory error would show the kind of artefacts I see. It's not corrupted data but missing/skipped data. Dual 1080p streaming also runs fine. Could it be an issue with AXI priorities for IPU1 and IPU2?

Frank

[Yuri]

Hello,

  You may look at EB828 (MMDC & NoC Configuration for Optimal DDR3 Performance
on the i.MX 6DualPlus/6QuadPlus), in particular - at section 6.1 (NoC register configuration).

" [...] we recommend customers use the DDR3 MMDC Excel register programming aid to assist

in configuring these specific parameters."

http://www.nxp.com/doc/EB828 

MX6DQP DDR3 Script Aid 

Regards,

Yuri.

[frankba]

Hi Yuri,

thanks for sending the document. The settings seem okay for the nitrogen6qp_max board (using latest u-boot 2017.3):

/* NoC DDR configuration register set */
DATA 4 0x00bb0008 0x00000004
DATA 4 0x00bb000c 0x2891E41A
DATA 4 0x00bb0038 0x00000564
DATA 4 0x00bb0014 0x00000040
DATA 4 0x00bb0028 0x00000020
DATA 4 0x00bb002c 0x00000020

/* MMDCx_MAARCR - bit 26 - Disable all MMDC arbitration and reordering controls */
DATA 4 0x021b0400 0x14420000

BOOT_CFG3 seems also to be okay: 0x00

Do you have any more ideas?

Frank

[gary_bisson]

Hi Frank,

Can you try using the g2dvideotransform instead of the IPU one? This should help since the IPU only handles 1024x1024 frames, in your case it means it has to run 2 jobs to downscale.

Regards,

Gary

[frankba]

Hi Gary,

thought that g2dvideotransform is limited to various types of RGB output. How could it be used for I420 scaling?

Regards,

Frank