[gst-devel] Region struct on cothread data

[Erik Walthinsen]

On Wed, 29 Nov 2000, Wim Taymans wrote:

> 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. 
As far as a single Src spanning multiple threads, I agree that we want to
keep the core library from having to do anything to maintain thread 
safety.  Though we are going to have to do a complete review of any code
that gets near threads to make sure we aren't overlooking a potential
killer.

Then again, I want to do a complete code review soon anyway.  Maybe review
the 0.1.0 release and put out any resulting changes as 0.1.1.

> 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'd vote for removing pushregion, in favor of similar functionality in the
pads (i.e. pullregion).  Then we have the following scenarios:

1a) _push chained
1b) _push cothreaded
2a) _pullfunc chained
2b) _pullfunc cothreaded
3a) _pullregionfunc chained
3b) _pullregionfunc cothreaded

2 and 3 are just special cases, where we can use a pointer in the pad to
determine which we call.  It doesn't really make sense to have a
_pushregion anyway, if you think about it.  In the single-pad case, the
downstream element is going to be responsible for asking for a specific
region, so conceptually it's pull()ing anyway.  In the multi-pad case,
what does the region mean anyway?

One of my original ideas was to enable the region to encode more than just
offset/length.  I'd like to enable it to do time or space based requests
as well.  I'm not sure what the timestamping and clocking system looks
like right now, so I don't know what that entails, but it shouldn't be too
hard.

The way this would typically work is the decoder would be handed a
timestamp via an argument or something, it would pullregion with that
timestamp from the parser.  The parser would use some algorithm or
internal cache to translate that to a byte offset, and pullregion from the
disksrc.

         Erik Walthinsen <omega at cse.ogi.edu> - Staff Programmer @ OGI
        Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/
   Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/
        __
       /  \             SEUL: Simple End-User Linux - http://www.seul.org/
      |    | M E G A           Helping Linux become THE choice
      _\  /_                          for the home or office user