GNOME Bugzilla – Bug 613567
Cannot query stream duration in playbin2 when GST_MESSAGE_DURATION appears on the bus.
Last modified: 2010-03-24 10:17:03 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)
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).
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.
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.
Well, not everything is OK. The player is in the "ready" state, when the duration message appears.
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.
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?
(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.
Thank you very much for the clarification :)