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 712645 - Quering basesink with negative rate less then -1.0 returns invalid value
Quering basesink with negative rate less then -1.0 returns invalid value
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.36
Other Linux
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-11-19 00:57 UTC by Dmitri Toubelis
Modified: 2018-05-06 12:07 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dmitri Toubelis 2013-11-19 00:57:17 UTC
I'm working on a player application and it implements the following logic: it stops the pipeline, queries current position and uses the position in the following seek. I noticed that it works fine for most scenarios however, if I do this query when pipeline is playing in reverse with -2.0 or lower rate (-4.0, -8.0, etc.) then the query returns a bizarre value. For example: let's assume that the duration of the stream is 10 and the pipeline is playing on a segment from 3 to 0. If I perform position query at around 2 the query will return 7. I tested the pipeline with a xvimagesink and fakesink - both are exerting the same behavior. I did not have a chance to test this at rate -1.0.

I work with 0.10.36 release of GStreamer but I looked at the commit log in 0.10 branch of the repository and I couldn't see anything that may be relevant to this issue in post release.

I also looked through the source code of gstbasesink.c and this code on lines 4718..4721 looks somewhat suspicious:

    ...
    /* for negative rates we need to count back from the segment
     * duration. */
    if (rate < 0.0)
      time += duration;
    ...

It is hard for me to grasp the entire position querying logic, so I wonder if someone more knowledgeable could look at this issue.
Comment 1 Tim-Philipp Müller 2013-11-24 17:27:01 UTC
Have you checked whether it's still an issue with 1.x ?

Do you have a small test program to reproduce the issue ?
Comment 2 Dmitri Toubelis 2013-11-28 00:50:10 UTC
I haven't checked it with 1.x. The code that I have uses some proprietary components, so I cannot use it as a sample without major reworking.

The simplest way to reproduce it is to use a seekable source connected directly to fakesink, and then do the following:

- play pipeline forward for let's say 10 seconds
- pause and query position (in time units of course)
- play backwards for 3 seconds
- pause and query position

If my assumptions are correct then second time will be around 17 instead of 7.

I think it should be reproducible in python as well. I never used python with GStreamer myself but it looks like a good way to do this test. Unfortunately I will not be able to produce this test myself, so if someone could take a shot at it that would be awesome.
Comment 3 Vivia Nikolaidou 2018-05-06 12:07:25 UTC
GStreamer 0.10 is not supported anymore. Please reopen if this is still the case for 1.x. Closing for now.