GNOME Bugzilla – Bug 114976
[0.6.3/patch] videotestsrc and xvideosink do not reset their state when going to NULL
Last modified: 2004-12-22 21:47:04 UTC
noticable by running videotestsrc ! colorspace ! xvideosink in the editor and setting to play, pause, play. Watch xvideosink not output anything until the same time as the previous play time has elapsed
Created attachment 17469 [details] [review] fix against 0.6
commited to HEAD and 0.6.2.1, closed
Shouldn't they reset in READY instead of NULL? NULL->READY is the resource allocation phase, READY->PAUSE is the pipeline intialization phase (and on PAUSE->READY, the pipeline data is therefore reset, including time and so on).
yes, the timing information should reset in PAUSED->READY. Also, element parameters should never be reset to their default value, even in READY->NULL transitions.
Created attachment 19339 [details] [review] patch
why shouldn't element data be reset even from READY to NULL ? AFAIK, all plugins going to NULL should behave as if they were freshly created, why is this not the case ?
> why shouldn't element data be reset even from READY to NULL ? Element data, yes. But (writable) parameters should (ideally) never be changed except under the control of the application. Reseting parameters to the default in READY->NULL makes it much more difficult for elements to use the NULL state to free their resources. A good example is osssink -- I don't think that it's a good idea to reset the device parameter every time we want osssink to detach from the device (i.e., every time the user presses pause on a GUI). If an application wants a pristine element, it can create one. I don't see a good reason to support restoring elements to a pristine state. One could probably approximate it by going through all the parameters and calling g_param_value_set_default(), though.
commited to 0.6.2.1, closing.