gstplayer strange duration_changed signal

[rland]

Hi all,
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);
  }
}

So，why does it need to be two emit_duration_changed, what is the difference between the two?
. Is this some kind of bug, or am I missing something?

 
Thanks

[Sebastian Dröge-3]

On Fr, 2016-05-06 at 02:27 -0700, lucky chou wrote:
> Hi all,
> 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:
> [...]

When you quickly change URIs, you can 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, but you can guess that from the
state-changed signal currently.

It might make sense to add a signal for that though (when an URI is
starting). If you think so too, please file a bug at
  https://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer
for that. Thanks!

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com


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

[rland]

That's why I love GStreamer so much, it has a very lively forum.

>When you quickly change URIs, you can 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, but you can guess that from the
>state-changed signal currently.

yes,I think the following code should be such a thought,
but still can't handle the problem accurately, That's because it's all asynchronous...

In gstplayer.c,Line 1382
-------------------------

static void
state_changed_cb (G_GNUC_UNUSED GstBus * bus, GstMessage * msg,
    gpointer user_data)
{
  GstPlayer *self = GST_PLAYER (user_data);
  GstState old_state, new_state, pending_state;

  gst_message_parse_state_changed (msg, &old_state, &new_state, &pending_state);

    ............
    if (old_state == GST_STATE_READY && new_state == GST_STATE_PAUSED
        && pending_state == GST_STATE_VOID_PENDING) {
     .....
      gst_element_query_duration (self->playbin, GST_FORMAT_TIME, &duration);
      emit_duration_changed (self, duration);
    }

    ......
}
--------------------------

>It might make sense to add a signal for that though (when an URI is
>starting). If you think so too, please file a bug at
>  https://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer
>for that.
If there is a signal to be able to accurately handle this(when an URI is
starting), that's the best.

Well, maybe it's a good idea to submit a bug to track this .

Best regards,
chou

[rland]

As mentioned above,
https://bugzilla.gnome.org/show_bug.cgi?id=766062