GNOME Bugzilla – Bug 345352
[API] query tag setters (and getters?) for supported tags
Last modified: 2018-11-03 12:12:33 UTC
There is currently no way to find out if a particular pipeline will be able to write out all meta data tags that are passed to it. Meta data can be silently lost currently, for example if an app allows user-supplied backends (to support arbitrary output formats, of which not all might have support for all types of meta data). Another use case applies to using analyzers like TRM (musicbrainz fingerprinting) or ReplayGain. Applications could disable such extra processing if the results cannot be saved in the output. Current state of affairs seems to be that encoders/muxers silently ignore any unsupported tags they encounter during iteration of passed tag lists.
This is interesting. It would also allow to get coverage of the tag-mapping. I would find it interesting for developer if we could produce a chart such as id3demux2 vorbisdec .... GST_TAG_COPYRIGHT COPY xxx GST_TAG_AUTHOR AUTH --- ... to show the implemented mappings. Any ideas for the API?
I had the idea of using filter functions for tag lists. From an application standpoint (like a coverage generator) it would look like this: Merge some tags using gst_tag_setter_{add,merge}_tags as usual. The new behavior of the element would imply that it filters out unsupported tags in the process. The app can then peek at the list with gst_tag_setter_get_tag_list to check which tags got accepted. Elements that have not been updated to the new behavior would be easily identified by feeding a non-existant dummy tag as bait, since they accept anything silently without checking. I don't know how complex or ugly the implementation would have to be, so this idea might be completely cracked after all.
Maybe we could just make the elements emit a GST_MESSAGE_ELEMENT containing the non-handled tags. Maybe we could combine that with some API to gst_tag_setter to emit those messages on its own. Ex : API for elements implementing GstTagSetter: void gst_tag_setter_set_unhandled_tags(.., GstTagList *unhandled); That code would emit a gst_message_new_element ('unhandled-tags', taglist); // The second argument is meant to be a GstStructure, but behold... a GstTagList IS a GstStructure. API for applications: GstTagList *gst_tag_setter_get_unhandled_tags(..);
We have 3 kind of tags: 1) known mapped ones 2) known unmapped ones or new (unmapped) ones - type 1 is fine - type 2 can be caught with the technique outlines in comment #3 So if we want to generate a chart as described in comment #1, we would need: - some way to get all registered tags from gst/gsttaglist.c::__tags hashtable to build a dummy taglist - get all tagsetter elements from registry and send the list to them - get the unhandled tags back -> red - those in the input list that or not in the unhandledlist -> green the red one need to be rechecked from time to time, wheter they can be supported.
Hi,I see that this is a pretty old report but I would like to second this request. I'm using encodebin for an application and I'd like to be able to easily set a tag using a different GST_TAG if the first one the application tries fails (so, for example, if GST_TAG_APPLICATION_NAME is not supported, then set the tag using GST_TAG_ENCODER). It would also make it easier to determine what tags were supported by a given muxer -- right now I can only determine that by trying to set tags and reading the error messages if they fail.
Not that I don't think there are legitimate use cases for this, but the example you give is something I would actively want to discourage. You shouldn't try to get your application into the tags no matter what, just somewhere. If a muxer or tag writer doesn't pick up APPLICATION_NAME you should figure out how to best write that given the format, and maybe file a bug/patch to add that functionality. You shouldn't go and (ab)use similar tags that aren't meant for this just because your primary tag doesn't work :)
What about the second case, then, which is using it to determine whether a tag is supported in the first place?
Sure, not argument there.
(In reply to comment #8) > Sure, not argument there. OK, then :) Thanks for the best-practices tip. I'll be sure not to set fallback tags.
-- 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/5.