Video Transmission over UDP/CDC_NCM/USB on i.MX 6 Solo and L3.0.35_4.1.0_130816

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Video Transmission over UDP/CDC_NCM/USB on i.MX 6 Solo and L3.0.35_4.1.0_130816

710 Views
oceanjin
Contributor I

Hi, I am currently developing an automotive embedded system based on i.MX 6 Solo chip and L3.0.35_4.1.0_130816_source.tar.gz

The application that I have been working on is Mirror Link.

Once a smartphone that has MirrorLink compliant is connected through an USB cable to the Head Unit, video and audio data are transferred from the phone to the unit.

The problem is that the video transfer throughput via RTP/UDP/IP/CDC_NCM/USB is somewhat slow.

MP4 files with low resolution are OK, but those with high resolution (1280x720p or above) are in poor conditions.

The TCP/UDP tuning parameters have been modified as follows.

net.core.rmem_default = 108544 -> 16777216 (default -> new)

net.core.rmem_max =     108544 -> 16777216

net.core.wmem_default = 108544 ->16777216

net.core.wmem_max =     108544 -> 16777216

net.core.optmem_max =   10240 -> 16777216

net.ipv4.tcp_mem =          5328    7104   10656

                                   -> 65536  131072  262144

net.ipv4.udp_mem =        5328    7104   10656

                                   -> 65536  131072  262144

net.ipv4.tcp_rmem =     4096   87380    227328

                                ->  8192   87380  16777216

net.ipv4.udp_rmem_min = 4096 -> 16384

net.ipv4.tcp_wmem =    4096   16384    227328

                                 ->  8192   87380  16777216

net.ipv4.udp_wmem_min = 4096 -> 16384

Could somebody verify that these numbers are reasonable, or suggest  any better buffer settings?

Thanks in advance.

0 Kudos
2 Replies

504 Views
jamesbone
NXP TechSupport
NXP TechSupport

Hello Ocean,

I do not think the problem of performance that you are experience could be related to the buffer settings,  it rather think it is going to be related to the sink pipeline,  I recommend you to use the mfw_v4lsink .  To the this task.  do you have pipeline that help to reproduced the issue?

0 Kudos

504 Views
oceanjin
Contributor I

Hello James,

Thanks for your reponse.

It seems to me like you suggest v4lsink.imx:  mfw_v4lsink: v4l2 video sink.

In the application, MirrorLink, I do not use gstreamer at all.

RGB565 raw video data are packetized at the mirrorlink phone and sent to the target board through CDC_NCM over the USB interface.

Once the video data are depacketized, they are sent to the mxc_vout via Video4Linux2 interface using such ioctl commands as VIDIOC_REQBUFS, VIDIOC_QUERYBUF, VIDIOC_QBUF, VIDIOC_DQBUF, VIDIOC_STREAMON and VIDIOC_STREAMOFF.

I referred to mxc_v4l2_output.c found at imx-test-3.0.35-4.1.0 included in L3.0.35_4.1.0_130816_source.

One more thing is that since the video data are not encoded in such formats as H.264 or MPEG4, the size of the data transmitted greatly depend on the video output size on the mirrorlink phone, rather than on the resolution of the recorded video.

Thanks.

0 Kudos