<div dir="ltr"><div>Hi, I have been having terrible difficulty tracking down an open socket issue and I am reaching out to the community for help.</div><div><br></div><div>My application is running on gstreamer-1.2.2 on the iMX6Q Wandboard, which is an ARM9 based platform.  I am running kernel 3.10.17-ga from Freescale, with an imx plugin as the video sink from <a href="https://github.com/Freescale/gstreamer-imx">https://github.com/Freescale/gstreamer-imx</a>.  I am using playbin to set up the video decoding pipeline, which will run through a playlist of local files (mpeg2, mpeg4 and h264 formats).  The application runs through the list fine, however it leaves four open sockets (or two socket pairs) at the end of each video.  </div>
<div>The basic structure of my code looks something like this:</div><div><br></div><div>TgstDec::play(){</div><div>  pipeline = gst_element_factory_make ("playbin", "playbin");</div><div>  g_object_set (pipeline, "uri", source.c_str(), NULL);</div>
<div>  g_object_set (pipeline, "video-sink", videosink, NULL);</div><div><br></div><div>  loop = g_main_loop_new (NULL, false);</div><div>  bus  = gst_pipeline_get_bus (GST_PIPELINE (pipeline));</div><div>  gst_bus_add_signal_watch (bus);</div>
<div>  g_signal_connect (bus, "message::eos", G_CALLBACK (playDecEOS), NULL);</div><div>  gst_element_set_state (GST_ELEMENT (pipeline), GST_STATE_PLAYING);</div><div>  g_main_loop_run (loop);</div><div><br></div>
<div>/* Cleanup */</div><div>  gst_object_unref (bus);</div><div>  gst_bus_remove_signal_watch (bus);</div><div>  g_main_loop_unref (loop);</div><div>}</div><div><br></div><div>TgstDec::playDecEOS(GstBus *bus,GstMessage *msg, GMainLoop *main_loop){</div>
<div><div>   gst_element_set_state (GST_ELEMENT (playDec.pipeline), GST_STATE_NULL);</div><div>   gst_object_unref (GST_OBJECT (playDec.pipeline));</div></div><div><div>   g_main_loop_quit (playDec.loop);</div><div>   return true;</div>
</div><div>}</div><div><br></div><div>Then the URI source is updated and the play function is called again.  As far as I can tell, the code looks clean, but their are always 4 sockets left open.  I have also tried using the about-to-finish signal instead of the EOS message, setting the state to paused instead of null and never unreferencing it, and setting the URI directly instead of using my own list playback handler.  None of these approaches made a difference, and some even made it worse.</div>
<div><br></div><div>I compiled the code on my build machine running Ubuntu 12.04 and the same version of gstreamer, replacing the video sink with xvimagesink.  The program ran fine without any open sockets or any other memory leaks.  I do not have xvimagesink available on my board, so I opted to test with fbdevsink.  From my understanding, this will write the stream directly to the hardware decoder, bypassing the gstreamer-imx plugin.  After playing the first video, 4 sockets were left open.  So I tried a third time and replaced the video sink with fakesink.  This time, the application ran exactly as expected; files were opened, played, and closed again.  </div>
<div><br></div><div>I don't believe that the issue is stemming from my own code, because it runs correctly on my desktop as well as on the board with fakesink.  Also, I don't believe it is an issue with the gstreamer-imx plugin.  The plugin does not use sockets anywhere, and I have been told by the developer that he has never seen an issue like this before.  That should leave me with either gstreamer or the kernel as the culprit, but I have not been able to narrow it down beyond that.  </div>
<div><br></div><div>So my question is, can I rightly assume that my code and the imx plugin are not the source of the bug, based on the information I have provided?  And if that is true, then what would be the next step?</div>
<div><br></div><div>Thank you,</div><div>Josh</div><div><br></div><div> <br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>