[gst-devel] autoplugging and 0.9

[Wim Taymans]

On Fri, 2004-08-06 at 10:31, Benjamin Otte wrote:
> Hi gang,
> 
> As most of you know, I'm currently in the process of writing a new
> autoplugger for GStreamer.
> Today is the day where I've given up doing this with the current GStreamer
> version. It is just not possible given the current way caps work. I'm
> pretty sure this requires quite some core changes to make it possible and
> since I'm not interested in thinking about 100% backwards compatibility,
> I'll just give it up.
> The best way to write an autoplugger with the current system is pretty
> much the same it has been since spider: based on the result of the getcaps
> function when a pad is added. And since spider does that already, I see no
> need to change it.
> 
> If you're convinced you can write a significantly better autoplugger with
> the current core, or are particularly interested in why it doesn't work
> right now, feel free to checkout gst-sandbox/gst-autoplug and try to
> improve it or ask me questions about it.
> 
> Since writing an autoplugger was the last task I wanted to accomplish
> before starting to hack on the next unstable branch and that task is done
> now - this task included tag writing and quite some more stuff, I'll
> probably soon start the next unstable branch. I'm not yet sure what the
> best way to do that would be (if I'll use arch or just branch cvs) and if
> this will result in 0.9, just be a testing ground or can be merged back
> into 0.8.
> 
> The changes I'm going to do include (in no particular order):
> - getting rid of the current scheduling model
> - thread safety
> - changing the caps and nego system to allow autoplugging
> - make the registry work
> - get rid of libxml requirements
> - clean up cruft
> - organize headers into plugins, application and probably other categories
> - use glib 2.4 features (maybe even 2.5) and get rid of stuff like atomic
> code

We at Fluendo are currently redesigning (inbetween real work :) the
issues you address. To avoid the problems we've seen before with
redesigning major subsystems I would suggest to start from a design
document and make the changes incrementally. 

Our design document is not ready for publication yet but it would
explain the design and reasons why a subsystem will be designed in a
specific way. It would also contain a roadmap and verification process
for each milestone.

The current roadmap is, in this order:

- Add return values to push/pull (requires the _get function to have a
different API). The purpose of this will become clear later on, for
example, an element can refuse data if it is not negotiated, or a filter
can refuse data when flushing.

- Redesign negotiation. Is tied to setting up pad connections and
deciding on the transport method (loop/get, loop/chain, ..) 

- redesign EOS/errors in plugins, they should not trigger a state change
(the cause of many deadlocks right now). This will also introduce a
mainloop or message bus for sending errors/EOS to the app/pipeline.

- Redesign state changes, bins just are containers for elements, their
state is what the app has last set.

- design thread safety, mainly for state changes, negotiation and
dataflow. 

- redesign scheduling. Basically get rid of the schedulers or at least
make then very simple, like starting a task (or thread) for each
pipeline entry point.

- Preroll in the PAUSED state, dataflow happens in PAUSED but no clock
is running. Samples block at the renderers. This has the advantage that
the pipeline base time can be set at the exact playback of a sample

- Move events out of the dataflow. 

- Remove GstThread. Threading is implicit now.

The most important part is to make a roadmap, design each feature,
validate it against all use cases and implement it step by step. 
 
After that we can think about the organisational stuff like splitting
headers and moving implementations around.

Wim

> 
> 
> Benjamin
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel