GNOME Bugzilla – Bug 664720
API: add gst_buffer_{set,get}_qdata()
Last modified: 2011-11-25 23:33:41 UTC
Created attachment 202055 [details] [review] buffer: add gst_buffer_{set,get}_qdata() Allows people/us to attach arbitrary metadata to buffers without creating a subclass, which is handy for all kinds of things. This is on GstBuffer and not GstMiniObject because it only really makes sense with buffers, and because all the conceptual bits of metadata writability and metadata copying are part of GstBuffer. The cost of this should be negligible when not used (just extends the malloc sizeof the buffer object by sizeof(gpointer)). I opted for a private struct instead of just using the reserved field directly so we still have one public pointer left for public things. (gtk-doc Since: markers will be fixed up before commit, obviously)
commit 33078aaeb70a9218242e41fc4b110bd1a1ac7a56 Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Wed Nov 16 01:04:45 2011 +0000 buffer: add gst_buffer_{set,get}_qdata() Allows people/us to attach arbitrary metadata to buffers. https://bugzilla.gnome.org/show_bug.cgi?id=664720 API: gst_buffer_set_qdata() API: get_buffer_get_qdata()
Whouldn't it be easier to use a hashmap with the quark as the key? instead of a slist?
> Whouldn't it be easier to use a hashmap with the quark as the key? instead of a > slist? Didn't really seem worth it given that the normal case is no qdata at all and the next most-likely case is one or at most two pieces of qdata.. But it's an implementation detail anyway, it can be changed later if desired. I don't think it would make a huge difference in terms of lines of code either. (PS: it's a double-linked list, not an slist ;-))
Also for this few elements a hashtable will most likely have more overhead