GstStream: Thread-safety concerns and modification/refinement of stream details
@slomo
Submitted by Sebastian Dröge Link to original bug (#777572)
Description
There seem to be two issues with the GstStream API as is currently.
- 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.
- 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?