After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 324725 - gst_element_set_locked_state() doesn't have effect
gst_element_set_locked_state() doesn't have effect
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.0
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-12-21 18:57 UTC by Akos Maroy
Modified: 2006-05-17 13:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
see the source file demonstrating the problem (1.98 KB, text/plain)
2005-12-21 18:58 UTC, Akos Maroy
Details
sample code showing that setting pads to flushing doesn't solve the problem (3.82 KB, text/plain)
2005-12-27 11:30 UTC, Akos Maroy
Details

Description Akos Maroy 2005-12-21 18:57:01 UTC
according to the documentation, when setting an element to locked state by calling gst_element_set_locked_state(element, TRUE), the state of the element in question should not change, unless explicilty changed.

but unfortunately it seems the above call has no effect on the elements.
Comment 1 Akos Maroy 2005-12-21 18:58:56 UTC
Created attachment 56266 [details]
see the source file demonstrating the problem

in the source file, a simple pipeline is assembled: filesrc ! mad ! audioconver ! alsasink.

before setting the pipeline to PLAYING, the mad element is locked. but despite this lock, it is set into PLAYING state when the pipeline is set to PLAYING.

it should remain in NULL state, because of the lock. but does not.
Comment 2 Wim Taymans 2005-12-21 19:30:14 UTC
Two problems:

1) the debug output is deceiving, the element does not actually change state, we just report success to the caller, which prints that the state changed.

2) pad are initially created in the non-flushing state so that you can stream data to them before they are activated. mad happens to work fine in the NULL state and so this pipeline works fine.

The proper fix is to initialize a newly created pad in the flushing state. It unfortunatly made ghostpads fail right before the 0.10 release, need to reinvestigate.
Comment 3 Akos Maroy 2005-12-27 11:30:31 UTC
Created attachment 56433 [details]
sample code showing that setting pads to flushing doesn't solve the problem

see the sample code that shows that setting pads to flushing mode doesn't solve the problem either.

the sample code contains a { filesrc ! mad ! audioconvert ! alsasink } pipeline. both mad and audioconvert are locked, and their pads are set to flushing.

but this does not prevent the pipeline to play right from the start.

the intended scenario for the sample code would be to stay silent for 2 seconds, and then start to play, when the audioconvert and mad plugins are set into PLAYING state. (before that they are in PAUSED).
Comment 4 Jan Schmidt 2006-01-17 16:58:23 UTC
ping - is this still ongoing?
Comment 5 Akos Maroy 2006-01-17 17:03:47 UTC
AFAIK yes
Comment 6 Wim Taymans 2006-02-14 14:55:45 UTC
in 0.10 elements starts streaming in PAUSED. The PAUSED state only blocks for sinks. If the purpose is to preroll the pipeline, then wait for 2 seconds before starting playback, just do PAUSED, _usleep (2 * seconds), PLAYING. 

Can you explain the use case if there is something else you would like to do?
Comment 7 Akos Maroy 2006-02-14 15:00:32 UTC
sure.

the use case is that I assemble a complex pipeline, with multiple sources. here is one switcher element (not the 'official' one), that selects one from the sources connected to it, and plays that one. from time to time, it selects other sources, and plays from that source.

naturally, all sources should block when not selected. so if source 1 is first selected, then source 2, then back to source 1, it should continue exactly where it left off. (this is contrary to the 'official' switcher element in that it lets all sources flow all the time.
Comment 8 Wim Taymans 2006-02-14 15:29:43 UTC
ok, sounds like gnonlin could be of great help to you.

Other pointers for implementing this: Set the sources to PAUSED, blocking the source pads. Then link/unblock them when needed and block/unlink when not needed anymore.
Comment 9 Akos Maroy 2006-02-14 15:35:29 UTC
I looked at gnonlin, but it seems way over-complicated for me. (or I'm just too dumb :)

as for your suggestion: this is my very problem: even if I set them to PAUSED, they get reset when the whole pipeline is set to PLAYING. this is what locking should prevent from happening, isn't it?

if not, I'd need a kind of locking that would :)
Comment 10 Wim Taymans 2006-02-17 19:46:24 UTC
yes, locking does not change the state of the element when the state of the container changes. so setting an element locked, then to PAUSED, will leave it in paused whatever you do to the state of the parent bin. 

Can this bug be closed?
Comment 11 Akos Maroy 2006-02-18 03:59:15 UTC
I'm not sure if I understand you.

the effect I see is that even though I lock an element, its state _does_ change, for example when changing the state of the parent bin.

you seem to be saying the opposite...
Comment 12 Wim Taymans 2006-02-19 14:40:15 UTC
What effect do you see that makes you believe the state changes regardless of the locked state of the element?
Comment 13 Tim-Philipp Müller 2006-05-17 13:42:54 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!