[Bug 683010] gst_tag_list_add_value_internal() behaviour for tags with no merge function

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Fri Jul 26 02:42:37 PDT 2013


https://bugzilla.gnome.org/show_bug.cgi?id=683010
  GStreamer | gstreamer (core) | git

--- Comment #12 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2013-07-26 09:42:35 UTC ---
Even ignoring the tone of comment #8 for a moment, I'm not sure whether I agree
with it.

For one, of course we provide an abstraction, and not even a particularly
clever one. It will always be leaky and imperfect, and not be able to express
everything. The same is true for the matroska tagging system (which isn't
"reality" btw, it's just another abstraction).

Secondly, I think it's an illusion that we actually "keep information" if we
just keep all those values around. We have lost the proper context for those
then. What's the point of keeping 10 dates if you don't know what they mean
anymore?

Thirdly, if something gets dropped because of an imperfect abstraction, it
makes sense to have the element that has the most context do the dropping, and
not some other function (though admittedly it would be sufficient if the
element with the most context simply ordered things in a suitable way, knowing
which one would be selected by merge_use_first).

Lastly, it is always possible to put extra information into "extended comments"
in the form key=value if there's no good mapping in the tagging system. This
way you can even preserve them if you remux to the same format.

I think we should look at the examples listed in more detail and decide on a
case-by-case basis whether the best thing is to add more tags (which definitely
makes sense for the dates IMHO), or to express it differently, or to allow
multiple tags in those cases (I'm not saying the NULL merge function is correct
everywhere where it's now, I'm just not sure it makes sense to replace it with
merge_use_first everywhere).

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