Socket trouble with playbin on gstreamer-1.2.2

[Sebastian Dröge]

On Do, 2014-05-08 at 14:58 -0400, Joshua Kurland wrote:
> 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?

If you're using the same GStreamer versions on both, then probably yes.
However the fbdevsink sink will not replace the hardware decoders,
they're still used in front of it. fbdevsink only renders raw video to
the framebuffer device.

I would expect the problem to be in gstreamer-imx or any of the
lower-level layers of the Freescale stack. Note that a socket pair is
also created for every GMainContext for example, and is often used for
implementation of event loops.

-- 
Sebastian Dröge, Centricular Ltd - http://www.centricular.com
Expertise, Straight from the Source
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140511/6fe1798a/attachment.sig>