GNOME Bugzilla – Bug 777572
GstStream: Thread-safety concerns and modification/refinement of stream details
Last modified: 2018-11-03 12:38:55 UTC
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?
As discussed at FOSDEM with Edward, the idea here would be that a) demuxer (or other elements that split streams, e.g. h264parse splitting off a CC stream) will create a new GstStream with the same stream-id (plus new collection) whenever something is changing, and sends that downstream b) parsers, decoders, etc are adding their things to the GstStream whenever they know something. While this can cause inconsistencies, the idea is that further downstream elements will always also get the updated stream (via the event), and parallel elements would extract the same information. So it would converge after a short while And elements would never ever use the information from the stream for anything related to how they work, for that the relevant other events are to be used which are always in sync with the current situation at the element.
Also splitting elements (e.g. demuxers) would always create a new collection (without the upstream streams in there!), and put the upstream stream id in there accordingly. Surrounding elements / the application can then accumulate the different collections and build a tree from them.
-- 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/214.