Does PMS has RTMP Proxy support. The reason being is when I was doing some study on RTMP Streams I found RTMPExplorer which basically takes web site URL and transfer the request to internal proxy to find all the information required to get the RTMP Stream including the APP, PLAYPATH, SWF, SWFVERIFY etc...
While this is possible why can't PMS has RTMP proxy initiated to get the same info. If this can be implemented then I believe we may not required to use WebVideoItem for atleast RTMP streams. I understand RTMPE requires DRM encryption key etc and it is not possible to play now anyway in Plex.
I think this will also avoid site confiuration or service configuration for RTMP streams.
You don’t need the RTMP proxy for the RTMP streams to work with PMS. PMS has libRTMP built in since 0.9.5.4 (maybe 0.9.5.3). There are a few caveats though.
1.) You need to do a little homework in advance. Most providers use a single format for the RTMP arguments across all their content so, you only need to figure it once per URL Service/Provider. Then you can programmatically provide the RTMP args to your RTMPVideoURL object as “url”, “clip” and “swf_url”.
2.) The URL Service and(or) Channel need to specify the RealRTMP flag in their respective plist files.
PlexFrameworkFlags
UseRealRTMP
This tells PMS to make use of RTMP transcoding if the client is not capable of direct playing the RTMP streams.
3.) As hinted in 2), the clients must either support direct RTMP playback (only the desktop client does), or make the proper request for RTMP streams to be transcoded. Several clients (but perhaps not all) have been updated to support this. Obviously, as a plugin developer, the capabilities of the Plex Clients are beyond your (and my) control but, the developers in charge of the separate clients are generally aware of these issues and will address them as time permits.
I understand that PMS has lmbRTMP built in. But what I am trying explain is instead of spending time to find the URL, CLIP and SWF details of an RTMP stream. If we have proxy to gather that information when we provide the website url of the video playing then it is easy for developer to build channels for most of the web sites that support direct RTMP. At the same time the args required to play RTMP stream is not unique for all services. Some may require just CLIP, URL, APP and SWF. Some requires additional info like PLAYPATH, swfVRY etc…
If we pass on this to local rtmp proxy then it will gather all this information using video weburl. I believe it is easy for developers to build the channels with out having to spend time on finding these details.
QUICK QUESTION :
What is the difference between RTMPVideoURL and WebVideoItem in PMS. I have noticed big difference between RTMPVideoURL and WebVideoItem in regards to loading the stream even on desktop clients. Obviously, PLEX is not just for playing on desktop. It is used as a media center to play videos on different devices. If it is a direct RTMP and does not require trans-coding then the resources used at system or less and the video streams quickly. I have seen a big difference of playing a channel on desktop VS ROKU. I do not see much difference of playing streams on desktop and ROKU if they are initiated using RTMPVideoURL. But big difference using WebVideoItem ans especially with trans-coding.
I believe if we can play all the RTMP streams using RTMPVideoURL method then we should be able to trans-code them quickly to other devices which does not support the actual video stream format.
I agree, adding in a proxy service like that would definitely make it easier for channel developers. It might be something that the Plex team should look into. Perhaps they have already and decided against it for one reason or another. I don't know. Either way, it seems like a nice feature to have from a channel developer's perspective.
RTMPVideoURL is set up to take RTMP parameters which then are either used for libRTMP to directly grab the stream or played using a plexapp.com-hosted RTMP-player which is then accessed using a standardized site config. The former relies on the points previously mentioned, and the latter is a fallback option for when either the RealRTMP flag is not set or the client does not request a transcoded RTMP stream (like the current aTV client for example).
WebVideoItem is an older function which has been replaced by WebVideoURL. They both take a website URL which matches a site config file and makes use of webkit for PMS to capture and transcode Flash or Silverlight video. Generally we try to only use WebVideo when no direct video or RTMP streams are accessible.
As you noticed, passing a direct RTMP video to a client is much less resource-intensive than transcoding webkit video. That's because when we are able to grab the RTMP stream directly, the end result is usually an MP4 file which most clients can play natively or an flv file which usually only requires remuxing for most clients to play. Whereas, playing webkit video on any client (other than one on the same system as PMS) requires system resources to process the video and audio in the webkit virtual browser window (even though it is usually not displayed), capture the audio and video, then transcode them on the fly into a format which the requesting client will accept. This process is CPU intensive which is why HD video via webkit is often choppy on all but the beefiest setups.
That is the general idea of including libRTMP in PMS. There are still a number of plugins that make use of WebVideo. That can be for one of a few reasons.
[list][*]the RTMP stream uses a handshake which is not currently supported by libRTMP[*]the website uses a streaming method other than rtmp which is not otherwise accessible to PMS[*]no one has gotten around to updating the channel since PMS started using libRTMP[/list]
