[gstreamer-bugs] [Bug 335635] Need an OGG retagging element

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=335635
 GStreamer | gst-plugins-bad | Ver: HEAD CVS





------- Comment #18 from James "Doc" Livingston  2006-05-17 10:15 UTC -------
(In reply to comment #17)
>  - is there a particular reason why you've decided to go for an element
>    that processes and retags a raw vorbis stream rather than one that
>    operates on a raw ogg stream? (both have advantages/disadvantages,
>    I was just wondering what your reasons where or if this has been
>    discussed on IRC or elsewhere before).

I don't think I'd had a real discussion about this with anyone.

My reasoning for operating on vorbis streams rather than Ogg streams was that I
thought it would make it easier to support re-tagging Ogg files that aren't
just a single Vorbis stream.


Applications use the current incarnation of the voristag element by creating a
pipline with "src ! oggdemux    oggmux ! sink" and listening for oggdemux's
pad-added signal. In response to the signal, it would look at the caps and plug
the appropriate tagging element (vorbistag for Vorbis streams) between oggdemux
and oggmux.

I thought that this should work for Ogg files with other (e.g. Speex) streams,
if the appropriate tagging element was written, and maybe for Oggs with
multiple vorbis streams. The above could probably be encapsulated in an
"oggtag" element rather than every application, bonus points if it didn't
hard-code the tagging elements.


>  - if the element is to be implemented as a vorbis stream retagger
>    maybe it should derive from the already existing vorbisparse
>    element? There are extra things to consider, like stream
>    header packets being part of the caps etc.
>    (apologies if all that came up before and was rejected as
>    an idea, I haven't been following this discussion up until now)

Currently vorbistag requries a vorbisparse element before it, to fix all that
up. Deriving from vorbisparse is probably a better idea, I'll look into it.


>  - in the current implementation in gst_vorbis_tag_chain() new_buf
>    should probably be stamped with the same values for timestamp /
>    duration / offset / offset_end etc. as the incoming vorbis
>    comments packet buffer.

I'll look at fixing that too.


-- 
Configure bugmail: http://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.