Hi,
looks like MPEG2 (DVD) is the only thing left not transcoded in realtime on a 4 core pi.
Is there some hardware acceleration improving this?
I can play on Amazon Fire Stick but Chromecast and Smartphones/Tabs seems to have no hardware support as the Plex Windows App not.
Nope. It’s not an X86_64 processor. It doesn’t have Intel QSV.
raspberrypi.stackexchange.com/questions/1919/why-does-the-raspberry-pi-need-a-mpeg-2-licence
Looks like there are several options on the arms, may be just other libs to use for hardware (gpu?) decoding while the 4 cores can do encoding.
It reads like even the 1 core Pi 1 could decode with that licence.
On the PC side you usually use some GPU also and not the Intel Main processor.
Can you assist here?
@iwl said:
raspberrypi.stackexchange.com/questions/1919/why-does-the-raspberry-pi-need-a-mpeg-2-licence
Looks like there are several options on the arms, may be just other libs to use for hardware (gpu?) decoding while the 4 cores can do encoding.
MPEG2 hardware decoding and H264 hardware encoding on any RPi has been known to work for many years and it is supported by ffmpeg with the right userland and compiler flags. That being said, no RPi is officially supported by Plex and there is no Plex build especially tailored to the OMX hardware transcoding pipeline. But feel free to open a feature request [1] 
If the hardware is equivalent to an external GPU, any thoughts of adding support is gated on external GPU support in general (libva - vaapi). The next gate will be customer base versus level of effort required to implement & support.
@ChuckPA said:
@uglymagooIf the hardware is equivalent to an external GPU, any thoughts of adding support is gated on external GPU support in general (libva - vaapi). The next gate will be customer base versus level of effort required to implement & support.
Unfortunately, the hardware support of the RPi is restricted to OpenMAX and there is no libva wrapper at the moment. Additionally, ffmpeg (and so the Plex transcoder) has to be build against the omx libraries.
I suppose PMP utilises also OpenMAX to provide the playback capabilities of the official Raspberry Pi 2 release. So Plex has engineers that are familiar with the OpenMAX pipeline used e.g. in mpv. However, I am afraid the effort to integrate this pipeline into the Plex transcoder is significant … and requires an official RPi 2/3 support B)
There should also be a look to Armbian supporting a wide range of Socs, the Orange Pis are cheaper and the H3 Arms powerfull, just buy some for 3x Dollar in china and try.
A more general approach to the available GPUs on the market is best.
I would start searching for de/encoding libs available and what the say about their hardware support and then do some quick de/encoding chain tests with that libs.
The only PMP I’m familiar with are the Intel flavors they use libva-vaapi.
Not to sound like a hard-axx . Everyone wants hw-transcoding but it’s only available on *nix boxes with Intel CPUs with QSV capability
@ChuckPA said:
@uglymagooThe only PMP I’m familiar with are the Intel flavors they use libva-vaapi.
“Plex Media Player for Embedded Platforms” [1] officially supports the Raspberry Pi 2 (and 3?) and there the OpenMAX backend is used.
Not to sound like a hard-axx . Everyone wants hw-transcoding but it’s only available on *nix boxes with Intel CPUs with QSV capability.
No worries. I am quite sure most users are aware of the significant effort to integrate hardware transcoding into Plex and libva was a great choice.
[1] https://support.plex.tv/articles/208050637-what-are-the-supported-platforms-for-plex-media-player/
@iwl said:
There should also be a look to Armbian supporting a wide range of Socs, the Orange Pis are cheaper and the H3 Arms powerfull, just buy some for 3x Dollar in china and try.
A more general approach to the available GPUs on the market is best.
I would start searching for de/encoding libs available and what the say about their hardware support and then do some quick de/encoding chain tests with that libs.
Plex only supports arm on NAS devices. Before we get Plex to even think about hardware transcoding on arm, we need Plex to officially provide Ubuntu / Debian packages for armhf and arm64. So please do not waste your time 
Sorry to go a little off topic @ChuckPA and @uglymagoo but it’s there any way to specify which render device Plex uses with libva? I have two, /dev/dri/renderD128 and /dev/dri/renderD129 but only D129 has vaapi support but Plex keeps trying to use /dev/dri/renderD128 and fails over to software transcoding but never tries to use /dev/dri/renderD129
Thanks
PMS is hard coded, at present, to look for /dev/dri/renderD128. Whatever magic you might do before PMS starts is up to you >:)
@ChuckPA Bummer, ok thanks for letting me know. I tried renaming and also symlinking but vainfo stopped working when I did that so unfortunately I’ve no idea what magic that might be
You can’t use symlinks with device nodes. 
mknod is what’s needed
@ChuckPA Thank you for pointing me in the right direction, if you know the exact command I need that would be additionally welcome but I will try to figure it otherwise
Update: I used the following to delete and recreate renderD129 as renderD128… mknod -m 0666 dri/renderD128 c 226 129
vainfo unfortunately is throwing an error now so Im looking into that…
libva info: VA-API version 0.39.0
libva info: va_getDriverName() returns -1
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)
vaInitialize failed with error code -1 (unknown libva error),exit
Thanks again for your help
trivial.
man mknod and
[~] # cd /dev/dri
[/dev/dri] # ls -la
total 0
drwxr-xr-x 2 admin administrators 100 2018-01-30 20:45 ./
drwxr-xr-x 20 admin administrators 22480 2018-02-07 08:19 ../
crw------- 1 admin administrators 226, 0 2018-01-30 20:45 card0
crw------- 1 admin administrators 226, 64 2018-01-30 20:45 controlD64
crw------- 1 admin administrators 226, 128 2018-01-30 20:45 renderD128
[/dev/dri] #
226 = Major device number
128 = Minor device number
Therefore, you probably have crw------- 1 admin administrators 226, 129 2018-01-30 20:45 renderD129 ?
yields
To bend that so you can experiment
renderD128 to something elsesudo mknod renderD128 c 226 129 (Minor device 129 named as if minor 128) This breaks all the rules, btwsudo chmod 666 /dev/dri/renderD128Thanks I found an article just after I replied and updated my comment. I basically did what you said but when I ran vainfo again it seems to be broken. I am seeing now if Plex is working though.
Unfortunately it didn’t work and it also didn’t fail over to software transcoding. The Android app just has the loading circle icon but nothing starts. It was worth a try I suppose. Thanks again @ChuckPA
Feb 07, 2018 15:10:23.214 [0x7fd7d77ff700] DEBUG - Codecs: hardware transcoding: testing API vaapi
Feb 07, 2018 15:10:23.215 [0x7fd7d77ff700] ERROR - [FFMPEG] - Failed to initialise VAAPI connection: -1 (unknown libva error).
Feb 07, 2018 15:10:23.215 [0x7fd7d77ff700] DEBUG - Codecs: hardware transcoding: opening hw device failed - probably not supported by this system, error: Input/output error
Feb 07, 2018 15:10:23.215 [0x7fd7d77ff700] DEBUG - Scaled up video bitrate to 114759Kbps based on 4.500000x fudge factor.
You must remember, Plex looks for Intel QSV first and foremost. I have extremely low confidence the equipment you have can adequately mimic Intel’s QSV replies to libva
