After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 613567 - Cannot query stream duration in playbin2 when GST_MESSAGE_DURATION appears on the bus.
Cannot query stream duration in playbin2 when GST_MESSAGE_DURATION appears on...
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.28
Other Windows
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-03-22 08:17 UTC by Vladimir Eremeev
Modified: 2010-03-24 10:17 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Vladimir Eremeev 2010-03-22 08:17:39 UTC
I'm developing an ActiveX player using GStreamer.
I'm using the SVN trunk of the OSSBuild, built with MSVS 2008 SP1.
The build and installation are successful, 0 warnings and errors appear in the debug window.


I'm creating a new instance of the playbin2 with the following code

m_player = gst_element_factory_make("playbin2","playbin0");
GstElement *bus = (GstElement *)gst_pipeline_get_bus(GST_PIPELINE(m_player));
gst_bus_set_sync_handler (GST_BUS(bus), (GstBusSyncHandler)gst_bus_sync_handler, this);
gst_bus_add_watch (GST_BUS(bus), bus_call, this);
gst_object_unref(bus);
m_loop = g_main_loop_new(NULL,TRUE);

if(!m_videosink){
  m_videosink = gst_element_factory_make("directdrawsink","videosink");
  if(m_videosink){
    g_object_set(m_videosink,"sync",TRUE,"force-aspect-ratio",TRUE,"preroll-queue-len",1,NULL);
      if(!m_hwnd && m_parent)
        m_hwnd=m_parent->hwnd();
      if(m_hwnd)
        gst_x_overlay_set_xwindow_id (GST_X_OVERLAY (m_videosink),m_hwnd);
      g_object_set(G_OBJECT(m_player),"video-sink",m_videosink,NULL);
  }
}

Both, bus_sync_handler and bus_watch contain the following code:

switch (GST_MESSAGE_TYPE (message)) {
...
   case GST_MESSAGE_DURATION:			
   if(gst_element_query_duration(GST_ELEMENT(m_player),&fmt,&m_stream_duration)){
      ....      process duration - set the duration time in a progress indicator and in a text box.
   }
    break;
...
}

The problem is that gst_element_query_duration returns false, and the following message appears:

playbin2: gstplaybin2.c:2064:gst_play_bin_query:<playbin0> Taking cached duration because of pending group switch: 0

Since that, the player cannot correctly handle _DURATION message and cannot draw a correct duration on the form, and no more duration messages appear on the bus.

The duration query is successful, but later, after the file is loaded, set to PLAYING state and again, to PAUSED.

This code worked successfully in the previous release of the OSSBuild (0.10.25)
Comment 1 Tim-Philipp Müller 2010-03-22 08:56:32 UTC
I wonder if this is related to the webkit unit test failure/regression (since they use appsrc IIRC, which was made to post DURATION messages in bytes for whatever reason).
Comment 2 Wim Taymans 2010-03-22 11:31:52 UTC
duration queries are only valid in the PAUSED/PLAYING state. I'm pretty sure that the duration message is posted too early for your query to succeed. There is also probably only one DURATION message.

In short: you should not rely on DURATION messages to trigger the duration query, instead query in the PAUSED/PLAYING state.
Comment 3 Vladimir Eremeev 2010-03-22 12:13:39 UTC
The next in my code, call after setting videosink, is putting a player to the playing state.
The DURATION message appears after that.
Bus watch and sync handler also have a code putting a player to the paused state after the first frame is displayed.
So, everything is OK, the duration is queried in the proper state.
Comment 4 Vladimir Eremeev 2010-03-22 12:22:57 UTC
Well, not everything is OK. The player is in the "ready" state, when the duration message appears.
Comment 5 Tim-Philipp Müller 2010-03-22 12:36:48 UTC
State changes to PAUSED and PLAYING are asynchronous. When the _set_state(PLAYING) returns, it will most likely not have reached PAUSED or PLAYING state yet.
Comment 6 Andoni Morales 2010-03-23 22:43:56 UTC
It's probably not a bug, but I'm having the same issue and not being able to do a duration query after receiving the GST_MESSAGE_DURATION on the bus doesn't seem very logical to me.
My player is based on totem and it has been working since the last GStreamer release, but after the last GStreamer update I can't query the duration after receiving the GST_MESSAGE_DURATION in the bus anymore and I have to do it in the READY to PAUSED transition. (This happens on Windows XP, I'll try later on linux, but I don't think it will happen since many people should have tested totem with the last GStreamer release :P)
If this is not the expected behavior why does totem relies on it  and even prints a debug message when this happens? http://git.gnome.org/browse/totem/tree/src/backend/bacon-video-widget-gst-0.10.c#n2165
I fixed it in my player with the following patch:
http://git.gnome.org/browse/longomatch/commit/?id=04d2eaaa9132cc64e5d0ed77508a0a7d1d2bd29d

Can you please confirm that this is not really a bug (maybe playbin2 is posting this message too soon or maybe it only happens on windows), and that what is done in totem is not the good approach?
Comment 7 Wim Taymans 2010-03-24 09:43:37 UTC
(In reply to comment #6)
> It's probably not a bug, but I'm having the same issue and not being able to do
> a duration query after receiving the GST_MESSAGE_DURATION on the bus doesn't
> seem very logical to me.

Maybe it's not logical but that is what it is. You can't query the duration as soon as you get a
duration message, you have to wait until the pipeline completes the state change to PAUSED.
The duration message is there to inform you about duration changes *after* going to the 
PAUSED state.

> My player is based on totem and it has been working since the last GStreamer
> release, but after the last GStreamer update I can't query the duration after
> receiving the GST_MESSAGE_DURATION in the bus anymore and I have to do it in
> the READY to PAUSED transition. (This happens on Windows XP, I'll try later on
> linux, but I don't think it will happen since many people should have tested
> totem with the last GStreamer release :P)

It's possible that the duration message is now emitted earlier. That is no problem as long as you don't use the duration message as the signal that it's safe to query the duration.

> If this is not the expected behavior why does totem relies on it  and even
> prints a debug message when this happens?
> http://git.gnome.org/browse/totem/tree/src/backend/bacon-video-widget-gst-0.10.c#n2165
> I fixed it in my player with the following patch:
> http://git.gnome.org/browse/longomatch/commit/?id=04d2eaaa9132cc64e5d0ed77508a0a7d1d2bd29d
> 

*after* going to paused, duration messages can be used to trigger a duration query. Before going to PAUSED the duration query will fail. Totem does the right thing, if it gets a duration message, it
tries to query for the duration (but doesn't fail when the query fails). Totem also has a timeout
scheduled to query the duration after PAUSED.

> Can you please confirm that this is not really a bug (maybe playbin2 is posting
> this message too soon or maybe it only happens on windows), and that what is
> done in totem is not the good approach?

As said before, it is not a bug and intended behaviour.
Comment 8 Andoni Morales 2010-03-24 10:17:03 UTC
Thank you very much for the clarification :)