[gstreamer-bugs] [Bug 639941] a position query done after EOS with negative playback rate should return 0

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=639941
  GStreamer | gstreamer (core) | unspecified

--- Comment #6 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2011-01-21 09:36:56 UTC ---
IRC log from yesterday:

10:28:17 <wtay> : __tim, do you think that small basesink patch could go in as
well?
10:28:40 <tim>  : wtay_, I was going to ask you about that :)
10:28:51 <wtay> : I think it should
10:28:55 <tim>  : wtay_, it looks harmless
10:29:02 <wtay> : yes
10:29:03 <tim>  : ok, let's do it then
10:29:28 <tim>  : we don't need another pre-release for that, do we?
10:29:47 <wtay> : don't think so
10:31:50 <wtay> : hm, it might not be right when the start is not 0
10:34:52 <philn>: wtay_: start of the segment?
10:35:12 <wtay> : philn-tp, say you play from 1 second to 3 seconds in reverse
10:35:25 <wtay> : philn-tp, the position in EOS is then 1 second and not 0
10:36:45 <wtay> : philn-tp, maybe last = time is better
10:37:14 <philn>: wtay_: ok, trying that here
10:38:18 <wtay> : also those max and min calls should be different for reverse,
I think
10:42:56 <philn>: wtay_: doesn't work :( i play from 0.3 to 0 and position at
EOS is 0.3 seconds
10:43:57 <wtay> : let me see..
10:46:05 <philn>: btw this issue seems to occur with pulsesink only, at least i
couldn't reproduce it with fakesink
10:48:06 <wtay> : philn-tp, it does not make sense.. let me try the testapp
10:50:56 <wtay> : philn-tp, how did you test? seems to work for me
10:56:58 <philn>: wtay_: using that python script i attached in the bug... ok
well something seems wrong in my setup now, i see in the logs the position
query returns 0 indeed with your proposed change
10:57:19 <wtay> : philn-tp, you test app is not very reliable
10:57:39 <wtay> : philn-tp, the easiest is to to to PAUSED, wait for preroll,
then seek with -1 and the go to PLAYING
10:59:43 <philn>: wtay_: hum ok trying that here
11:18:42 <philn>: wtay_: ok figured it out, i was doing the query in the wrong
format... and the conversion to TIME was failing ;)
11:19:11 <philn>: i'll update the patch
11:19:15 <wtay> : philn-tp, it all seems reasonable to me without any patches
11:19:42 <wtay> : philn-tp, but with the patch, a bug in qtdemux is exposed
11:32:24 <philn>: wtay_: well if qtdemux sends a wrong segment it seems normal
that the sink reports a wrong position without the patch no?
11:33:01 <wtay> : philn-tp, it reports a more correct position without the
patch
11:46:49 <philn>: wtay_: so you think that bug is invalid? sorry but i'm
getting lost now
11:48:40 <wtay> : philn-tp, I'm saying that the position reporting can be
improved a little more
11:53:10 <philn>: wtay_: you mean take in account the negative rate with those
MAX / MIN calls?
11:54:42 <wtay> : philn-tp, I think so, haven't looked closely. Also the bin
should aggregate the min of all returned values etc.
11:57:42 <philn>: ok, that sounds like more work indeed :/

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.