JW7 support for RTMP source file via RSS playlist

[pixelchutes]

I may have stumbled upon a bug with JW Player 7.2.4 and RTMP source files in RSS playlists...

I am facing the following error, however it's only occurring on RTMP URLs within an RSS playlist:

Error loading media: File not found

The playlists in question adhere to the RSS Playlist embed documentation for JW 7.

When monitoring the browser console, a 404 error is being thrown. The entire RTMP URL is being incorrectly fetched local to the website domain, and not from the CDN (e.g. Ignoring the RTMP Application Path / streamer)

In the 404 error log, it seems the double slash in the RTMP URL has been converted to a single slash...
e.g:

domain.com/**rtmp:/**xyz.fcod.llnwd.net/a1234/b56/sub.folder/video.mp4

Beyond that, I'm not sure why it is even attempting to load over http(s) when the protocol is explicitly RTMP. I have tried both flash and html5 mode to see if that made a difference, but it is resulting in the same error.

See forum thread for more detail: https://support.jwplayer.com/customer/en/portal/questions/15980772-does-jw7-still-support-rtmp-source-file-via-rss-playlist-

[pixelchutes]

Alex helped to identify this was being caused by type="video/mp4" on the jwplayer:source node:

<jwplayer:source file="rtmp://example.com/vod/mp4:myVideo.mp4" type="video/mp4"/>

Removing the type="video/mp4" declaration did indeed get the video to play. Once the RSS is parsed, the difference can be seen via the API with:

jwplayer().getPlaylist()[0].sources[0].type // rtmp (after) vs. mp4 (before)

However, what I don't understand is why this should be required? It seems like a workaround to a greater issue. This is otherwise completely valid XML. Even the JW example Media RSS shows this approach. The difference? RTMP vs. HTTP.

In summary: Defining type="video/mp4" for MP4 files in your RSS/XML to be served via RTMP will prevent them from ever playing.

Shouldn't we be able to declare our mp4 videos as video/mp4 type in the RSS / XML markup without it breaking the actual RTMP attempt? Should the handling be reworked to ensure RTMP type is set correctly, based on the source:file protocol?

[robwalch]

The player uses either the type or the file extension to determine which provider will load and play the media. Some types like mp4 have flash and html5 providers. RTMP is only supported in Flash and the player does not look at the protocol first to infer the type. It sees an explicit type of video/mp4 or the extension and expects a progressive download. Once down that route, it chokes on the url provided. It's likely the browser changing the url after setting video.src.

[pixelchutes]

With multiple providers for some types (e.g. mp3, mp4) does this model suggest this is the expected behavior (404 error against incorrect domain), that RTMP sourced content should not / can not declare their type via type="..." in the XML? Or is this unexpected behavior?

[robwalch]

It's certainly unexpected and is caused by setting type. This can be fixed here https://github.com/jwplayer/jwplayer/blob/master/src/js/playlist/source.js#L34

or better yet when setting source.type, we should consider the url and run isRTMP and isYoutube, ignoring config type when there is a match:
https://github.com/jwplayer/jwplayer/blob/master/src/js/playlist/source.js#L30

In the mean time I'd remove type from your feed. Do you need it for anything else?

[pixelchutes]

Thanks for confirming @robwalch. I've renamed the attribute in the XML to something that won't conflict for now.

[robwalch]

This issue is being tracked internally (JW7-1782) and is scheduled to be fixed in 7.3.

[pixelchutes]

Fixed by #997. Thanks!