From activatepush_function, we can see the activation mechanism in gstreamer.

Use activatepush_function in gstrtpjitterbuffer. C to check the activation mechanism in gstreamer.

Related functions: ststst_pad_set_activatepush_function. You can refer to the document part-activation.txt under the DOC/designdirectory in the gstreamer package. This document makes the logic of pad active clearer. First, gstreamer core will call the activate method of pad (if we call the stst_pad_set_activate_function overload). In this method, you must call the ststst_pad_activate_push and ststst_pad_activate_pull to notify gstreamer Core, whether the pad is scheduled in push or pull mode. If the activate function is not reloaded, the default activate function uses the stst_pad_activate_push mode.

OK. Now, let's take a look at the stst_pad_set_activatepush_function and ststst_pad_set_activatepull_function. If the pad is in Push mode, when gstreamer core activates the pad, it will call the activatepush_function of the pad (if set); If the pad is in PULL mode, then, when gstreamer core activates the pad, it will call the activatepull_function of the pad.

For example, in gstrtpjitterbuffer. c, set the chain function for the sink pad and activatepush_function for the SRC pad, this indicates that both sink pad and SRC pad use the push mode (because no activate function is set for any pad, the default setting is used, that is, the push mode ), in this case, the _ chain function is used for data flow (see the in writer's guide scheduling mode chapter. In fact, I think the _ chain function will be called as long as the sink pad is in Push mode, because the PULL mode is set on the SRC pad, which is generally used for downstream element, that is, the sink pad of the downstream element can use the PULL mode ).

OK. Now pipeline is running. First, when gstreamer core initializes and activates elements in the pipeline, it starts from the sink element to the SRC element of the source. If, in turn, SRC is first activated to produce data, and the sink element is not ready yet, which is obviously not suitable. In the activation process of a single element, Src pad is also started first, the same applies to the sink pad. When the sink pad generates data, the SRC pad has ready. Therefore, go back to gstrtpjitterbuffer and check that the SRC pad is activated first. At this time, the activatepush_function is called. In this function, the Code starts a gthread, which will wait for a certain condition, after the condition is signal, it starts to work. Finally, it calls ststst_pad_push to push the buffer to downstream. Then, the sink pad is activated because we didn't set activatepush_function for the sink pad, therefore, use the default logic, that is, the default implementation in gstreamer core.

After both sink and SRC pad are activated, the _ chain function is called. Do not confuse the activatepush_function/activatepull_function and _ chain functions. The first two functions are called only once when the pad is activated, while the _ chain function is always called, because buffer is constantly transmitted from the upstream. If our sink pad is not in Push mode, but in PULL mode, we generally start a ststtask which cyclically reads data from the upstream, in this case, the _ chain function is not required. OK. The _ chain function in gstrtpjitterbuffer. C will check whether the RTP data in the buffer is valid. If it is valid, it will go to signal condition after a series of processing. As we have said before, this condition is the gthread waiting condition started in activatepush_function of SRC pad. After this condition is signal, this gthread starts to work, the main task is to sort the received data in the timestamp order and remove the repeated RTP packet. Finally, gst_pad_push is called to pass the buffer.

The whole process is like this. Therefore, in the _ chain function of gstrtpjitterbuffer. C, we cannot see the code of the stst_pad_push statement, because we have our own definition of the push logic of SRC pad.