GNOME Bugzilla – Bug 613320
tags: better metadata / tag editing API
Last modified: 2018-11-03 11:16:21 UTC
GStreamer has no easy to use and efficient api for metadata editing of files. These are the usecases which are not well supported: - add new metadata to a file (tagging) - changing existing metadata in a file (editing) - strippping some (or all) metadata from a file (privacy filter) In-place editing would be fast (no need to rewrite long files), but difficult to achieve with gstreamer and would only cover striping and a subset of editing (new size <= old size). The classic way would be to do filesrc location=a.mp4 ! mp4demux name=d ! queue ! mp4mux name=m ! filesink location=b.mp4 with extra .d ! queue ! .m for each stream. This is cumbersome as one would need to filter/process the tag-events either on each stream or via tagSetter on the muxer. Thus we would like to have remux elements that have same in/out caps. Eventually demuxer code could register remuxers as well and reuse the parsing code. One would run them as below and do an atomic delete and rename upon success. Adding: - filesrc location=a.mp4 ! mp4remux tags-add=tags ! filesink location=b.mp4 - tags is GstTagList of tags to add - go to playing - wait for eos Editing: - tagreadbin uri=file://a.mp4 - wait for tags - edit values - filesrc location=a.mp4 ! mp4remux tags=tags ! filesink location=b.mp4 - tags is GstTagList of tags to set - go to playing - wait for eos Filtering: - filesrc location=a.mp4 ! mp4remux tags-remove=tags ! filesink location=b.mp4 - tags is GList of tags to supress - go to playing - wait for eos One alternative would be also to always supply tags-old=tags1 and tags-new=tags2 - both GstTagLists. Problems: - Remux elements would need to buffer the whole file in memory until they get to a point where no further metadata is in the file. Then the size corrected headers followed by the data can be written. Trailing buffers can be pushed as they are. Does this sound doable? Does it stretch what GStreamer is covering too much? One alternative would be to have a tageditbin, that does the classic pipeline, but manages the internals.
We have elements that do somethig like this already, like vorbistag. My original idea was to have something like that, but nobody implemented it, it just wasn't necessary. I'm also not sure how well this works with those multi-tagged files. How would you want to treat wav-in-id3 or files with 2 id3 tags? How would you treat Ogg (Speex, Flac, Vorbis)? Last but not least, the name remux should probably be reserved for elements that actually do remuxing, i.e. ones used for fixing a broken stream.
> Does this sound doable? Does it stretch what GStreamer is covering too much? I think it's both doable and highly desirable, and also very much within scope. Even simple re-tagging operations are currently a PITA in GStreamer. It would be nice to improve that. Ultimately we'd want some high-level API for this of course, be it a tageditbin or a helper library, so users don't need to worry about the file type and all that, but figuring out how this should work at the lower levels is probably harder. > We have elements that do something like this already, like vorbistag. Even though vorbistag does implement the change-tags-on-the-fly parser approach, it's more of an example of what's wrong with re-tagging in GStreamer at the moment, ie. that you need to use it in combination with oggdemux and oggmux and hand-craft pipelines. A couple of things that should work / be supported IMHO: - in-place editing of tags where possible and supported, depending on uri / permissions / available padding: this does not really fit well into the whole stream approach though (but it's not clear to me that we absolutely have to support a stream-based approach) - minimally invasive tag editing: when we edit tags in container files, we should touch as little as possible and leave the container's original structure intact by default. This excludes a demux ! mux approach to tag editing (but that approach is problematic for other reasons anyway). - nested tags, tagged containers, e.g.: [ID3v2 tag with replaygain info] [ID3v2 tag with tags] [mp3 data] [ID3v1 tag] [ID3v2 tag] [APE tag] [flac data with vorbis comment tag in flac headers] [ID3v2 tag] [m4a quicktime container / data] [Ogg with multiple streames] - per-stream / container-level tag editing for containers I also think that having dedicated 'retag' elements would be best for this purpose (I'd also avoid the term 'remux' here). They could sit alongside the demuxer/muxers and share some of the code base. As Edward noted on IRC, there also interesting applications for elements like this besides re-tagging, e.g. index rewriting, move headers to start of file, etc.
-- 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/gst-plugins-base/issues/30.