If we have more than one dynamic payloader in the pipeline, we need
to wait until the *last* one emits 'no-more-pads' before switching
to PREPARED.
Failure to do so would result in a race where some of the streams
wouldn't properly be prepared
https://bugzilla.gnome.org/show_bug.cgi?id=769521
The initial pipeline does not contain specific transport
elements. The receiver and the sender parts are added
after PLAY.
If the media is shared, the streams are dynamically
reconfigured after each PLAY.
https://bugzilla.gnome.org/show_bug.cgi?id=788340
Removed port allocation test from the media suite.
The port allocation failure is now in the stream suite.
rtspserver:
Make sure that the media is suspended after the DESCRIBE request
before reconfiguring the UDP sinks.
rtspclientsink:
In the RECORD case we have to set async property to false
for the appsink element in the test in order to make sure
that the media pipeline doesn't hang in start_preroll().
https://bugzilla.gnome.org/show_bug.cgi?id=757488
In this test we simulate a dynamic pad by watching the caps event.
Because of renegotiation in the base payloader now, this caps is sent
multiple times but we can only deal with 1 invocation, use a variable to
only 'add and remove' the pad once.
Add support for different suspend modes. The stream is suspended right after
producing the SDP and after PAUSE. Different suspend modes are available that
affect the state of the pipeline. NONE leaves the pipeline state unchanged and
is the current and old behaviour, PAUSE will set the pipeline to the PAUSED
state and RESET will bring the pipeline to the NULL state.
A stream is also unsuspended when it goes back to PLAYING, for RESET streams,
this means that the pipeline needs to be prerolled again.
Base on patches by Ognyan Tonchev <ognyan@axis.com>
See https://bugzilla.gnome.org/show_bug.cgi?id=711257
