i.MX ProcessorsのトピックRe: Overall Bus Load for H264 VPU decoding with i.MX6Q

Overall Bus Load for H264 VPU decoding with i.MX6Q

henryabril1 — Wed, 17 May 2017 20:17:59 GMT

Hi,

I would like to display 4 Ethernet camera streams with qHD resolution (960x540) in a LVDS 1080p display.
For the moment I am displaying the 4 camera streams in a smaller display (1024x768).
As a result I have (in my opinion) a high "Overall Bus Load" (75% measured with the mmdc2 tool) and I would expect a higher "Overall Bus Load" with the 1080p display.

Could you please help me to clarify the following questions:
[1] Is the measured 75% "Overall Bus Load" a normal value for the exposed use case?
[2] How can I calculate the theoretical "DDR memory allocation" and "Bus load" for each of the elements of my pipeline?
[3] Is there a way to reduce the "Overall Bus Load"? (without reducing display or cameras stream resolutions...)

HW & SW setup

Community BSP (Morty)
i.MX6Q SABRE-SDB Evaluation Board
Ethernet cameras configuration: H.264 / 24Mb/s / qHD (960x544)
GStreamer pipelines:

gst-launch-1.0 udpsrc port=50004 caps="application/x-rtp,media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96" ! rtph264depay ! h264parse ! imxvpudec ! imxeglvivsink window-width=512 window-height=384 window-x-coord=0 window-y-coord=0 sync=false
gst-launch-1.0 udpsrc port=50005 caps="application/x-rtp,media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96" ! rtph264depay ! h264parse ! imxvpudec ! imxeglvivsink window-width=512 window-height=384 window-x-coord=512 window-y-coord=0 sync=false
gst-launch-1.0 udpsrc port=50006 caps="application/x-rtp,media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96" ! rtph264depay ! h264parse ! imxvpudec ! imxeglvivsink window-width=512 window-height=384 window-x-coord=0 window-y-coord=384 sync=false
gst-launch-1.0 udpsrc port=50007 caps="application/x-rtp,media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96" ! rtph264depay ! h264parse ! imxvpudec ! imxeglvivsink window-width=512 window-height=384 window-x-coord=512 window-y-coord=384 sync=false

mmdc2 results
root@imx6qsabresd:~# export MMDC_SLEEPTIME=1000; /unit_tests/mmdc2
i.MX6Q detected.
MMDC SUM

MMDC new Profiling results:
***********************
Measure time: 1001ms
Total cycles count: 528077120
Busy cycles count: 398627871
Read accesses count: 19186960
Write accesses count: 18073067
Read bytes count: 724389624
Write bytes count: 443528184
Avg. Read burst size: 37
Avg. Write burst size: 24
Read: 690.14 MB/s / Write: 422.56 MB/s Total: 1112.70 MB/s

Utilization: 18%
Overall Bus Load: 75%
Bytes Access: 31

Thanks!

Re: Overall Bus Load for H264 VPU decoding with i.MX6Q

igorpadykov — Thu, 18 May 2017 05:19:22 GMT

Hi Henry

- in general 75% "Overall Bus Load" is tolerable load
- I am afraid there is no way to calculate theoretical "DDR memory allocation" or "Bus load"
for such specific use case and reduce "Overall Bus Load". One can try to relocate some memory
buffers to OCRAM.

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: Overall Bus Load for H264 VPU decoding with i.MX6Q

henryabril1 — Thu, 18 May 2017 13:50:51 GMT

Hi,

75% is the current bus load without any additional process running in parallel (this will not be our the final use case) and without the additional bus load due to the 1080p display we will use. We need to find the way to moderate the bus load due to the camera streams processing.

As you mentioned, there might not be a way to calculate the exact "DDR memory allocation" or "Bus load" element by element, but I think it should be possible to have a rough estimation about it.

I have found some similar calculations at:
https://community.nxp.com/thread/307038

But those calculations seem to apply to the official Freescale plugins with different decoder, different sink (IPU instead of GPU), etc.

Relocationg buffers to OCRAM is not an option for us.

I would still like to clarify the following questions:
[1] Is the measured 75% "Overall Bus Load" a normal value for the exposed use case?
[2] How can I calculate the theoretical "DDR memory allocation" and "Bus load" for the imxvpudec and imxeglvivsink elements of my pipeline (vpu buffers, color conversion???, frame buffers, etc.)?
[3] Are there any additional options to reduce the "Overall Bus Load"? (without reducing display or cameras stream resolutions...)

Thanks!