gstplayer strange duration_changed signal

[lucky chou]

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




--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/gstplayer-strange-duration-changed-signal-tp4677368p4677379.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.