GNOME Bugzilla – Bug 560302
Add GST_TAG_MERGE_REMOVE
Last modified: 2016-05-14 08:25:16 UTC
The usecase is that one wants to implement a e.g. privacy filter and strip certain tags. A pipeline would be something like filesrc ! demuxer ! queue ! muxer ! filesink Right now one would need to listen to GST_MESSAGE_TAG, filter the list manually and then call gst_tag_setter_merge_tags(setter, filteed_tags,GST_TAG_MERGE_REPLACE_ALL); I propose adding GST_TAG_MERGE_REMOVE with the following semantics: merge mode A + B A + !B !A + B !A + !B REPLACE - A - - This way one can do: gst_tag_setter_add_tags (setter, GST_TAG_MERGE_REMOVE, GST_TAG_TITLE,NULL, GST_TAG_DURATION, GST_CLOCK_TIME_NONE, NULL); Basically the values don't matter.
What if you want to remove some tags, but also add or change other tags in the same run? I wonder if it wouldn't be nicer to add new API for this 'remove these tags' functionality. That might be more discoverable API-wise, and there wouldn't be that values-don't-matter-but-you-have-to-pass-them-anyway anomaly.
Yeah, though about that too. But if you just want to filter than you just filter. For the mixed use case using REPLACE_ALL is better. But you are right passing values that don't matter sounds hackish.
I'm likely missing something here, but isn't gst_tag_list_remove_tag enough for this?
Thiago, as a application you don't have the taglist of the element. The element merges tags you sent there with the tags the elements receives from upstream and sends that downstream. So right now we can only add tags. But I totally agree with Tim that the proposal in comment #1 is hackish. It would be better to add e.g. gst_tag_setter_remove_tags (setter, first_tag, ...); The above example would become: gst_tag_setter_remove_tags (setter, GST_TAG_TITLE, GST_TAG_DURATION, NULL); Does that look good?
> gst_tag_setter_remove_tags (setter, GST_TAG_TITLE, GST_TAG_DURATION, NULL); > > Does that look good? Looks good to me. How would this work implementation-wise, would you keep an additional remove-list on the setter object via g_object_set_user_data() and then remove those tags at the end of gst_tag_setter_merge_tags()?
I was thinking of 1.) storing them in a list (in the GstTagData) and resolv those when one runs gst_tag_setter_get_tag_list() 2.) apply them to GstTagData->list when calling gst_tag_setter_remove_tags(), basically calling gst_tag_list_remove_tag() foreach tag to delete. Not sure what makes more sense.
(In reply to comment #6) > I was thinking of > > 1.) storing them in a list (in the GstTagData) and resolv those when one runs > gst_tag_setter_get_tag_list() How about adding gst_tag_setter_add/remove_ignore_tag() for this case? GstTagSetter would store a list of tags to be ignored and would discard those. > > 2.) apply them to GstTagData->list when calling gst_tag_setter_remove_tags(), > basically calling gst_tag_list_remove_tag() foreach tag to delete. This sounds more like removing once, if a new one arrives it would be added. > > Not sure what makes more sense.
I think the right thing to do here is to just 'filter the list manually' (for a whitelist) otherwise gst_tag_list_remove_tag() for a blacklist. Let's close this, but please feel free to re-open if you still want it. In 0.10 we used to post tag messages directly to app, and apps would just merge everything, but in 1.x they're passed through the pipeline and posted by the sinks so such filtering is easier for elements in the pipeline.