-
Notifications
You must be signed in to change notification settings - Fork 58
Improvements & Additional Features
This is a collection of idea for improvements and additional features. Feel free to contribute.
Real-time load-based balancing has been added but is experimental and is still currently being tested. Here is a screenshot showing a PMS
master
node (top) and two transcoder slave
nodes--one with a single CPU core and the other with a dual core CPU. All three nodes are running in a VM. There are two transcode (encode) jobs running which have automatically been balanced across the two transcode slave
nodes. Notice the load difference between the master
and the two slave
s.
Other possible load balancing options are discussed below.
As transcode requests come in, we simply pick the next slave
from the list. This method is trivial to implement but not necessarily the most efficient. Consider that not all transcode requests are the same--some are direct copy (change of container), which are relatively cheap, whereas some requests involve re-encoding, which is expensive.
If each host has a maximum number of "transcode slots" available, we can send transcode jobs to the same slave
until it has been fully saturated with work before moving on to the next host. This actually suffers from similar limitations as the round-robin approach.
Before deciding which host to delegate a transcode request to, we first check the current (and historical) load for slave
and pick the one with the lowest load. This should lead to better utilization of each transcode slave
.
Each transcode request includes a path to the file that is to be transcoded. Technically, this is done via the -i "/path/to/video.mkv"
flag sent to the transcoder. This requires that each media path on the master
be exported via a network-share to each slave
. This results in increased complexity of transcode slave
configurations. If a new path is added to the master
then every slave
must also be updated to have access to that directory.
One way to get around this issue is to remap the file path to a PMS
HTTP URL. We can easily do this by parsing the -progressurl
flag sent to the transcoder, extract the session ID and then query the master
via the /status/sessions
URL where we can get the HTTP URL to the file.
For example, consider the flag passed to the transcoder
-progressurl http://127.0.0.1:32400/video/:/transcode/session/3yk96eap8cp/progress
The session ID is 3yk96eap8cp
. Before delegating a transcode request to a slave
, on the master
we can query http://127.0.0.1:32400/status/sessions
, parse the XML, looking for the session ID 3yk96eap8cp
, and get a URL like
http://127.0.0.1:32400/library/parts/18392/file.mkv
We can then swap the input from
-i "/path/to/video.mkv"
to
-i "http://127.0.0.1:32400/library/parts/18392/file.mkv"
The requested file can then be streamed directly from the master
to the slave
without having to deal with network shares for the media files.
Update
It looks like the /status/sessions
page is not updated until after the transcoder has started running, therefore this method will not work as outlined above. Another idea is to extract the session ID and then parse the Plex Media Server.log
file and look for the /video/:/transcode/universal/start.m3u8
entry corresponding to the session ID. An example log entry looks like:
Aug 21, 2015 15:18:18 [0x7fa125fff700] DEBUG - Completed: [192.168.0.21:50431] GET /video/:/transcode/universal/start.m3u8?path=http%3A%2F%2F127.0.0.1%3A32400%2Flibrary%2Fmetadata%2F4&mediaIndex=0&partIndex=0&protocol=hls&offset=0&fastSeek=1&directPlay=0&directStream=1&subtitleSize=100&audioBoost=100&maxVideoBitrate=2000&videoQuality=60&videoResolution=1280x720&session=ceocxymly7d&subtitles=burn&Accept-Language=en (4 live) GZIP 8ms 492 bytes 200
where, in the example, the session ID is ceocxymly7d
and the URL can be retrieved by loading the XML at http://127.0.0.1:32400/library/metadata/4
and finding the item corresponding to mediaIndex=0
and partIndex=0
.
A easy way to update server software. For example create a .deb package and host a ppa so users can update from the terminal. When creating a .deb (or other types of files for other distros) package this is also a esay way too install the software
There isn't currently anyway to limit the maximum bitrate that a client can request. If you are sharing with many users, or are hosting on a platform where bandwidth is limited, this can become a serious issue. Since Plex Remote Transcoder
is already intercepting the transcode request, it would be possible to modify the command and introduce the proper flags to limit the maximum bitrate.
Additionally, bitrate limitations could be imposed as a per-user restriction by taking into account the current session and the associated user.