GNOME Bugzilla – Bug 758642
Suggestion: new SEEKABLE event and/or message
Last modified: 2018-11-03 12:30:57 UTC
Currently, when one wants to find out if a pipeline is seekable, it is necessary to send out a seeking query, and parse its seekable flag. The problem with this is that it is not always clear when it should be done. In most cases, it should work when the pipeline reaches the PAUSED state, or in case of decodebin, when the pad-added callback is invoked. However, sometimes, this won't work. One example are AIFF files. It is not known until later if the file is actually seekable. The seeking query will therefore fail (which does *not* mean that the file isn't seekable, it means it can't be determined, at least not at that time). So, one has to continually issue the seeking query until it no longer fails. No matter how (by using a timer, or by re-issuing the query before a seek attempt, or in a pad probe every time a buffer passes through for example), the result is suboptimal. For this reason, I think it should be possible for elements to notify the pipeline and application that it is now known if seekable is possible or not. It could send some sort of serialized SEEKABLE event up- and downstream, with one boolean inside, "is seekable yes/no". Somewhere else (in sinks for example), the event could become a message. This way, both elements and the application get the update. Thoughts?
I'd just use the DURATION message for that.
Is it 100% guaranteed that as soon as I get a DURATION message I can actually seek? Isn't it possible that at some point, the duration is known, but the ability to seek isn't? Example: formats where the duration is stored in the header, but seeking only works once some sort of seek table is found, which is placed somewhere beyond the header. If this is streamed over, say, HTTP, it may happen that the duration is known instantly, but the table isn't.
No, it's not guaranteed. It just tells you to update duration and/or seekability/seekable-range. Even in your hypothetical scenario, seekability doesn't really depend on the actual seek table having been read, and it might not be read until a seek is actually requested. It's even possible that a stream was advertised to be seekable, but then turns out not to be when you try. There's never a 100% guarantee.
Which is another reason for such an event/message. The parser/demuxer which does the seeking is the component which knows best about whether or not seeking is (currently) possible. Everywhere else you are left guessing.
It also doesn't necessarily know, e.g. seekability might depend on the upstream source (say an http server) but when you actually try to seek it might turn out not to work after all, just as an example. FWIW, in 0.10 we had the duration value in the duration message, we then removed that in favour of just letting the app query again (also since the value might be outdated by the time the app gets the message).
the duration isn't something reliable. You could very well have a "live" stream with a duration but which isn't seekable. We already have a query to figure out if something is seekable (the SEEKING QUERY). The problem is figuring out the "reliable" time when to do that. The reliable time is when the parse/demuxer has enough information. The nice side effect of the new streams API is that the stream collection *is* posted on the bus by such elements when they have enough information. So you can do your seeking query at that time and the resulting seekable flag value will be the correct one. Can we close this then ?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/141.