Add support for forced UDP multicast to RTSP

[GoogleCodeExporter]

I've run into an issue with using LAV filters (0.62) to playback RTSP streams 
where no unicast streams are available - only multicast streams are published 
in the RTSP SETUP response.

These normally will produce an error when using ffplay of "Nonmatching 
transport in server reply" unless the 'rtsp_transport' option is set to 
'udp_multicast'. 

While this can be done with ffplay and ffmpeg there's no way to do this via LAV.

I would like to suggest adding another URL handler to LAV which would force 
this option similar to the way it is done with the AXIS Media Control. They 
have an axrtpm:// handler which forces multicast so rtspm:// could be used for 
LAV to do something similar. Other handlers could also be used to set the other 
'rtsp_transport' options such as TCP and HTTP such as rtspt:// and rtsph:// as 
it's up to the client not the server to select between the available streams.

I'm not sure how difficult this would be but I'm hoping it should be fairly 
straight forward - looking at the source though I'm not sure where to start. 
I'm happy to assist with testing and development if you can give some direction.

Original issue reported on code.google.com by ja...@flit.com.au on 2 Sep 2014 at 1:08

[GoogleCodeExporter]

Looking at this again there may be a simpler solution. Currently ffmpeg allows 
multiple rtsp_transport options to be specified. The documentation states that 
"Multiple lower transport protocols may be specified, in that case they are 
tried one at a time (if the setup of one fails, the next one is tried)." So all 
that would need to be done in LAV is to specify all the rtsp_transport options 
when connecting to RTSP such that multicast can be used if unicast is not 
available. Ideally this ordering could be controlled by the settings dialog but 
initially having it set to udp then udp_multicast then tcp would allow 
non-unicast streams to be played.

https://www.ffmpeg.org/ffmpeg-protocols.html#rtsp

Original comment by ja...@flit.com.au on 3 Sep 2014 at 12:53

[GoogleCodeExporter]

Looks like this may be possible by modifying LAVFDemuxer.cpp at around line 250.
Should be able to introduce the 'rtsp_multicast' option here:

  // demuxer/protocol options
  AVDictionary *options = nullptr;
  av_dict_set(&options, "icy", "1", 0); // request ICY metadata
  av_dict_set(&options, "rtsp_transport", "udp;udp_multicast;tcp;http", 0); 

Hoping to test this out shortly - having trouble building FFMPEG on windows 
using MinGW at the moment.

Original comment by ja...@flit.com.au on 3 Sep 2014 at 7:59

[GoogleCodeExporter]

I didn't have much luck with specifying multiple transport options but I have 
gone with the original idea of adding support for different rtsp:// URL 
handlers to specify the RTSP transport mode (rtspu://, rtspm://, rtspt:// and 
rtsph://) and applied a similar approach to what was done with the icyx:// 
protocol.

This also mimics the approach taken by Microsoft with Media Foundation where 
they also specify rtspt:// and rtspu:// URLs 
(http://msdn.microsoft.com/en-us/library/windows/desktop/aa965244%28v=vs.85%29.a
spx)

See the attached patch for the changes - I've tested this with some multicast 
cameras using the rtspm:// URL and it seems to work well.

Original comment by ja...@flit.com.au on 4 Sep 2014 at 2:31

Attachments:

• rtsp_transport_patch.diff

[GoogleCodeExporter]

On a quick check in the ffmpeg code, I noted that there seems to be an issue in 
the code (or maybe its by design), if you select http as a possible transport, 
its the only mode that will ever be used.

Additionally, it seems that if the value is 0/unset, it should automatically 
try to use all modes (except http), but apparently that doesn't work properly?

I suppose there is no harm in offering the aliases, if that solves the problem. 
Automatically handling that from just the rtsp URL would be nicer of course.

I don't suppose you have a public stream that I can use to test on, which 
currently suffers from the problem?
Or a decent way to reproduce it with a RTSP server I can setup?

Original comment by h.lepp...@gmail.com on 4 Sep 2014 at 7:12

• Changed state: Accepted

[GoogleCodeExporter]

I think the issue of selecting RTSP transport modes is always going to be a 
problem as some cameras offer multiple options (unicast, multicast, tcp) over 
RTSP and it's up to the client to select which transport mode they want to use. 

This is something I've noticed on AXIS cameras as they use the same URL to 
access all the different streaming modes. As a result a player which uses the 
first mode may use unicast and has to be explicitly set to multicast if that's 
what you want. This is what seems to happen with both ffplay and VLC as they 
seem to both automatically pick unicast streams unless forced otherwise.

Unfortunately this particular camera I'm testing only supports multicast and so 
the initial unicast selection fails and the stream doesn't play. I think that's 
where the ffmpeg code falls over as it tries to setup a unicast connection 
initially but receives a multicast response from the test camera (hence a 
nonmatching transport error).

This seems to fairly common based a few threads I've read:
http://ffmpeg.gusari.org/viewtopic.php?f=16&t=774

I have some scripts which use VLC to setup multicast streams from files but VLC 
does not seem to exhibit this behaviour. Strangely enough even when 
multicasting it looks like it responds to a unicast setup request with a 
unicast response - except with a multicast address! 

vlc.exe test.mp4 --sout "#rtp{sdp=rtsp://:554/, dst=239.255.1.2, port=50000, 
ttl=10}" --loop

This is a bit cheeky but I'm assuming it was done for compatibility. In this 
case if you explicitly set "udp" mode in ffmpeg then multicasting from VLC 
works but if you set "udp_multicast" then playback will fail despite 
confirmation of multicast traffic via wireshark. This seems wrong and I don't 
think VLC is doing the right thing here.

Either way I think there's an argument for providing the extra URL prefixes to 
allow the client to choose what transport mode they want to use where multiple 
are available. This seems to be a good thing and would definitely help with 
camera stream compatibility.

Original comment by ja...@flit.com.au on 4 Sep 2014 at 8:13

[GoogleCodeExporter]

This issue was closed by revision d440798f5747.

Original comment by h.lepp...@gmail.com on 6 Sep 2014 at 1:42

• Changed state: Fixed

[GoogleCodeExporter]

I did some modifications to avoid having to use the enum and practically two 
switch blocks, but otherwise applied.

Thanks.

Original comment by h.lepp...@gmail.com on 6 Sep 2014 at 1:42

• Added labels: Component-ffmpeg, Filter-Splitter

[GoogleCodeExporter]

Changes look good. Thanks Hendrik.

Original comment by ja...@flit.com.au on 7 Sep 2014 at 1:18