[Bug 758642] New: Suggestion: new SEEKABLE event and/or message

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 758642
           Summary: Suggestion: new SEEKABLE event and/or message
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: dv at pseudoterminal.org
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

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?

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