I am interested in video subregion information. I had plan to add caps to do this. Now you may help to estimate the feasibility of this plan. Adding 5 caps, x, y, subwidth, subheight, first data byte offset in original video. substream tests these caps, if they are zeros, then ignores subregion information. Otherwise we operate subregion according to these information. <div>2008/1/16, Stefan Kost <<a href="mailto:ensonic@hora-obscura.de">ensonic@hora-obscura.de</a>>:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi, Jan Schmidt schrieb: > <quote who="Stefan Kost"> > >> hi, >> >> I am looking for a way to send some private data along with a buffer. >> During data capture I get some metadata about capture settings and I would >> like to store/analyze them later along with the data stream. I tried to add >> a payload item to caps and put a GstBuffer there. But this seems to be >> painful and I am afraid that it will cause renegotiation as the content >> changes for each buffer. Has anyone been doing something similar? >> >> alternative (better approach) seems to be using a buffer subclass, right? >> >> Attached is my current test. Its a bit hackish and fails. One thing I was >> wondering is that fakesrc send buffer with caps=NULL. A bug? >> > >>From time to time, I've thought about adding something like this directly > to GstBuffer, for carrying information whose presence been negotiated in > the caps, but whose content should be allowed to change without > renegotiating. > > Examples: >   * Pan and scan (video subregion) position information >   * interlacing markers (top field, bottom field) >   * theora granulepos, instead of slapping it in the 'offset' field >   * MPEG Decoding timestamps, which we currently never send along. > > My thought was to add a GstStructure to GstBuffer which is allowed to be > NULL. > > Wim has expressed concern that it would cause performance issues, and it > would certainly require extending various bits of GStreamer to support > properly (buffer serialisation/deserialisation in GDP, for example). Also, > the semantics of how to handle the 'extradata' when transforming a buffer > need to be clearly defined, ie the extradata has to be clearly specified > by the caps attached to the buffer, and there needs to be a way for it to > be handled by elements that don't understand the extradata they've been > given. It can't just be a dumping ground in which to place arbitrary data, > or I don't think it can be made to work. > > J. > Maybe some GstTaglist features can help. I am thinking of the merge-modes here. Atleast this is needed when mixing data. No idea how to express constraints that would render the data useless. E.g. muxing two streams removes the 'frame' context from video frames. Thus the muxer would not copy/merge the extra-data to outgoing buffers. I am not so much concerned with performance. In most cases it would not be used. Freeing buffers would need to release the taglst if its not NULL. Copying buffers need to copy it. As we have hierarchical structures now, we could probably require that the producer uses its element name as a root tag. This way the taglist could carry multiple data-sets identified in a unique way. Elements that can use the data need to know the name of the element that created it. I'll think more about it - may be we can use our shiny new wiki to draft it :) Stefan ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. <a href="http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/"> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/</a> _______________________________________________ gstreamer-devel mailing list <a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net </a> <a href="https://lists.sourceforge.net/lists/listinfo/gstreamer-devel">https://lists.sourceforge.net/lists/listinfo/gstreamer-devel</a> </blockquote></div>