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

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Sat Mar 20 04:39:58 PDT 2010


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

Tim-Philipp Müller <t.i.m> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
                 CC|                            |t.i.m at zen.co.uk
     Ever Confirmed|0                           |1

--- Comment #2 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2010-03-20 11:39:51 UTC ---
> 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.

-- 
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.



More information about the Gstreamer-bugs mailing list