GNOME Bugzilla – Bug 597077
Audio sources don't inform when they lose ability to provide a clock
Last modified: 2009-10-08 11:39:11 UTC
From "gst_message_new_clock_provide" function documentation: "Create a clock provide message. This message is posted whenever an element is ready to provide a clock or lost its ability to provide a clock (maybe because it paused or became EOS)." However, that message is never sent to bus, when some clock-providing element loses its ability to provide a clock (e.g. is put to PAUSED). This causes problems in camerabin: Camerabin contains separate sub-bins for video and image encoding. Videobin contains audio source element. When video recording starts for the first time, camerabin creates videobin, and thus GST_MESSAGE_CLOCK_PROVIDE is sent to bus, and this audio clock is taken into use. However, after video is recorded, videobin is put to READY state, so it should inform that clock isn't usable anymore. Currently this won't happen. GstBin just continues to use this audio clock, since it hasn't received new GST_MESSAGE_CLOCK_PROVIDE message, which would cause bin->clock_dirty flag to be set and thus new clock to be selected.
So elements that provide the clocks should send those messages? Or do you think GstBin should send that message if going to READY?
I tested this a bit by implementing appropriate message sending code to GstBaseAudioSrc's READY->PAUSED and PAUSED->READY state changes. At least it seemed to fix the problem in camerabin, but I don't know if it introduces some regressions. However, now there are redundant CLOCK_PROVIDE messages; one is sent when element (with clocking capabilities) is added/removed to/from bin, and another when this same element changes its state. I think it doesn't matter who sends those messages; it may be GstBin as well.
the CLOCK_PROVIDE message is not so interesting because we don't want to change the clock when we don't have to. The CLOCK_PROVIDE message is only posted and cached by bins when an element is added that could provide a clock. This makes sure that when we go to PLAYING next, a new clock is selected. What's interesting is the CLOCK_LOST message, which should be caught by the application. The CLOCK_LOST message is posted when a clock becomes inactive (for example when removing an audiosink that proviced the clock for the pipeline). It is the application responsability to go back to PAUSED and PLAYING (or do something else). If you are manualy managing the state of the elements in a custom bin, you might have to post provide/lost messages yourself.
(In reply to comment #3) > If you are manualy managing the state of the elements in a custom bin, you > might have to post provide/lost messages yourself. Okay, adding the corresponding message sending mechanism to sub-bin works too. I just wasn't sure who's responsibility it is to handle this kind of situations. If this is the usual policy how clocking is handled in custom bins, then this bug can be considered as resolved.