If we have multiple profiles (AVP or AVPF) for a stream, make one m=
line in the SDP for each profile. The client is then supposed to pick
one of the profiles in the SETUP request. Because the m= lines have the
same pt, the client also knows that only 1 option is possible.
Pass the multicast address of the stream in the connection info in the
SDP so that clients try a multicast connection first.
Only allow multicast connections in the test-multicast example. Also
increase the TTL a little.
If client supplied a range check if the range specifies the start point.
If not, then do an accurate seek to the current position. If a start
point was specified do do a key unit seek to make sure the streaming
starts with decodeable frames.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=724611
in gst_rtsp_media_prepare() the thread is not used if media is already
prepared (e.g. media shared) so we want to stop the thread. otherwise, a
leak occurs.
https://bugzilla.gnome.org/show_bug.cgi?id=724182
Ignore streams that can't generate RTP-Info instead of failing.
Don't return the empty string when all streams are unconfigured but
return NULL so that we don't generate and empty RTP-Info header.
Improve docs a little.
Only set the keyframe flag when we modify the start position. The
keyframe flag should probably be ignored when no change is requested but
until we can claim this is all documented properly and all demuxer
implement this, avoid setting the flag.
See also https://bugzilla.gnome.org/show_bug.cgi?id=723075
Add method to create the RTPInfo for a stream-transport.
Add method to create the RTPInfo for all stream-transports in a
session-media.
Use the session-media RTPInfo code in client. This allows us to refactor
another method to link the TCP callbacks.
Implement a vmethod that can be used to configure the media and the
streams based on the current context. Handle the blocksize handling in
the default handler.
See https://bugzilla.gnome.org/show_bug.cgi?id=720667
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
Start live streams in the blocked state and make them preroll using the
messages. This ensure that no data is played by the sink until we explicitly
unblock the stream right before going to PLAYING.
See https://bugzilla.gnome.org/show_bug.cgi?id=711257
