[gst-devel] sending extra data along with buffers
niej0001 at gmail.com
Wed Jan 16 02:52:25 CET 2008
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.
2008/1/16, Stefan Kost <ensonic at hora-obscura.de>:
> 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
> >> like to store/analyze them later along with the data stream. I tried to
> >> 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,
> >> Attached is my current test. Its a bit hackish and fails. One thing I
> >> wondering is that fakesrc send buffer with caps=NULL. A bug?
> >>From time to time, I've thought about adding something like this
> > 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).
> > the semantics of how to handle the 'extradata' when transforming a
> > 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
> > 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
> > 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
> 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
> 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
> 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
> multiple data-sets identified in a unique way. Elements that can use the
> 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 :)
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gstreamer-devel