After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 779452 - gstplayer: set rate continuously and the position will be wrong.
gstplayer: set rate continuously and the position will be wrong.
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.10.x
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-03-02 06:34 UTC by Lyon
Modified: 2018-11-03 14:05 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Lyon 2017-03-02 06:34:59 UTC
When I tried to set rate immediately after first my first set rate action.

The play position will jump to 0 to play.


Checked  gst_player_set_rate_internal(), It will first call gst_player_get_position()

however, I found that the 2nd time get position return might be zero if the first set_rate (or seek) is not yet finished.

    case PROP_POSITION:{
      gint64 position = 0;

      gst_element_query_position (self->playbin, GST_FORMAT_TIME, &position);
      g_value_set_uint64 (value, position);
      GST_TRACE_OBJECT (self, "Returning position=%" GST_TIME_FORMAT,
          GST_TIME_ARGS (g_value_get_uint64 (value)));
      break;
    }

Actually, the second time when getting the position, gst_element_query_position() return is FALSE means the query is failed. and the position is remain 0 to be got.

That's why after 2nd set rate operation, the play position will jump to 0.

Will it be a possible solution here to using a while loop to check the gst_element_query_position() return TRUE, and set the correct position.
Comment 1 Vincent Penquerc'h 2017-05-29 14:39:40 UTC
It may fail indefinitely if an error happened, etc. Maybe here what's best is return GST_CLOCK_TIME_NONE if the query fails.
Comment 2 Lyon 2017-06-02 09:22:11 UTC
yes, that maybe better to return GST_CLOCK_TIME_NONE.
Comment 3 GStreamer system administrator 2018-11-03 14:05:08 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/526.