[gstreamer-bugs] [Bug 613320] New: API: metadata editing

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=613320
  GStreamer | don't know | unspecified

           Summary: API: metadata editing
    Classification: Desktop
           Product: GStreamer
           Version: unspecified
        OS/Version: All
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: Normal
         Component: don't know
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: ensonic at sonicpulse.de
         QAContact: gstreamer-bugs at lists.sourceforge.net
      GNOME target: ---
     GNOME version: ---


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.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.