Socket trouble with playbin on gstreamer-1.2.2

[Joshua Kurland]

Hi, I have been having terrible difficulty tracking down an open socket
issue and I am reaching out to the community for help.

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
https://github.com/Freescale/gstreamer-imx.  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.
The basic structure of my code looks something like this:

TgstDec::play(){
  pipeline = gst_element_factory_make ("playbin", "playbin");
  g_object_set (pipeline, "uri", source.c_str(), NULL);
  g_object_set (pipeline, "video-sink", videosink, NULL);

  loop = g_main_loop_new (NULL, false);
  bus  = gst_pipeline_get_bus (GST_PIPELINE (pipeline));
  gst_bus_add_signal_watch (bus);
  g_signal_connect (bus, "message::eos", G_CALLBACK (playDecEOS), NULL);
  gst_element_set_state (GST_ELEMENT (pipeline), GST_STATE_PLAYING);
  g_main_loop_run (loop);

/* Cleanup */
  gst_object_unref (bus);
  gst_bus_remove_signal_watch (bus);
  g_main_loop_unref (loop);
}

TgstDec::playDecEOS(GstBus *bus,GstMessage *msg, GMainLoop *main_loop){
   gst_element_set_state (GST_ELEMENT (playDec.pipeline), GST_STATE_NULL);
   gst_object_unref (GST_OBJECT (playDec.pipeline));
   g_main_loop_quit (playDec.loop);
   return true;
}

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.

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.

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.

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?

Thank you,
Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140508/74d20863/attachment.html>