[Bug 777572] New: GstStream: Thread-safety concerns and modification/refinement of stream details

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 777572
           Summary: GstStream: Thread-safety concerns and
                    modification/refinement of stream details
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: slomo at coaxion.net
        QA Contact: gstreamer-bugs at lists.freedesktop.org
                CC: bilboed at bilboed.com, thaytan at noraisin.net
     GNOME version: ---

There seem to be two issues with the GstStream API as is currently.

1) Thread-safety

Currently the tags/caps/etc are locked with a mutex, which is good and solves
the problem of one writer and multiple readers. However there could also be
multiple writers according to the documentation (downstream could refine the
information). In this case there is a race condition between getting the e.g.
caps, modifying them and setting new caps. E.g. downstream could be a parser
that is separated from the demuxer with some queue and refines the details from
the demuxer.

2) How to decide when to refine specific details

These are actually a group of similar problems.

Consider the case of a demuxer knowing the resolution of a stream but not much
more, and downstream a parser that adds more information (e.g. profile). Now at
a later time, the resolution of the stream changes. How does the demuxer know
whether it can update the resolution (maybe downstream was setting a more
accurate resolution?), whether it has to remove other fields (they might not be
valid anymore), and especially how would it know which fields were set by
itself and which not (other than always remembering everything everywhere).

Another case, similar, would be a demuxer that first provides generic
information without resolution. Then a parser adds the resolution. Then the
demuxer also knows the resolution from somewhere. How would it decide whether
to update it in the caps or not?

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