That kernel creates the /dev/dri/renderD128 inode.
The installer sees it
Plex canât use it,
I already changed the text to be âTranscoding HWâ .
In the release notes for the packaging, I do state itâs possible for the simplistic detection to see something which canât be used. A good example is AMD GPUs.
I could start writing additional code to qualify what it finds before stating itâs viable but decoding CPU info is problematic at best.
The OS / kernel sees it but Plex canât.
There wonât ever be any HW transcoding on a Pi CPU unless there is a real nVidia card plugged in somewhere.
EDIT: I am curious what cat /proc/cpuinfo returns for âmodel nameâ ?
Is this due to a lack of interest? The Raspberry Pi 4 supports hardware decode of H.265 (up to 4K 60 FPS) and H.264 (up to 1080p 60 FPS); and hardware encode of H.264 (up to 1080p 30 FPS). And FFMPEG has direct support for hardware encode on the Pi. My feeling is that it likely could be implemented, given sufficient interest.
The best advantage of the Plex pass is HW transcoding, Considering the number of people having a RPI, it should by a great opportunity for Plex company.
For my personal case, the day when Plex server support HW transcoding, I will buy a Plex pass immediately !
I bought a lifetime Plex pass six years ago⊠best investment ever! I just want to add my voice to this - I replied to the feature request and upvoted it. Figured a reply here endorsing the same couldnât hurt.
Please add HW transcoding support for raspberry pi 4!
If u have not bought plex pass, look else where. By looking at current developments. Plex is not going anywhere. They are not fixing major bug and nothing new as media player server. Just adding thing that nobody wants like free movie. Even closing up the plugins
We did look at accessing the HW transcoding support which exists in some of the ARMv8 CPUs. I was part of the ARMv8 launch effort.
We discovered itâs licensed and prohibitively expensive to obtain that information at this time. Further, the metrics do not support the investment in that segment of the customer base when other areas need the engineering resources much more urgently. Should the usage metric shift and demonstrate a sufficient demand for ARMv8 HW transcoding which justifies the expense and effort, Iâm sure the product and engineering teams will make it happen.
To the point of not fixing major bugs:
We are going as fast as we can. Whatâs important to one person isnât necessarily important to the next. Itâs a no-win scenario. We make some happy while others feel ignored.
posting in the forum unfortunately doesnât upvote the server metrics.
That information is exchanged between PMS and Plex.tv when obtaining codecs.
(Thatâs the only time PMS needs to know which specific binary files to download)
That type of custom help is outside the scope of a support forum.
As for the ARMv8 question at large:
I was on the team which brought ARMv8 support to Plex.
We tried to gain access to the features within the CPU itself so we could provide that capability primarily to the NAS community (Synology and QNAP) and apply through the FFMPEG layer.
If it were possible to also bring broad spectrum HW support to other ARMv8 implementations (such as the hobbyist Pi4 boards) then great.
Because we couldnât get direct hardware access, like Intelâs QSV via libva, the only alternative was a libgtreamer hack which would have been unique to the Pi4.
It wasnât a good solution (as you see). It would take a great deal of work to make viable and bring to production use quality level.
There is insufficient Pi4 user base to justify the expense.
Libgstreamer wouldnât be viable on the other ARMv8 NAS platforms because they donât have any of the required base elements.
It seems the devs perked up some eyebrows and are curious about âexperimentingâ.
This could be good but, until seen in released product, itâs anyoneâs guess (especially mine).
The option you reference isnât used how you think.
FFMPEG upstream comes with codecs embedded. Plex canât do that due to licensing issues. Thereâs been some customization because of codec licensing and that happens to be one of the known flags which was altered.
Maybe they can do something else? I have no idea.
It wasnât so much the possibility of supporting RPi4 as it was the entire ARMv8 NAS community. All those systems would benefit immediately.
