From: Wim T. <wim...@ch...> - 2000-11-22 18:38:19
|
On Wed, 22 Nov 2000 09:57:57 Erik Walthinsen wrote: > I'm working up a list of issues, here's the first set: > > Bins: > > Do we want to generate the plan before or after getting all the children > set? I would think that a plan may be dependent on the prepared state of > the children, so I would vote for after. I'm not sure how the plan would be any different if one of the children failed to set its state, I would guess that if the child failed to set its state, we would be in an error condition. I could however imagine that if a child fails, the plan could be different by not including the child in the pipeline or somesuch, so create_plan should be done after the state change. Anyway, are we going to run this crippled pipeline? So, state change is the most important thing and we might better do it first. > > Does the order matter when setting the children? Currently it follows > the > order they were added, but I think the order should be derived from the > connection order. Which end it should start from I'm not sure. This > begs > the next question. You cannot always know the connection order since some elements will be connected while the pipeline is running, when new pads are created by an element because of the media types, eg. You might also not want to set the state of an element that is not yet connected to any other element because it is not yet needed. The downside of the delayed state change is that it has to be performed at runtime which can introduce serious delays if the element has to perform a complex state change (CORBA connect for example). So generally, I don't think the order should be of any importance. I just can't imagine what we are supposed to do if, for example, the fifth element fails to set its state... The state change of the pipeline either fails or succeeds, it is up to the application to decide what to do with it. I might be wrong here though... > > Do we want to have states travel up or down the pipeline at all? We > could > make this an option, in the form of a special buffer flag that causes the > system to try to set the state of an element before the buffer is pushed > or pulled. This could be useful, but would have a constant drag on > normal > operations even if never used. (this could be mitigated by having single > test for a cluster of such bits, though how many such bits there might be > is questionable) You could also do this without a buffer flag. When an element pushes or pulls a buffer, we could see if the nearby element is in a given state. If it isn't, we change its state. I don't think it is a good idea to atach the state change to a buffer. I would limit the flags on the buffer to be related to media data/events (EOS, DISCONTINUITY, FLUSH, ...). State and quality control should be dealt with seperately, I feel. > > Do we want to simplify the state-change process for elements by having > gst_element_set_state restrict state changes to one level at a time? If > you tell something to go from NULL to PAUSED, it could simply loop > setting > the state to READY, then PLAYING, then PAUSED, each time moving only one > level. This would simplify most element's state handler. Yes. > > How do we deal with failed state changes? Do we revert the entire Bin > back to the state we last attained (the above change would make that more > sane, too). Or do we simply leave things the way they are and return > FAILED? Rollback would be nice, if possible. Can we rollback any element? > > How do we deal with ASYNC returns from state changes? The only place we > use this so far is in the thread code, where a state change requires an > acknowledgement from the thread itself. It's highly broken right now, > since the thread never sets the state. Yes, something is wrong. Actually, the thread does change its state, but not ASYNC as it says with its GstElementStateReturn value and it is not depending on the success of the actual state change of its children, it always succeeds. > My plan was to make use signals, > but the question of context comes up, and thus thread safety. The > general > idea is that the Bin's change_state() will attach a callback to the > change_state signal of the any element that says ASYNC, and keep a count. That will do fine I think. The ASYNC thread state change would currently only happen when going from READY to PLAYING. We should probably change this ASYNC behaviour to the NULL->READY state. so for the threads we have: currently: NULL->READY: create the thread, delay create_plan READY->PLAYING: start the thread (unlock mutex) create_plan and play (ASYNC). better: NULL->READY: create the thread, start the thread, create plan (ASYNC) READY->PLAYING: unlock mutex to start playing This would solve some problem we have right now, mainly the delay introduced by the cleate_plan function. We would also have the thread (really) ready after the NULL->READY state change. It would also be more consistent with the bin doing the create_plan in the NULL->READY state. The READY->PLAYING state change would become pretty fast, and it would be easier to start the threads in sync. > > As they come back changed, the count drops towards zero, then finally the > Bin's state is set. This means locking the count. Does the change_state() return _after_ all the ASYNC replies are received or does it also become an ASYNC element when it has ASYNC elements in it? The programmer has to attach a callback to the bin in this last case, which may be a bit awkward. OTOH, do we really need ASYNC state changes. Technically we can make all state changes blocking. The downside of this is that you cannot change_state() many ASYNC elements in parallel. Just my 0,2 EUR Wim > > > Erik Walthinsen <om...@cs...> - 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 > > _______________________________________________ > gstreamer-devel mailing list > gst...@li... > http://lists.sourceforge.net/mailman/listinfo/gstreamer-devel > -- You're dead, Jim. -- McCoy, "The Tholian Web", stardate unknown |