This also happen when using a uridecodebin with a "wave" file.

If a "scaletempo" element is in the pipeline the "rate" property has the correct value.

P.S.
I've accidentally submitted before writing all the info

Can you provide a testcase for this?

What element is replying to the SEGMENT query, and are you playing with a different rate than 1.0?

Created attachment 374006 [details]
Simple test, you need to change the pipeline description to point a file

I've done a few test, using different seek types/flags, and I've tried to query multiple elements of the pipeline (and the pipeline), still I get always 1.0 as rate, after changing it.

The playback rate is applied correctly, but cannot be retrieved correctly with  a "new_segment" query.

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.

The first patch only will give you your wanted behaviour, but the second one in addition is more correct.


What are you trying to do exactly with the seeking query?

Created attachment 374009 [details] [review]
wavparse: Implement SEGMENT query

Created attachment 374010 [details] [review]
scaletempo: Implement SEGMENT query

Also note that many elements don't implement the SEEKING query, it's not very reliable.

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).

> 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.

> Also note that many elements don't implement the SEEKING query,
> it's not very reliable.

Really? I think gst-play and totem use the SEEKING query to determine seekability and duration, so it's not some exotic thing that's not implemented by anything. It should really be implemented where missing.

(In reply to Tim-Philipp Müller from comment #9)
> > Also note that many elements don't implement the SEEKING query,
> > it's not very reliable.
> 
> Really?

Typo in that line. Everything in this bug is about the SEGMENT query, not the SEEKING query :)

(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.

Perfect, thanks again :-)

Attachment 374009 [details] pushed as 2415d51 - wavparse: Implement SEGMENT query
Attachment 374010 [details] pushed as a03d294 - scaletempo: Implement SEGMENT query