We currenty do not support multiple tracks with same type in GESPipeline
and we actually need to set the presence field to avoid a scenario where
we have only video in a video track, and no audio in the audio track. So
audiotestsrc is used and we end up encoding the whole audio stream but
no decoded video frame as reached the decodebin src pad, so the pad
has not been created and thus it will not be linked to the encodebin.
On the audio part, the EOS will be emitted so fast that the resulting stream will
not have any video in it as the muxer will not even have a video pad created.
Setting the presence will ensure that the muxer does have a video pad
(because of how encodebin behaves) and thus will create a pad for it
and wait for its EOS.
We actually do not need it has everywhere where we would need it we are
already locked against the timeline.dyn_lock, we need to make sure it is
always the case in the future.
The hierarchy of the mutex was wrong and could possibly lead to
deadlocks
Setting the profile on an encodebin can fail, and if that happens, there
will be no profile set at all, we should return FALSE in GESPipeline
when that happens
