Discussion:
[gstreamer-bugs] [Bug 613567] New: Cannot query stream duration in playbin2 when GST_MESSAGE_DURATION appears on the bus.
"GStreamer" (bugzilla.gnome.org)
2010-03-22 08:17:42 UTC
Permalink
https://bugzilla.gnome.org/show_bug.cgi?id=613567
GStreamer | gstreamer (core) | 0.10.28

Summary: Cannot query stream duration in playbin2 when
GST_MESSAGE_DURATION appears on the bus.
Classification: Desktop
Product: GStreamer
Version: 0.10.28
OS/Version: Windows
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: gstreamer (core)
AssignedTo: gstreamer-***@lists.sourceforge.net
ReportedBy: ***@gmail.com
QAContact: gstreamer-***@lists.sourceforge.net
GNOME target: ---
GNOME version: ---


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)
--
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
"GStreamer" (bugzilla.gnome.org)
2010-03-22 08:56:34 UTC
Permalink
https://bugzilla.gnome.org/show_bug.cgi?id=613567
GStreamer | gstreamer (core) | 0.10.28

Tim-Philipp Müller <t.i.m> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@zen.co.uk

--- Comment #1 from Tim-Philipp Müller <***@zen.co.uk> 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).
--
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
"GStreamer" (bugzilla.gnome.org)
2010-03-22 11:31:56 UTC
Permalink
https://bugzilla.gnome.org/show_bug.cgi?id=613567
GStreamer | gstreamer (core) | 0.10.28

Wim Taymans <wim.taymans> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
CC| |***@gmail.com
Resolution| |NOTABUG

--- Comment #2 from Wim Taymans <***@gmail.com> 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.
--
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
"GStreamer" (bugzilla.gnome.org)
2010-03-22 12:13:41 UTC
Permalink
https://bugzilla.gnome.org/show_bug.cgi?id=613567
GStreamer | gstreamer (core) | 0.10.28

--- Comment #3 from Vladimir <***@gmail.com> 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.
--
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
"GStreamer" (bugzilla.gnome.org)
2010-03-22 12:23:02 UTC
Permalink
https://bugzilla.gnome.org/show_bug.cgi?id=613567
GStreamer | gstreamer (core) | 0.10.28

--- Comment #4 from Vladimir <***@gmail.com> 2010-03-22 12:22:57 UTC ---
Well, not everything is OK. The player is in the "ready" state, when the
duration message appears.
--
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
"GStreamer" (bugzilla.gnome.org)
2010-03-22 12:36:49 UTC
Permalink
https://bugzilla.gnome.org/show_bug.cgi?id=613567
GStreamer | gstreamer (core) | 0.10.28

--- Comment #5 from Tim-Philipp Müller <***@zen.co.uk> 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.
--
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
"GStreamer" (bugzilla.gnome.org)
2010-03-23 22:43:57 UTC
Permalink
https://bugzilla.gnome.org/show_bug.cgi?id=613567
GStreamer | gstreamer (core) | 0.10.28

Andoni Morales <ylatuya> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
CC| |***@gmail.com
Resolution|NOTABUG |

--- Comment #6 from Andoni Morales <***@gmail.com> 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?
--
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
"GStreamer" (bugzilla.gnome.org)
2010-03-24 05:14:53 UTC
Permalink
https://bugzilla.gnome.org/show_bug.cgi?id=613567
GStreamer | gstreamer (core) | 0.10.28

Sebastian Dröge <slomo> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@circular-chaos.org
--
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
"GStreamer" (bugzilla.gnome.org)
2010-03-24 09:43:41 UTC
Permalink
https://bugzilla.gnome.org/show_bug.cgi?id=613567
GStreamer | gstreamer (core) | 0.10.28

Wim Taymans <wim.taymans> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |NOTABUG

--- Comment #7 from Wim Taymans <***@gmail.com> 2010-03-24 09:43:37 UTC ---
(In reply to comment #6)
Post by "GStreamer" (bugzilla.gnome.org)
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.
Post by "GStreamer" (bugzilla.gnome.org)
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.
Post by "GStreamer" (bugzilla.gnome.org)
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
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.
Post by "GStreamer" (bugzilla.gnome.org)
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.
--
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
"GStreamer" (bugzilla.gnome.org)
2010-03-24 10:17:04 UTC
Permalink
https://bugzilla.gnome.org/show_bug.cgi?id=613567
GStreamer | gstreamer (core) | 0.10.28

--- Comment #8 from Andoni Morales <***@gmail.com> 2010-03-24 10:17:03 UTC ---
Thank you very much for the clarification :)
--
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
Loading...