GNOME Bugzilla – Bug 777662
GstStream: Stream type/flags setters seem like a bad idea
Last modified: 2017-02-08 17:59:40 UTC
Currently there are setters for caps and tags, which makes sense, and for stream type and flags. The latter don't seem like a good idea to me. Whenever that part of a stream changes, it would seem like a change to a completely different stream (i.e. new GstStream, stream collection, etc). Is there any use case where changing the type/flags could make change, or should we deprecate those setters?
I remember I raised these explicitly at the time as well, and there was some reasonable explanation/use case for it. I think basically a demuxer might create a stream object but fill in type etc. at a later time, but still before it gets announced. Maybe there should be some kind of sealing.
Yes, it's indeed to avoid storing information in multiple places and use the GstStream object to store all stream-related information in the creator *before* the stream object is sent. A simple solution to this would be to make it writable only if the refcount is one (i.e. by the sole owner). An alternative would be to make it copy-on-write (i.e. if the refcount is greater than one a copy is returned).
(In reply to Edward Hervey from comment #2) > Yes, it's indeed to avoid storing information in multiple places and use the > GstStream object to store all stream-related information in the creator > *before* the stream object is sent. > > A simple solution to this would be to make it writable only if the refcount > is one (i.e. by the sole owner). An alternative would be to make it > copy-on-write (i.e. if the refcount is greater than one a copy is returned). That's not so simple, because bindings :) If the intention is to make it write-only after sending, just make it "seal'able" via a flag or boolean.
The use case for these is e.g. a filesrc that creates the stream but does not know anything about it yet, but later elements might add/specialize things.