<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>i.MX ProcessorsのトピックExcessive socket throughput degradation under HD streaming</title>
    <link>https://community.nxp.com/t5/i-MX-Processors/Excessive-socket-throughput-degradation-under-HD-streaming/m-p/351792#M48932</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello, we routinely observe excessive socket throughput reduction (&amp;lt;300kbps)&lt;BR /&gt;when decoding streaming video using isink, or low-latency, or 720p decode to 1080p hdmi output.&lt;BR /&gt;This can be introduced under the following setup:&lt;BR /&gt;Encode side:&lt;BR /&gt;&amp;nbsp;&amp;nbsp; Encoded 720p60 strem from independent board with pipe:&lt;BR /&gt;&amp;nbsp;&amp;nbsp; mfw_v4lsrc&amp;nbsp; ! vpuenc codec=6 bitrate=200000 ! rtph264pay ! udpsink port=xxx host="xx.xx.xx.xx" sync=false async=false&lt;BR /&gt;Decode side:&lt;BR /&gt;Case 1: &lt;BR /&gt;&amp;nbsp;&amp;nbsp; hdmi output set to S:1280x720p-60&lt;BR /&gt;&amp;nbsp;&amp;nbsp; udpsrc port=xxx caps='...' ! rtph264depay ! vpudec ! mfw_isink sync=false&lt;BR /&gt;&amp;nbsp;&amp;nbsp; hardware setup Gateworks IMX6 DL running 3.10.17-1.0.0&lt;BR /&gt;Case 2:&lt;BR /&gt;&amp;nbsp;&amp;nbsp; hdmi output set to S:1920x1080p-60&lt;BR /&gt;&amp;nbsp;&amp;nbsp; udpsrc port=xxx caps='...' ! rtph264depay ! vpudec ! mfw_v4lsink sync=false&lt;BR /&gt;&amp;nbsp;&amp;nbsp; hardware setup Gateworks IMX6 DL running 3.10.17-1.0.0&lt;BR /&gt;Case 3:&lt;BR /&gt;&amp;nbsp;&amp;nbsp; hdmi output set to S:1280x720p-60&lt;BR /&gt;&amp;nbsp;&amp;nbsp; udpsrc port=xxx caps='...' ! rtph264depay ! vpudec ! mfw_v4lsink sync=false&lt;BR /&gt;&amp;nbsp;&amp;nbsp; hardware setup IMX6 solo running 3.10.17-1.0.0&lt;/P&gt;&lt;P&gt;The buffer overflow and packet loss can be observed by "cat /proc/net/udp".&lt;BR /&gt;&amp;nbsp;&amp;nbsp; &lt;BR /&gt;Note, by changing isink, v4lsink, 1080p hdmi output, or even add vpu low-latency=true, one can &lt;BR /&gt;trigger this excessive low socket throughput. Loading using "top" show only 10-15% loading.&lt;BR /&gt;encoder bit rate measured by monitoring ifconfig.&amp;nbsp; For all cases when using 720p output + v4lsink &lt;BR /&gt;without low-latency, we do not see this issue.&amp;nbsp; We do not see any dependency on bit rate, or even &lt;/P&gt;&lt;P&gt;when both encode/decode are on the same hardware running through localhost (127.0.0.1).&lt;/P&gt;&lt;P&gt;It seems to suggest that there is some underlying scheduling or resource sharing issues that is &lt;BR /&gt;causing this loss of throughput state.&amp;nbsp; When in a working configuration, we can run this upto&lt;BR /&gt;4mbps without seeing any socket limitations.&amp;nbsp; Any insight to this would be great.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Mon, 29 Sep 2014 00:28:31 GMT</pubDate>
    <dc:creator>yendohu</dc:creator>
    <dc:date>2014-09-29T00:28:31Z</dc:date>
    <item>
      <title>Excessive socket throughput degradation under HD streaming</title>
      <link>https://community.nxp.com/t5/i-MX-Processors/Excessive-socket-throughput-degradation-under-HD-streaming/m-p/351792#M48932</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello, we routinely observe excessive socket throughput reduction (&amp;lt;300kbps)&lt;BR /&gt;when decoding streaming video using isink, or low-latency, or 720p decode to 1080p hdmi output.&lt;BR /&gt;This can be introduced under the following setup:&lt;BR /&gt;Encode side:&lt;BR /&gt;&amp;nbsp;&amp;nbsp; Encoded 720p60 strem from independent board with pipe:&lt;BR /&gt;&amp;nbsp;&amp;nbsp; mfw_v4lsrc&amp;nbsp; ! vpuenc codec=6 bitrate=200000 ! rtph264pay ! udpsink port=xxx host="xx.xx.xx.xx" sync=false async=false&lt;BR /&gt;Decode side:&lt;BR /&gt;Case 1: &lt;BR /&gt;&amp;nbsp;&amp;nbsp; hdmi output set to S:1280x720p-60&lt;BR /&gt;&amp;nbsp;&amp;nbsp; udpsrc port=xxx caps='...' ! rtph264depay ! vpudec ! mfw_isink sync=false&lt;BR /&gt;&amp;nbsp;&amp;nbsp; hardware setup Gateworks IMX6 DL running 3.10.17-1.0.0&lt;BR /&gt;Case 2:&lt;BR /&gt;&amp;nbsp;&amp;nbsp; hdmi output set to S:1920x1080p-60&lt;BR /&gt;&amp;nbsp;&amp;nbsp; udpsrc port=xxx caps='...' ! rtph264depay ! vpudec ! mfw_v4lsink sync=false&lt;BR /&gt;&amp;nbsp;&amp;nbsp; hardware setup Gateworks IMX6 DL running 3.10.17-1.0.0&lt;BR /&gt;Case 3:&lt;BR /&gt;&amp;nbsp;&amp;nbsp; hdmi output set to S:1280x720p-60&lt;BR /&gt;&amp;nbsp;&amp;nbsp; udpsrc port=xxx caps='...' ! rtph264depay ! vpudec ! mfw_v4lsink sync=false&lt;BR /&gt;&amp;nbsp;&amp;nbsp; hardware setup IMX6 solo running 3.10.17-1.0.0&lt;/P&gt;&lt;P&gt;The buffer overflow and packet loss can be observed by "cat /proc/net/udp".&lt;BR /&gt;&amp;nbsp;&amp;nbsp; &lt;BR /&gt;Note, by changing isink, v4lsink, 1080p hdmi output, or even add vpu low-latency=true, one can &lt;BR /&gt;trigger this excessive low socket throughput. Loading using "top" show only 10-15% loading.&lt;BR /&gt;encoder bit rate measured by monitoring ifconfig.&amp;nbsp; For all cases when using 720p output + v4lsink &lt;BR /&gt;without low-latency, we do not see this issue.&amp;nbsp; We do not see any dependency on bit rate, or even &lt;/P&gt;&lt;P&gt;when both encode/decode are on the same hardware running through localhost (127.0.0.1).&lt;/P&gt;&lt;P&gt;It seems to suggest that there is some underlying scheduling or resource sharing issues that is &lt;BR /&gt;causing this loss of throughput state.&amp;nbsp; When in a working configuration, we can run this upto&lt;BR /&gt;4mbps without seeing any socket limitations.&amp;nbsp; Any insight to this would be great.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 29 Sep 2014 00:28:31 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-Processors/Excessive-socket-throughput-degradation-under-HD-streaming/m-p/351792#M48932</guid>
      <dc:creator>yendohu</dc:creator>
      <dc:date>2014-09-29T00:28:31Z</dc:date>
    </item>
  </channel>
</rss>

