RTMP parameters: token, pageUrl, swfUrl, etc.

Patch welcome.

These parameters do work and are passed via the URI if you use a version of ffmpeg or libav compiled with librtmp support. However, the builtin rtmp handler used by ffmpeg and libav requires external paramters like -rtmp_live -rtmp_pageurl -rtmp_swfverify and in cases of complex urls other parameters for the -rtmp_tcurl -rtmp_app and -rtmp_playpath, which makes it harder to use as a drop in solution since these parameters are different for each source. i.e. a transcoding script for a upnp server, with librtmp support you can set the parameters as part of the URI to a generic command, without it you would need to create a seperate handler each time you need to use these specific parameters.

The ffmpeg/libav library built from contribs doesn't include librtmp. I'm not familiar with the specifc parts of the licensing, so there may be a conflict since rtmpdump is GPLv2 while VLC is LGPL, it would also depend on gnutls for rtmpe support. If you are able to use it, I can come up with a patch that would include librtmp as part of the contribs and build ffmpeg/libav with it.

Looking into it more while the rtmpdump application is GPLv2, the librtmp component is LGPL. I added a custom rules.mak for rtmpdump to the contribs folder. I also had to modify the ffmpeg/libav rules.mak file to enable librtmp, gnutls to pull in the required libs for rtmp's encryption, and the extra-libs parameter to link to lws2_32 and lwinmm for win32. It's working with both the vlc-2.1 branch and git master. It succesfully built for win32 and I'm using it as we speak on Windows 7 and XP to watch rtmp streams via the vlc active x control with all the required parameters like swfurl and pageurl in the uri.

The next step is to clean up the rules.mak to make it universal with most platforms and test it with linux, Win64 and possibly Mac and Android. For example since ffmpeg/libav upstream refused a patch to fallback on the system's pkg-config binary if there's no cross version present (i.e. the nonexistant i686-w64-mingw32-pkg-config), I also had to include a pkg-config parameter for win32 in the ffmpeg rules.conf so it will detect librtmp and it might be needed for other platforms.

There is no reason to use librtmp, since VLC 2.1.0 has the newest libav, that has all the needed RTMP parameters and support.

Read comment 2, while libav has built in rtmp support, their builtin rtmp support does not support setting parameters like swfUrl and pageUrl via the URI, they can only be set via external parameters. This makes VLC useless for things like a transcoder for a upnp server since you would need a different command for each url as opposed to just dropping the source url in on a predetermined command or with the web plugin which doesn't have an option to set these parameters. When ffmpeg/libav is compiled with librtmp support these parameters can be passed via the URI, with this I can now watch rtmp streams that require a swfUrl and pageUrl via the web plugin and use vlc to transcode these streams with a upnp server like mediatomb.

Replying to [comment:5 kyl416]:

Read comment 2, while libav has built in rtmp support, their builtin rtmp support does not support setting parameters like swfUrl and pageUrl via the URI, they can only be set via external parameters.

So, you can do it with --avio-options.

But if you have a list of the REALLY important ones, we could make a simpler options mapping.

If you use libav's built in rtmp handler, the most important parameters are rtmp_pageurl, rtmp_swfurl, rtmp_swfvfy, and rtmp_live, without them any stream that requires them will not play at all or in the case of swfurl protection it will stop after a few seconds. rtmp_playpath, rtmp_app and rtmp_tcurl are needed for some urls where the values cannot be guessed from the basic rtmp://tcurl/app/playpath format.

However, that won't address the issue of using vlc as transcoder for a upnp server or the web plugin. In order to accomplish that you would need nearly every 3rd party upnp server to modify their software to indicate which avio-parameters need to be set for each url and pass it to the command line. In some cases this would invovle a complete revamp of the upnp server if they have no way of indicating this since the only thing they store for each entry in the database is a title, URI and content-type. With the web plugin, you would need to create a new parameter that allows you to set these options.

What's easier? Getting all the above accomplished, or simply building libav/ffmpeg with librtmp support which takes care of all of this as the unique parameters can now be passed via the URI. Also in the case of the web plugin, it doesn't create any potential security risks that come with letting a web page have control over avio parameters.

Replying to [comment:7 kyl416]:

What's easier? Getting all the above accomplished, or simply building libav/ffmpeg with librtmp support which takes care of all of this as the unique parameters can now be passed via the URI.

Of course not, the avio options are not passed as is.

However, that won't address the issue of using vlc as transcoder for a upnp server or the web plugin. In order to accomplish that you would need nearly every 3rd party upnp server to modify their software to indicate which avio-parameters need to be set for each url and pass it to the command line

First you can pass them as per media options and URI, then you need to pass options anyway.

I fail to see your point.

Most upnp servers do not have that option, they just pass the URI to a preconfigured command line to transcode. They do not have the ability to set any other unqiue options on the fly.

In not so technical terms, it does not require any external avio options to be set like libav's native rtmp handler, all unique options are set via the URI, vlc and libavformat never touch or parse the options since as far as they are concerned it's no different than any other URI. (As opposed to the native rtmp handler where the external avio options would need to be parsed by libavformat at this point) Libavformat sends the rtmp url and the various options to librtmp as if it was one URI, librtmp does its work and sends the flv output to libavformat and the decoding continues down the chain like it would with any other format. Basically multiple urls that wouldn't play at all are now working with my custom vlc with librtmp build including with mediatomb and the web plugin. The only thing that was modified was a new rtmpdump and rules.mak in contribs and a slight modification to rules.mak in the ffmpeg folder. If you fail to see the value in having rtmp urls without requiring --avio-options to be set, especially when it comes to instances listed above where setting this is not an option, I guess there's no convincing you. I'll just finish my work, post the patches on the mailing list and link to it here and let people who want this feature apply the patch and build it themselves and voice their opinions on it.

I just don't see the reason to add yet another dependency, just because of parsing options from URI. (Not to mention that this mapping could be done in the avio module).

How can the mapping be done via the avio module if these are unique to each url and the instances listed above do not allow setting external options like --avio-options?

If you are saying there's a potential way for vlc to parse these parameters as part of a URI then we're on the same page and point me in the right direction so I can focus on that and submit a patch to get that to work. (i.e. if there's any other instances where VLC parses options via the URI or if that function needs to be built from scratch as well) If not, the only way for these issues to be addressed on VLC's end of things is by having libav compiled with librtmp support.

Although having vlc parse these options in the URI opens up another potential issue. For linux many distributions do not use the contribs and instead build with the libav/ffmpeg libraries included in the distribution, many of which are built with librtmp support, so they already handle these urls just fine, which was why I focused on win32. Having vlc strip these parameters from the URI and instead sending them as avio-options before it's sent to libavformat (and thus librtmp) might end up breaking it for them as when libavformat is compiled with librtmp support it disables the native rtmp handlers and errors out when it sees those options.

hi guys.

using --avio-options on windows8 with vlc version 2.1.0 would cause runtime error.

Can't play rtmp stream with param on win8.

	libvlc_instance_t * inst;
	libvlc_media_player_t *mp;
	libvlc_media_t *m;
	libvlc_log_t *log;

	const char *options[] = {
		":avio-options={rtmp_swfurl=http://www.56.com/flashApp/vshow_player.13.04.28.a.swf,rtmp_swfvfy=1,rtmp_live=1}"
	};



	/* Load the VLC engine */
	inst = libvlc_new (0, NULL);

	log = libvlc_log_open (inst);	
	libvlc_set_log_verbosity (inst, 2);
	unsigned int level = libvlc_get_log_verbosity (inst);
	printf ("vlc log verbosity level = %d\n", level);


	m = libvlc_media_new_location (inst, "rtmp://live190.la3.origin.filmon.com:1935/live/198.high.stream");


	//for (int i = 0; i < sizeof(options) / sizeof(options[0]); i++)
	//	libvlc_media_add_option (m, options[i]);

	mp = libvlc_media_player_new_from_media (m);

	libvlc_media_release (m);

	libvlc_media_player_play (mp);

	getchar();
	libvlc_media_player_stop (mp);
	libvlc_media_player_release (mp);
	libvlc_release (inst);
	return 0;

And these code end up with "Using network protocols without global network initialization. Please use avformat_network_init(), this will become mandatory later."

Sorry about my english

Please help me~

changed milestone to %Features paradize

added Type::feature label

RTMP parameters: token, pageUrl, swfUrl, etc.

Child items ...

Activity