Skip to content

tags: better metadata / tag editing API

Submitted by Stefan Kost @ensonic

Link to original bug (#613320)

Description

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.