[gstreamer-bugs] [Bug 613320] API: metadata editing
bugzilla at gnome.org
Sat Mar 20 04:39:58 PDT 2010
GStreamer | don't know | unspecified
Tim-Philipp Müller <t.i.m> changed:
What |Removed |Added
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
> 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
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
[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