Currently Plex really only software decodes on the server and essentially insists that the players be able to hardware decode. While this is an understandable design decision, it seems a bit short sighted as players become more and more powerful while low end devices start becoming powerful enough to be plexservers, but not powerful enough to do transcoding.
a well known codec example that causes problems is VC-1.
One can take a look at the raspberry pi 4 in terms of direction hardware is moving. i.e. they no longer have hardware decode support for VC1 and they tell everyone that the hardware is powerful enough to decode in software.
Or one can take a look at Sony TVs. Those built on the ATV2 platform have geekbench single core scores around 500, while the newer ATV3 platform basically doubles that to 1000+. (for record, the RPi4 is a bit under 1000 for single core). While the ATV2 could not keep up with bluray level VC1 decoding, I have higher hopes for the ATV3 (donât have a TV with it, so canât test directly). I would believe for instance that nvidiaâs shield could software decode VC1 with ease (it has a hardware decoder, but just used for reference as a beefy device)
In addition, even when on can decode on the server, transcoding is by definition a loss of quality (and a waste of electricity if not really needed). Therefore it seems a good design to enable lower cpu servers with higher cpu players is to have an option for software decode, where you might be able to set your player into 3 modes
hardware only - equivalent to today - i.e. only direct play what can be hardware decoded and transcode the rest on server
Smart Mode - prefer hardware decode, but if thereâs no hardware, tries to software decode and if software decode canât keep up, reverts to transcoding on server.
direct play only - this would use hardware or software decoding on player and never transcode on server (this would be the equivalent of playing with kodi or vlc).
Plex supports hardware transcoding on the server, so even an old ass PC can transcode h265 files with the right gpu. Some GPUs support hardware VC1 transcodes, including some of Intelâs iGPU.
As a server owner that will/might be serving files to all sorts of clients, with different support for file types and some bandwidth restrictions if streaming remotely, you would probation be better served to use a tool like handbrake or even Plexâs own optimize function to get your file into a format most players can read, ie. H264 or h265. Which would also be easier to transcode with the right GPUs.
Get clients that support the video files you want. Or use software that does. On a rPi you could use Kodi to stream your files with Plex for Kodi.
I donât argue with points 1 or 2. Itâs not saying that they are wrong, its saying that thereâs a value to be able to software decode. But there is also a value in keeping things in the original format without transcoding
Perhaps thatâs what you are saying in point 3. that there are clients that can direct play with software decode (i.e. Plex for Kodi) and performance will just be bad if they cant keep up?
This has nothing to do with âsoftwareâ versus âhardwareâ decoding.
What you are proposing is to have a player engine on all platforms which behaves like Kodi â i.e. it can play almost anything, as long as the hardware allows it.
However, that is not always possible.
There are technical, legal and financial hurdles in the way.
That being said, there are some important advances being made in player support. If it is possible (with reasonable expense of money and developer time) to extend the native player, it is done.
For instance, a few months ago, this wouldnât have been possible in the mobile Andoid Plex app:
I agree that its not always possible. and I agree its about essentially including ffmpeg (libavcodec) or some other playback engine in the player.
Are there actual legal issues? i.e. whatâs the legal difference between decoding on the server (i.e. using ffmpeg) and decoding on the player?
can you explain what we are looking at in your screenshot? i.e. before dts-hd ma couldnât be direct played, but now its being decoded by the player?)
Some player platforms simply donât allow a software like Kodi or VLC to be installed, which replaces the default media player engine with an own (Typically âSmart TVâ platforms or game consoles).
That is usually part of the developer agreement which one needs to accept, in order to have you app available on that platform and/or the app store.
Thatâs what I meant with âlegalâ issues.
The screen shot shows a video being âdirect-playedâ (i.e. no transcoding on the server at all), even though it has DTS HD-MA audio and subtitles activated.
Iâm not arguing that plex should require it be able to use its own player engine, Iâm saying that it can be valuable on the platforms that it can do it on. (i.e. any android, xbox) and obviously on some platforms it be impossible as no native code (ex: roku)
hence, why I would never phrase it in a way that it would be smart to remove transcode ability from the server, plexâs ability to transcode to player capabilities is fundamental to plex being plex. Iâm just arguing that it be good to expand player capabilities where one can.
Iâd like to add my support for this feature.
It seems I have bought an Android tablet last year (2021 Samsung Tab A7) that has no HEVC hardware decoding support. So all my HEVC movies fail to play in Plex app without server-side transcoding (and my server is too weak to do that).
So the only solution for now is to use an external player like VLC or MX Player, that does use software decoding. But the downside is Plex canât keep track of played episodes/movies etc that way. Would be awesome if the Plex player would try hardware decoding first, and software decoding if that fails. And only resort to server-side transcoding if both fail.
one thins to consider is âthird partyâ plex front ends (namely the kodi front end). Kodi will basically tell plex it can play all codecs and hence plex will directplay them all to it. Either kodi will be able t use hardware decoding on the platform or it will use it software codecs.
In my android device , i have noticed that plex tends to transcode a lot of my content which emby always direct played . Upon further analysis , i found out that plex just doesnât support software decoding âŠ
I have a weak cpu in my host vps . I was using emby on this vps for almost a year with transcoding disabled and never even once had any video failed to direct play . Much of it would direct play using hardware decoding while the rest using software decoding .
Now i have hosted plex on the very same vps and with transcoding disabled , good amount of my content just fails to direct play as there is no software decoding support . Even when i had to forcibly enable transcoding , the performance of { Emby + software decoding ( direct play )} seems way better than {plex + transcoding} . Seemingly so Software decoding is lot less resource intensive than transcoding . This should have been already there by default as software decoding does -
A) Lot lesser strain on the host server cpu ( as software decoding task is totally client sided )
B) Direct plays almost all audio and video codecs
Now i havenât tested this for all clients of plex but it definitely is the case with android client atleast
Iâd like to add that software decoding shouldnât only be added for video, but audio as well. For instance, Emby Android apps support TrueHD (maybe others too) software decoding, whereas Plex Android apps do not.
Thereâs already an existing suggestion thatâs addressing this question/topic. May I suggest you vote/comment in that thread in order to avoid distracting votes?
