Fix Gstreamer warning and fix the usage of deprecated functions

[sancane]

Afore mentioned warning can be observed when task function sends stream start events without being sucessful, it assumes that it already has sent the event and then starts sending data buffers. Next pipeline reproduces this case:

gst-launch sctpenc remote-sctp-port=5000 sctp-association-id=1 use-sock-stream=true ! dtlssrtpenc connection-id="c1" ! fakesink videotestsrc ! dtlssrtpdec connection-id="c1" ! sctpdec local-sctp-port=5000 sctp-association-id=1

[sancane]

yes, sure: gst-launch sctpenc remote-sctp-port=5000 sctp-association-id=1 use-sock-stream=true ! dtlssrtpenc connection-id="c1" ! fakesink videotestsrc ! dtlssrtpdec connection-id="c1" ! sctpdec local-sctp-port=5000 sctp-association-id=1

[sancane]

Coming back to the problem. Sticky events are only stored when pad is actived. Somehow it seems there is a race condition with the activiation of the pad and the GstTaskFunction, wich tries to send the event when the mode of the pad is still GST_PAD_MODE_NONE. That's why stream_start is not propagated, because event though it's a sticky events it is not being stored. My patch only let the task progress when it achieves to send the event. That's why the patch solves the problem, perhaps this is just a workaround and it would be better to start the task in the src pad activation function instead of doing it during the GST_STATE_CHANGE_READY_TO_PAUSED state change. Suggestions are more than welcome.

[sdroege]

Yes the code should make sure to activate the pad early enough before sending anything to it. Your patch is working around that bug :)

[sancane]

Ok, I'm gonna make a patch to start/stop the the task when the pad is activated/deactivated instead of doing it during the change of the state of this element.