GNonLin & QT in Windows

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

GNonLin & QT in Windows

amartin
Dear all,

I had an odd problem with a QT application in windows that exploits gstreamer (OSSBUILD).

I have a QT widget that host a Gstreamer pipeline. This application is a kind of playlist player, so after the first video a second video should be displayed through the GNonLin library.

In Linux the program runs perfectly but in Windows it doesn't.

According to the GST_DEBUG log differences when the first video send the EOS signal the gnlcomposition freezes. As far as I understand, the problem could be the
"gnlcomposition" element. In fact, the problem and solution is already identified in the problematic function under a FIXME comment.

/-----------------------------------------------/
gnlcomposition.c released code:

static gboolean
ghost_event_probe_handler (GstPad * ghostpad G_GNUC_UNUSED, GstEvent * event,
    GnlComposition * comp)
{
  gboolean keepit = TRUE;

  GST_DEBUG_OBJECT (comp, "event: %s", GST_EVENT_TYPE_NAME (event));

  switch (GST_EVENT_TYPE (event)) {
    case GST_EVENT_NEWSEGMENT:{
      COMP_FLUSHING_LOCK (comp);
      if (comp->priv->pending_idle) {
        GST_DEBUG_OBJECT (comp, "removing pending seek for main thread");
        g_source_remove (comp->priv->pending_idle);
      }
      comp->priv->pending_idle = 0;
      comp->priv->flushing = FALSE;
      COMP_FLUSHING_UNLOCK (comp);
    }
      break;
    case GST_EVENT_EOS:{
      COMP_FLUSHING_LOCK (comp);
      if (comp->priv->flushing) {
        GST_DEBUG_OBJECT (comp, "flushing, bailing out");
        COMP_FLUSHING_UNLOCK (comp);
        keepit = FALSE;
        break;
      }
      COMP_FLUSHING_UNLOCK (comp);

      GST_DEBUG_OBJECT (comp, "Adding eos handling to main thread");
      if (comp->priv->pending_idle) {
        GST_WARNING_OBJECT (comp,
            "There was already a pending eos in main thread !");
        g_source_remove (comp->priv->pending_idle);
      }

      /* FIXME : This should be switched to using a g_thread_create() instead
       * of a g_idle_add(). EXTENSIVE TESTING AND ANALYSIS REQUIRED BEFORE
       * DOING THE SWITCH !!! */
      comp->priv->pending_idle =
          g_idle_add ((GSourceFunc) eos_main_thread, (gpointer) comp);

      keepit = FALSE;
    }
      break;
    default:
      break;
  }

  return keepit;
}
/-----------------------------------------------/

I think that this is the tricky point, because in the QT application I don't create any g_main_loop, so I think that g_idle_add doesn't work properly in this context in windows.

So for the problem is only for live performance (QT player), because when we simply create a file video with the performed result according to a defined timeline, through a g_main_loop for the pipeline, it works perfectly.

So please find below the proposed solution (already checked in Windows):

/-----------------------------------------------/
gnlcomposition.c released code:

static gboolean
ghost_event_probe_handler (GstPad * ghostpad G_GNUC_UNUSED, GstEvent * event,
    GnlComposition * comp)
{
  gboolean keepit = TRUE;

  GST_DEBUG_OBJECT (comp, "event: %s", GST_EVENT_TYPE_NAME (event));

  switch (GST_EVENT_TYPE (event)) {
    case GST_EVENT_NEWSEGMENT:{
      COMP_FLUSHING_LOCK (comp);
      if (comp->priv->pending_idle) {
        GST_DEBUG_OBJECT (comp, "removing pending seek for main thread");
        g_source_remove (comp->priv->pending_idle);
      }
      comp->priv->pending_idle = 0;
      comp->priv->flushing = FALSE;
      COMP_FLUSHING_UNLOCK (comp);
    }
      break;
    case GST_EVENT_EOS:{
      COMP_FLUSHING_LOCK (comp);
      if (comp->priv->flushing) {
        GST_DEBUG_OBJECT (comp, "flushing, bailing out");
        COMP_FLUSHING_UNLOCK (comp);
        keepit = FALSE;
        break;
      }
      COMP_FLUSHING_UNLOCK (comp);

      GST_DEBUG_OBJECT (comp, "Adding eos handling to main thread");
      if (comp->priv->pending_idle) {
        GST_WARNING_OBJECT (comp,
            "There was already a pending eos in main thread !");
        //g_source_remove (comp->priv->pending_idle);
        // FIXING
        g_thread_join((GThread *)comp->priv->pending_idle);
      }

      /* FIXME : This should be switched to using a g_thread_create() instead
       * of a g_idle_add(). EXTENSIVE TESTING AND ANALYSIS REQUIRED BEFORE
       * DOING THE SWITCH !!! */
      //comp->priv->pending_idle =
      //    g_idle_add ((GSourceFunc) eos_main_thread, (gpointer) comp);
      // FIXING
      comp->priv->pending_idle = 
           (guint)g_thread_create((GThreadFunc) eos_main_thread, (gpointer) comp, TRUE, NULL );

      keepit = FALSE;
    }
      break;
    default:
      break;
  }

  return keepit;
}
/-----------------------------------------------/

My feeling is that this change should fit in Linux and Windows developments.

Thank you.

Best Regards.

Angel

--
Ángel Martín Navas
Investigador / Researcher
Televisión Digital y Servicios Multimedia / Digital TV & Multimedia Services

Vicomtech - Visual Interaction Communication Technologies
Mikeletegi Pasealekua, 57 - Parque Tecnológico
20009 Donostia - San Sebastián - Spain
Tel: <a href="tel:%2B%5B34%5D%20943%2030%2092%2030" value="+34943309230" target="_blank">+[34] 943 30 92 30
Fax: <a href="tel:%2B%5B34%5D%20943%2030%2093%2093" value="+34943309393" target="_blank">+[34] 943 30 93 93
e-mail: [hidden email]
www.vicomtech.org

*** member of IK4 Research Alliance ****
www.ik4.es
*** member of GraphicsMedia.net ****
www.graphicsmedia.net



-----------------------------------------------------
Vicomtech is an ISO 9001:2000 certified institute
-----------------------------------------------------

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel