[gst-devel] Region struct on cothread data

[Wim Taymans]

On Wed, 29 Nov 2000 09:58:41 Erik Walthinsen wrote:
> I'm a bit confused as to why cothread_[gs]et_data() is used to pass the
> region structure in gstbin.c.  Why not simply drop the pointer into the
> pad?  Pads aren't so common that thowing another pointer into them will
> cause a space problem, but forcing a function call and pthread lookup by
> string for every cothread switch into a Src very well could be a
> performance problem. 

Agreed. 

The problem is however that we use gst_src_push in the loopfunc wrapper and
we really do not know about the pad that was pulled. We might add the data
to the element, but that might fail with multithreading if we are ever
going
to do one src that feeds multiple threads.

If we drop the data into the SRC pad, we still have to loop over all the
SRC 
pads and collect the region information before we can do a
gst_pad_push_region 
on the SRC element. 

This situation would be solved quite easily if we do not use gst_src_push
at
all but use the same method we use for regular elements. At that time we
loop over the pads and we can easily see if we need to push_region or not 
because the pullregionfunc will have attached the info to the pad. Another
reason to remove gst_pad_push or at least not use it in the cothread case?

> 
> I'll leave it for now, but unless there's a good reason to keep it that
> way, I'd be inclined to go change that.

The pthread_gstspecific stuff is not nice at all. I'd be happy if the pad
had some means of storing the pointer.

Wim


-- 
Any given program, when running, is obsolete.