Hello, we routinely observe excessive socket throughput reduction (<300kbps)
when decoding streaming video using isink, or low-latency, or 720p decode to 1080p hdmi output.
This can be introduced under the following setup:
Encode side:
Encoded 720p60 strem from independent board with pipe:
mfw_v4lsrc ! vpuenc codec=6 bitrate=200000 ! rtph264pay ! udpsink port=xxx host="xx.xx.xx.xx" sync=false async=false
Decode side:
Case 1:
hdmi output set to S:1280x720p-60
udpsrc port=xxx caps='...' ! rtph264depay ! vpudec ! mfw_isink sync=false
hardware setup Gateworks IMX6 DL running 3.10.17-1.0.0
Case 2:
hdmi output set to S:1920x1080p-60
udpsrc port=xxx caps='...' ! rtph264depay ! vpudec ! mfw_v4lsink sync=false
hardware setup Gateworks IMX6 DL running 3.10.17-1.0.0
Case 3:
hdmi output set to S:1280x720p-60
udpsrc port=xxx caps='...' ! rtph264depay ! vpudec ! mfw_v4lsink sync=false
hardware setup IMX6 solo running 3.10.17-1.0.0
The buffer overflow and packet loss can be observed by "cat /proc/net/udp".
Note, by changing isink, v4lsink, 1080p hdmi output, or even add vpu low-latency=true, one can
trigger this excessive low socket throughput. Loading using "top" show only 10-15% loading.
encoder bit rate measured by monitoring ifconfig. For all cases when using 720p output + v4lsink
without low-latency, we do not see this issue. We do not see any dependency on bit rate, or even
when both encode/decode are on the same hardware running through localhost (127.0.0.1).
It seems to suggest that there is some underlying scheduling or resource sharing issues that is
causing this loss of throughput state. When in a working configuration, we can run this upto
4mbps without seeing any socket limitations. Any insight to this would be great.
