ffmpeg: consider --disable-librtmp.
Reason, quoting the Ubuntu ffmpeg package rules file: “ffmpeg has better built-in RTMP support with listen mode”.
Background: for years I’ve been grabbing an rtmp stream off the internet
with VLC and restreamed it on LAN. The relevant input parameters look
like this:
—avio-options \
“{rtmp_swfurl=https://example.com/player.swf,rtmp\_playpath=example\_live,rtmp\_pageurl=https://www.example.com/live/,rtmp\_tcurl=rtmp://example.com/live,rtmp\_app=live,rtmp\_conn=S:OK,rtmp\_flashver=LNX\\2031\\2C0\\2C0\\2C108}”
This did not work on Alpine 3.8.0, whereas on Ubuntu there’s never been a problem. Debugging the issue I found that that not all of the parameters were sent to the server. Specifically swfurl didn’t make it. I then tried various stuff, like deleting parameters. When I took out flashver for example swfurl suddenly was transmitted. But whatever I did, reordering etc., I never arrived at a situation where all parameters were sent out.
I then looked at the Alpine vlc/ffmpeg/librtmp versions, compiled other than the packaged ones, but always with the same result. Basically wasted a lot of time until I had the idea to look at the build configuration of the Ubuntu ffmpeg package. Et voila, there I read the above comment, rebuilt the Alpine package with only this one configuration parameter changed, and everything else being the same things suddenly started to work.
No idea why the packager here chose to enable the external librtmp to begin w/. But, considering this recent experience of mine, looking at package configurations of distributions with large user bases doesn’t seem to be such a bad idea.
(from redmine: issue id 9554, created on 2018-10-14, closed on 2018-10-15)
- Changesets:
- Revision 8d45de8a on 2018-10-15T13:19:03Z:
community/ffmpeg: use built-in RTMP support
Fixes #9554
- Revision 4b616938 on 2018-10-15T13:19:47Z:
community/ffmpeg: use built-in RTMP support
Fixes #9554