GNOME Bugzilla – Bug 766062
player: Provide signalling for when a new URI is started
Last modified: 2016-05-15 12:12:37 UTC
I’m using the gstreamer 1.8 gst-plugins-bad/gst-libs/gst/player/gstplayer api to play some videos on an embedded system. The playback is fine, but I get a strange problem when trying to get the duration of the playback. In particular, I regularly get duration from DURATION_CHANGED event,like follow: --------------------- g_signal_connect(instance->internal_player,"duration-changed", G_CALLBACK(myduration_changed_cb),instance); ..... static void myduration_changed_cb(GstPlayer *p_internal_player,GstClockTime dur, gstreamer_player_t *instance) { if (dur != GST_CLOCK_TIME_NONE) player_event_send(instance->pl_player, PLAYER_EVENT_DURATION_CHANGED, (void *)pl_event_msg_obtain(PLAYER_EVENT_DURATION_CHANGED, (int64_t)NS_TO_MS(dur), -1, NULL)); } ---------------------- My problem is that when I quickly switching URI 3~5 times, the duration value which got from DURATION_CHANGED event was previous duration value. My sequence is following: (1)init gstplayer gstplayer_init () { ........ instance->renderer = gst_player_video_overlay_video_renderer_new(NULL); instance->internal_player = gst_player_new(instance->renderer, NULL); ........ g_signal_connect(instance->internal_player,"duration-changed", G_CALLBACK(myduration_changed_cb),instance); ..... } (2) ........... gst_player_set_uri(instance->internal_player, cur_uri1); gst_player_play(instance->internal_player); (3) ....... gst_player_stop(instance->internal_player); ...... gst_player_set_uri(instance->internal_player, cur_uri2); gst_player_play(instance->internal_player); then ,repeat (2)~(3),just pass to the gst_player_set_uri function's parameters are different. log: --------------------------------- ...... cur_uri1 05-06 09:42:46.084 2323 2375PLAYER_EVENT_DURATION_CHANGED duration = 275458 05-06 09:42:47.139 2323 2375PLAYER_EVENT_DURATION_CHANGED duration = 225666 ... cur_uri2 05-06 09:44:11.659 2323 2375PLAYER_EVENT_DURATION_CHANGED duration = 225666(Obviously this is previous file's duration value) 05-06 09:44:12.764 2323 2375PLAYER_EVENT_DURATION_CHANGED duration = 286208 ... cur_uri3 05-06 09:45:28.759 2323 2375PLAYER_EVENT_DURATION_CHANGED duration = 286208(this is...) 05-06 09:45:29.789 2323 2375PLAYER_EVENT_DURATION_CHANGED duration = 277166 ... cur_uri4 05-06 09:47:31.574 2323 2375PLAYER_EVENT_DURATION_CHANGED duration = 277166(this is ...) 05-06 09:47:33.014 2323 2375PLAYER_EVENT_DURATION_CHANGED duration = 1998007 ---------------------------------- When an anomaly occurs, play each URI my custom <myduration_changed_cb> func 1s interval is called twice, first is gstplayer.c state_changed_cb L1409 emit_duration_changed: check_video_dimensions_changed (self); gst_element_query_duration (self->playbin, GST_FORMAT_TIME, &duration); => emit_duration_changed (self, duration); second is gstplayer.c duration_changed_cb L1487,emit_duration_changed static void duration_changed_cb (G_GNUC_UNUSED GstBus * bus, G_GNUC_UNUSED GstMessage * msg, gpointer user_data) { GstPlayer *self = GST_PLAYER (user_data); gint64 duration; if (gst_element_query_duration (self->playbin, GST_FORMAT_TIME, &duration)) { => emit_duration_changed (self, duration); } } When quickly change URIs, We still get notifications from the old one as it's all asynchronous. Currently there is no explicit signal to know when the next URI has started. http://gstreamer-devel.966125.n4.nabble.com/gstplayer-strange-duration-changed-signal-td4677368.html#a4677379
This could either become a new signal that also gives the URI (uri-started or something, happening even before the first changed state of that URI), or maybe the URI should be part of the state-change signal?
commit 175e02ba7bbf06a34e7d7c8fc5abf712c1c26ded Author: Sebastian Dröge <sebastian@centricular.com> Date: Sun May 15 15:11:10 2016 +0300 player: Add uri-loaded signal that is fired whenever a new URI is actually loaded This allows knowing the "boundary" from which on all following signals are for the new URI. https://bugzilla.gnome.org/show_bug.cgi?id=766062