Plex on Linux(Ubuntu going forward)

Since I got some push back in the other thread and a request to open a separate one, here’s a separate one.

I got this reply int he 16.04LTS/Plex thread:

Ubuntu 16.04 and Fedora 26 are the Linux 'standard' platforms for Hardware Acceleration. Those two distros have the the required kernel capabilities (compile-time drivers) for HW to work. If the CPU and motherboard / BIOS allow the Intel ASIC to be enabled (what it really is inside the CPU/GPU) then the kernel detects it and presents it in /dev.
No Beta OS versions will be supported. Frankly, A. It's subject to change and, by definition, a work in progress and B. Chasing a moving target or phantom 'bug' serves no purpose.

So I’m trying to understand some stuff. The Ubuntu wiki itself says 17.04 and 18.04 both have HW accel out of box, and don’t say anything about 16.04 being the ‘standard’ platform, so I’m not sure how someone would magically just know that. My original question wasn’t quite answered, this is one of those things that I’m not sure how much the change/reverting back to Gnome would affect things like this. So, should HW accel exposed in 18.04 probably still just work? Anyone know?

I wasn’t asking about supporting a beta version in my original question, I don’t know why the response was framed that way. Anyway it seems a relevant question since 18.04 releases tomorrow, and 16.04LTS ends hardware updates this year, so I can’t think of any particular reason I’d want to deploy on 16.04 if I really didn’t have to.

Anyway, so anyone planning on doing a deploy on 18.04? I’m trying to figure out if I wanna bother with this or if I should just deploy with Windows and put up with random reboots.

I’m running a 16.04 and have HW transcoding enabled.

@MasterChiefmas

Would you post the link to my post so I may review again in proper context?

Certainly. Last page of the Linux/Ubuntu 16.04/Intel Nuc thread.

I’ve gotten a little more of a handle on some of the changes. I think I was confusing the impact of Ubuntu changing back from Unity to Gnome, with the impact of changing back from Wayland to Xorg.

However, it looks like the Wayland change happened mainly in v17 releases, and 16.04 was still Xorg, and 18.04 going back to Xorg I think means that there is actually much less to be concerned about then if I was going to a v17 Ubuntu. This seems to make 18.04 much closer to 16.04 then 17 with Wayland was.

Feel free to correct me, but that’s my understanding as it stands now, I didn’t realize I was asking something of a non-question.

MasterChiefmas,
Just to avoid any confusing or getting sidetracked in unnecessary thinking, the level PMS and video operate at is independent of the server. This is because the browser opens the ‘Window’ to be drawn (rendered) in. PMS talks to the Web browser on Linux. The browser, paints a 2D image from its memory (after rendering) to the Xserver. Both Wayland and Xorg handle this trivially. The distinctions really show in applications such as gaming (above 60 fps or 3D modeling & rendering). From the Plex perspective, “However the browser puts it on the glass is up to the browser”.

Now that Ubuntu 18.04 has been released, I am expecting the next update from them to contain a flurry of bug fixes. This is normal with any new release. Not everything can be caught in beta.

From Plex’s perspective Ubuntu 16.04 and Fedora 26 are still the baseline (minimum revision required) OS distributions. Above that, unless dropped in the kernel, is gravy :slight_smile:

To explain how Ubuntu 16, 17 and 18 support HW transcoding is very straight forward.

  1. The kernel itself has a couple ‘driver’ modules compiled in. This is how the kernel can correctly detect and identify the ASIC in the CPU/GPU which gives us Hardware transcoding
  2. Another important module in there is the one which provides the logical device /dev/dri/renderD128. This is what Plex is looking for.
  3. When we see that file (even though it’s a raw device), we talk to it. If everything makes sense, hardware transcoding “activates” and is available. The transcoder does this little “Marco - Polo” handshake for each video stream being transcoded.
  4. We do the transcoding in our memory. When done, we send the image to be displayed out to the browser to paint for you

Does this help explain it better?

Yes, it does, thanks. What I was reading about it made me think that functionality was exposed at the Xorg/Wayland layer, hence my questioning about support. It had seemed like that was one of the motivations for moving to Wayland, getting away from having driver support being compiled into the kernel and into user space. Anyway, I digress into Ubuntu philosophy I’m not well enough versed on. Thanks for the info!