[Bug 761439] Backward step operations fails and may lead to negative position value

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=761439

--- Comment #15 from Bastien Nocera <bugzilla at hadess.net> ---
(In reply to Vincent Penquerc'h from comment #14)
> I think this looks wrong:
> 
> 5890	    GST_DEBUG ("Setting playback direction to %s at
> %"G_GINT64_FORMAT"", DIRECTION_STR, cur);
> 5891	    event = gst_event_new_seek (target_rate,
> 5892					GST_FORMAT_TIME, GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_ACCURATE,
> 5893					GST_SEEK_TYPE_SET, forward ? cur : G_GINT64_CONSTANT (0),
> 5894					GST_SEEK_TYPE_SET, forward ? G_GINT64_CONSTANT (0) : cur);
> 5895	    if (gst_element_send_event (bvw->priv->play, event) == FALSE) {
> 5896	      GST_WARNING ("Failed to set playback direction to %s",
> DIRECTION_STR);
> 5897	    } else {
> 5898	      gst_element_get_state (bvw->priv->play, NULL, NULL,
> GST_CLOCK_TIME_NONE);
> 5899	      bvw->priv->rate = target_rate;
> 
> In the seek event, if we're going forward, both start and stop are set, and
> the segment is set from cur to 0. Should it not be from cur to something
> unset ?

You mean passing -1 instead of 0 as the "stop" argument? That's what it throws:
(totem:21224): GStreamer-CRITICAL **: gst_segment_position_from_running_time:
assertion 'segment->format == format' failed

The documentation isn't exactly great explaining what the stop value is, but it
says:
"
For negative rates, playback will start from the newly configured stop position
(if any). If the stop position is updated, it must be different from -1
(GST_CLOCK_TIME_NONE) for negative rates.
"

So 0 looks correct.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.