[Bug 797313] wavparse: Not handling SEGMENT query

[GStreamer (GNOME Bugzilla)]

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

--- Comment #11 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Francesco Ceruti from comment #8)
> Thanks :-)
> 
> > With scaletempo it is expected that you get 1.0: rate will be 1.0 and
> > applied_rate will be 2.0, but the segment query only gives you the rate.
> 
> mmh, okay, it's not clear to me where can I get the "applied_rate", plus I
> cannot find reference of this behavior in the scaletempo documentation and
> it's seems related to the wavparse element, this doesn't happen whit other
> decoders (with or without scaletempo in the pipeline).

After the scaletempo patch you'll always get 1.0, it's a bug.

> > What are you trying to do exactly with the seeking query?
> 
> I'm changing the playback position (start_position), stop_position, and
> playback-rate, but using the gst_element_seek() function, that should use a
> GstEvent not a GstQuery, but I don't know to much about how this works
> internally.
> 
> For various reasons the seeks that change the rate and start/stop position
> happens in different parts of the application, and I need to retrieve the
> correct rate to avoid changing it when moving start/stop position.
> 
> Still, if it's not very reliable, I'll change how I handle the things on my
> application to avoid future problems.

I think the most reliable way for this would be to store in your application
what the last effective rate was that you configured via a SEEK event. Or if
you're interested in what the current effective rate is, you could get the
sinkpad of the sink and get the SEGMENT event from it via
gst_pad_get_sticky_event() (but if you just seeked this might still be the old
one). That contains the applied rate and the rate.

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