Created attachment 353190 [details] [review]
stream: Use stream duration as stream-stpo if segment was not configured with a stop

Allowing client to know stream duration when no seeking happened.

Comment on attachment 353190 [details] [review]
stream: Use stream duration as stream-stpo if segment was not configured with a stop

You can use gst_element_query_duration() directly.

The question is what happens with streams where the queried duration is not reliable because it relies on bitrate estimation (such as with VBR audio files, for example) - would that cause players or the server to cut them short if the initial estimate was shorter than the the actual duration?

(In reply to Tim-Philipp Müller from comment #2)
> Comment on attachment 353190 [details] [review] [review]
> stream: Use stream duration as stream-stpo if segment was not configured
> with a stop
> 
> You can use gst_element_query_duration() directly.

Looks like we are supposed to answer the configured stop to me (ie, after a seek it will return the duration of the seek). 

> The question is what happens with streams where the queried duration is not
> reliable because it relies on bitrate estimation (such as with VBR audio
> files, for example) - would that cause players or the server to cut them
> short if the initial estimate was shorter than the the actual duration?

I made some tests and it looks like with GStreamer it would cut on the client (the jitterbuffers sends EOS based on the stream stop it seems) but it does not change anything on gst-rtsp-server fwics.

Not sure what we should do about that, what do you think?

Created attachment 353227 [details] [review]
stream: Use stream duration as stream-stop if segment was not configured with a stop

Allowing client to know stream duration when no seeking happened.

Attachment 353227 [details] pushed as 8b38aa9 - stream: Use stream duration as stream-stop if segment was not configured with a stop