GNOME Bugzilla – Bug 661634
[0.11] no way to store buffer metadata in tag lists
Last modified: 2011-12-01 18:05:12 UTC
In 0.11, caps are not part of GstBuffer anymore. That is currently a problem for buffers in tag lists, most notably for GST_TAG_IMAGE (also GST_TAG_ATTACHMENT).
Maybe we can we just add GstMeta for it?
No metadata because then we are back to the 0.10 situation where we have caps on the buffers. I would like to have a small buffer context object that contains a buffer and all of the events that define the context of the buffer. This could be a miniobject.
It wouldn't be a GstMetaCaps or something like that but a GstMetaImageTag that contains the caps, the "usage" of the tag (is it a preview image? the front cover?) and other things and it would only be used for image tags. There's the same problem with the last-buffer property on sinks though and that would need to be solved differently then.
I did quite like the idea of caps on buffers. It made a lot of sense, and was self-contained in a way. Maybe we can just add back the possibility of putting caps on buffers, but not use it for negotiation purposes?
I really wanted to avoid putting the caps on buffers because then you could have them being passed in the dataflow with conflicting caps (caps in event != caps on buffer etc). It would also not solve the problem of also retrieving the timing info (useful for appsink) (again putting that in metadata feels wrong). The current implementation uses a small GstSample minobject that wraps a GstBuffer, GstCaps, GstSegment and arbitrary other info in a GstStructure. This structure can be passes around between elements and app and can be put in taglists and returned from appsink etc. It's a bit of a struggle between having a small selfcontained object vs having the flexibility of multiple objects. I think this GstSample makes sense as an object that aggregates state and data.