Any news on GPU transcoding, especially Intel Quick Sync?

Plex Media Server Desktops & Laptops
181

@starbetrayer said:

Bottom line: Quicksync will not be implemented until there is a GPL implementation of it.
Intel is the one at fault, not Plex.

I feel like I’m on a circular post that never ends. I guess what people DO NOT understand is that you can MIX GPL and non GPL code in other projects (FFmpeg itself does this). You need to allow the GPL code to compile without it (no brainer) but you CAN STILL USE IT. You also need to post any modifications as source for the GPL code.

For those that keep saying it’s not GPL or can’t be used in FFmpeg please ignore the obvious that it is indeed already in FFmpeg and they have the distributions available in compiled form. BUT instead show me where SPECIFICALLY in the GPL it says it can’t be use,

I’ve already shown specifically in section 5-7 of the GPL that you can use it and how you handle this. This is no different than the way FFmpeg itself is handling this. Where/what is the issue???

This is no different than the thousands of other GPL software running on windows that make use of Windows DLLs that have no source code available. If you didn’t author it you can’t distribute that part of it and it doesn’t apply to the GPL part of the program. There has never been anything in the GPL that says 100% of the program has to be 100% open source or that you can’t call 3rd party libraries.

182

@cayars said:

@starbetrayer said:

Bottom line: Quicksync will not be implemented until there is a GPL implementation of it.
Intel is the one at fault, not Plex.

I feel like I’m on a circular post that never ends. I guess what people DO NOT understand is that you can MIX GPL and non GPL code in other projects (FFmpeg itself does this). You need to allow the GPL code to compile without it (no brainer) but you CAN STILL USE IT. You also need to post any modifications as source for the GPL code.

For those that keep saying it’s not GPL or can’t be used in FFmpeg please ignore the obvious that it is indeed already in FFmpeg and they have the distributions available in compiled form. BUT instead show me where SPECIFICALLY in the GPL it says it can’t be use,

I’ve already shown specifically in section 5-7 of the GPL that you can use it and how you handle this. This is no different than the way FFmpeg itself is handling this. Where/what is the issue???

This is no different than the thousands of other GPL software running on windows that make use of Windows DLLs that have no source code available. If you didn’t author it you can’t distribute that part of it and it doesn’t apply to the GPL part of the program. There has never been anything in the GPL that says 100% of the program has to be 100% open source or that you can’t call 3rd party libraries.

http://www.gnu.org/licenses/gpl-faq.en.html#GPLIncompatibleLibs

Only the copyright holders for the program can legally release their software under these terms.

Plex is not the copyright holder for FFmpeg.

Edited comment: for windows, you have the system library exception.

183

So what? Copyright has nothing to do with this. This is purely about how to use a mix of GPL and non GPL code together which is permissibly (and also what FFmpeg does).

Again did you read section 5 to 7 telling you what you can do with the GPL code?

184

@cayars said:
So what? Copyright has nothing to do with this. This is purely about how to use a mix of GPL and non GPL code together which is permissibly (and also what FFmpeg does).

Again did you read section 5 to 7 telling you what you can do with the GPL code?

Looks like I am not reaching to you.
Copyright (in the sense that the GPL is a copyright license) has everything to do with this.

Plex is not the copyright holder for FFmpeg.
Only FFmpeg copyright holders can release and distribute a modified version of FFmpeg with non-free librairies, or Plex.inc would have to ask every single copyright holder of FFmpeg for their approval.

Yes, I read the GPL license several times as part of my day-job, so thank you but I know the license and its limitations pretty well.

185

Did it stop? I just got some popcorn out.

186

If the lack of GPL means Plex can’t add QS support, how exactly is Emby doing it? Serious question, not a challenge. Is it simply that Emby has users download the QS-enabled FFmpeg manually?

187

Because they are allowed. It’s only people’s weird interpretation of some wording that is tripping people up.
Go to https://www.ffmpeg.org/download.html and click on download for FFmpeg windows builds and follow it until you get to http://ffmpeg.zeranoe.com/builds/ where you can download the FFmpeg binaries in FULL GPL 3.0 compliance with Quick Sync support. Note, how these binaries are fully GPL 3 compatible but don’t say they are non-distributable. Plex can recompile them the same way while adding there own code provided they make the code available. They can’t however distribute the MFX libraries.

To get past what you think the FFmpeg “copyright” is you have to really understand what code is theirs, what is not, what comes from other libraries, what patents they may or may not have, basically the lineage to get this: http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html (for reference)

FFmpeg uses the libavcodec code which in turn uses the libmfx dispatcher which is open source (same used by VLC and other GPL software). Libav uses the “–enable-libmfx” switch (look familiar???) to build in Quick Sync support.

Libav (some would call it a fork or split of FFmpeg) comes as part of many GNU operating systems which are fully GPL supports Quick Sync. Actually many LINUX builds have distributed this in place of FFmpeg.

FFMpeg uses the libavcodec (and other libs) and command lines to compile this support in but then says it’s not GPL???

FAIL on many levels as they can’t take someone else GPL code, modify it and then call it not GPL compliant. They can’t NOT let you use an operating system GPL dynamic link and call it not GPL. etc, etc.

The split between FFMpeg/Libav has caused some weird stuff. FFmpeg will suck in libav stuff but not always the other way. They each try to not acknowledge the other as being the true “ffmpeg”. Each tries to act like they are the original and the other is the “clone” or the split. This used to be much worse than it is today.

But when you get down to it you can’t suck someone else’s GPL code into your project and then declare parts of it NOT GPL. Doesn’t work like that.

Concerning the “copyright” argument thrown out previously. When it comes to both Libav and FFmpeg this is something of a joke. They are reverse engineering or recreating works of other people and then releasing this under GPL. They may not own it to begin with.

The Libav team comes right out and says this here: https://libav.org/legal/ at the bottom part of the page talking about patents and whatnot. Since FFmpeg uses the Libav libs it applies to them as well even if they don’t come out and say it.

If I were Plex, I’d be much more worried about this than with just incorporating the Quick Sync stuff.

The main point I guess I’d want to make is that even if Plex thought there was a strong case why they couldn’t use FFmpeg’s Quick Sync there are other easy ways to do this.

  1. Quit modifying FFmpeg. Use a wrapper to get most of your changes and use a packaged version of FFmpeg which already has FFmpeg in it like Emby and tons of other program do. This would also allow us to stay up to date with the latest FFmpeg releases instead of getting months behind.
  2. use Libav instead
  3. switch to VideoLan open source projects instead of FFmpeg. VideoLan uses a different license and is much more liberal especially for commercial products. They could also make use of the VLC player which could help solve much of the buffer issues we currently see on many platforms (available on a whole lot of platforms). VLC in itself is worthy of making the jump. Getting the equivalent of a much more liberal (maybe better also) transcoder in the process.

I know I went off on a tangent, especially in this post but if Plex had the will to get us GPU encoding it could have been done by now in many different ways. As Forrest Gump would say “That’s All I Have To Say About That”.

188

There’s a lot of confusion in this thread, so I’m going to clear some of it up here.

Yes, we’re looking into hardware transcoding support, as I’ve said before. It’s not the highest priority we have, but it’s something we take seriously.

The current support for QuickSync in ffmpeg has technical issues (it only supports full-GPU pipelines when no filtering is performed) and legal ones (we can’t distribute the MFX libraries ourselves under GPL, so this would only be useful for Windows users where they’re usually preinstalled). We’ll add support on Windows when those technical issues are resolved, and we’ll add support on Linux when a different mechanism is added that doesn’t use MFX (work on this is being conducted upstream, with our input).

We have no need nor desire to switch the transcoder from GPL to another license.

@cayars said:
FFMpeg uses the libavcodec (and other libs) and command lines to compile this support in but then says it’s not GPL???

I don’t even know what you’re talking about here.

@cayars said:
2. use Libav instead

This doesn’t make any sense. Libav and ffmpeg share the majority of their codebases and use the same licensing structure. There are few features that Libav has that ffmpeg does not (since ffmpeg merges changes from Libav on a regular basis). This doesn’t solve a problem.

@cayars said:
3. switch to VideoLan open source projects instead of FFmpeg.

What? VLC is a media player that uses ffmpeg’s libraries for demuxing and decoding. Sure, it can be used for transcoding, but there’s no significant advantage to doing that over using ffmpeg.c. This doesn’t solve a problem.

Even if we did want to switch to LGPL, we couldn’t, because x264 is licensed under GPL.

@cayars said:
if Plex had the will to get us GPU encoding it could have been done by now in many different ways.

Sorry to disappoint, but we’d rather wait until we can provide a complete solution than rushing to support one specific case (no scaling, no interlacing, no subtitle burning, on Windows only), only to have to replace that code later.

189

Thanks for the response @rcombs

Thank you for clearing up the technical and the legal issue. From the legal perspective this is what we have been talking about and I think you nicely addressed this. I wouldn’t let the MFX libraries hold you up. GPU encoding will be something of high-end/experimental thing when first released. It’s not unreasonable to have the user download/setup this on their own as a prerequisite to using it. I don’t think anyone “chiming” for it would mind this extra step. :slight_smile:

With the libav/libavcodec stuff that you didn’t understand. I was suggestion that anyone go read there license and look at the compile switches and the distribution of compiled programs using mfx. The point was libav allows you to do this (not cloudy like with FFmpeg in this thread). FFmpeg pulls in that libav mfx code then muddies the water for some people with the language which was the confusion in the later part of this thread. But again you cleared this up with your comment about not being able to distribute/install the MFX libraries.

My point was that if it were a “license” issue you could just use Libav instead of FFmpeg for GPU stuff. The command lines will need to get changed regardless of what external program is used. But I as well as everyone else would just as well prefer to stay with FFmpeg. I only brought this up because some people were making it sound like a legal roadblock that doesn’t really exist. Libav didn’t appear to have this “roadblock”.

Concerning VideoLan, it is an organization. They have multiple projects including VLC, VideoLan Movie Creator, DVBlast, x264, x262, x265, multicat, VLMa, libdvdcss, libbluray, libdvbpsi, libaacs, libdvbcsa, biTStream. VLC is just one of the projects. Since there is no “roadblock” then there is also no need to switch transcoders. Using VLC as the player (Windows, MAC, Linux, Android, iOS, web) is a different subject altogether but could make a lot of sense as well since it free to use and super powerful.

Not sure what you meant in the end about one specific case. It’s available on Linux as well as Windows. It can do scaling or re-sizing. Yes it’s true you will not have full filter support in the GPU pipeline. I don’t think anyone is ever going to expect ffmpeg on a chip. Yes it’s very true QuickSync can’t natively do everything FFmpeg can do but it’s a compromise. You use it for what it can do and use the CPU for the things it can’t do.

There are a lot of functions in Plex that could use the current feature set of QuickSync such as Sync, Cloud Sync, Media Optimization and some real-time transcoding. Most of the Sync and MO type functions are suited well for QSV.

But again thanks for you reply which cuts right to the chase and answers a lot of questions.

190

@WhatPlantsCrave said:
If the lack of GPL means Plex can’t add QS support, how exactly is Emby doing it? Serious question, not a challenge. Is it simply that Emby has users download the QS-enabled FFmpeg manually?

GPU Transcoding · MediaBrowser/Emby Wiki · GitHub

You need to propose it as a separate download, and have FFmpeg as LGPL or GPL with the modified license.

191

Emby doesn’t need to do anything with a modified license nor do they or others using FFmpeg for this purpose. They go to http://ffmpeg.zeranoe.com/builds/ and download the current version and package it along with the license info with their product.

Nothing more or less.

Most windows computers will the proper CPI will support QuickSync out of the box. One github pull will do the same for Linux.

192

@rcombs said:
Sorry to disappoint, but we’d rather wait until we can provide a complete solution than rushing to support one specific case (no scaling, no interlacing, no subtitle burning, on Windows only), only to have to replace that code later.

I totally agree. I think the tricks GPU’s uses now are limited. Wish Intel, AMD, and Nvidia came together to bring out some unified way of handling transcoding and other video related functions. Sort of like DirectX for windows, but some sort of new universal API. One hopes as 4k and 265 hits fan, more and more of this will evolve. The programming “cap” has been put into the attic for me. But what about direct support without using anything 3rd party? Sort of like the assembler language direct hardware support? I know that all equals lots of man hours. But just curious is that the issue or is it the fact that the GPU assistance is limited in the functions they offer, such as the ability to burn subtitles and so on?

One final question, what is Qnap doing with the Tanscode Management ? Is that something you guys could tap into easily and support? Again this probably goes back to no support for Windows only or in this case Qnap only point you made. But I am sure others are curious on this as more and more people are getting NAS’s to store their libraries.

I personally don’t mind building a 12 core system for a Plex server but, not everyone has the $ for it.

Ok, thanks… Oh BTW if you are in a starbucks or something and all of the sudden somebody bugs you about transcoding , might be me. :wink: I live in Chicagoland.

193

I don’t get why this hasn’t been implemented. This feature has been requested for ages, just look how far back this thread goes and there were others before it. And they haven’t even addressed the issue. I don’t need lyrics for my music, I don’t need half the crap they keep shoehorning into this software. GPU encoding on the other hand would be easy to implement (the libraries already exist for god’s sake, why not just include them?) and it would make a HUGE difference for a ton of users. It wouldn’t take a freaking Xeon or i7 processor to stream multiple HD movies at once, or to transcode a bluray rip for an off-network client. Suddenly, APUs and i3s would be able to handle WAY more stuff, and a system with a video card would be even better.

The improvement in lower-end hardware being used for servers would be huge, and it would make Plex more appealing to people who can’t afford to have a server rack in their basement. And if I’m not spending $300 on the processor for my server, maybe I can afford to pay $150 for PlexPass features. Just throwing that out there.

Overall, it’s honestly nuts that hardware encoding isn’t supported. If Emby manages to get it working before Plex does, I’m going to use Emby instead.

194

@RedSocks157 said:
I don’t get why this hasn’t been implemented. This feature has been requested for ages, just look how far back this thread goes and there were others before it. And they haven’t even addressed the issue. I don’t need lyrics for my music, I don’t need half the crap they keep shoehorning into this software. GPU encoding on the other hand would be easy to implement (the libraries already exist for god’s sake, why not just include them?) and it would make a HUGE difference for a ton of users. It wouldn’t take a freaking Xeon or i7 processor to stream multiple HD movies at once, or to transcode a bluray rip for an off-network client. Suddenly, APUs and i3s would be able to handle WAY more stuff, and a system with a video card would be even better.

The improvement in lower-end hardware being used for servers would be huge, and it would make Plex more appealing to people who can’t afford to have a server rack in their basement. And if I’m not spending $300 on the processor for my server, maybe I can afford to pay $150 for PlexPass features. Just throwing that out there.

Overall, it’s honestly nuts that hardware encoding isn’t supported. If Emby manages to get it working before Plex does, I’m going to use Emby instead.

Then go use Emby, nobody is retaining you.
If you don’t get why this is not implemented, read the post from rcombs just above.
GPU encoding is not easy to implement contrary to your belief.

I especially love the fact that non-plexpass user is bitching about this, and use the word maybe afford the plex pass if this gets implemented.

195

@RedSocks157 said:
I don’t get why this hasn’t been implemented. This feature has been requested for ages, just look how far back this thread goes and there were others before it. And they haven’t even addressed the issue. I don’t need lyrics for my music, I don’t need half the crap they keep shoehorning into this software. GPU encoding on the other hand would be easy to implement (the libraries already exist for god’s sake, why not just include them?) and it would make a HUGE difference for a ton of users. It wouldn’t take a freaking Xeon or i7 processor to stream multiple HD movies at once, or to transcode a bluray rip for an off-network client. Suddenly, APUs and i3s would be able to handle WAY more stuff, and a system with a video card would be even better.

The improvement in lower-end hardware being used for servers would be huge, and it would make Plex more appealing to people who can’t afford to have a server rack in their basement. And if I’m not spending $300 on the processor for my server, maybe I can afford to pay $150 for PlexPass features. Just throwing that out there.

Overall, it’s honestly nuts that hardware encoding isn’t supported. If Emby manages to get it working before Plex does, I’m going to use Emby instead.

Emby already has this available.

Other than the “easy to implement”, I agree with you. Plex pushes an astonishing number of fringe “features” while major issues go unaddressed and bugs fester in core functions. I’m glad that rcombs addressed this thread and helped to clarify some of the issues. That said, I’d really hate to see QS delayed because of something as simple as requiring customers to download an extra package. My Plex server is Linux based, and it sounds like I won’t be seeing QS support for quite some time. Very frustrating.

196

@starbetrayer said:

@RedSocks157 said:
I don’t get why this hasn’t been implemented. This feature has been requested for ages, just look how far back this thread goes and there were others before it. And they haven’t even addressed the issue. I don’t need lyrics for my music, I don’t need half the crap they keep shoehorning into this software. GPU encoding on the other hand would be easy to implement (the libraries already exist for god’s sake, why not just include them?) and it would make a HUGE difference for a ton of users. It wouldn’t take a freaking Xeon or i7 processor to stream multiple HD movies at once, or to transcode a bluray rip for an off-network client. Suddenly, APUs and i3s would be able to handle WAY more stuff, and a system with a video card would be even better.

The improvement in lower-end hardware being used for servers would be huge, and it would make Plex more appealing to people who can’t afford to have a server rack in their basement. And if I’m not spending $300 on the processor for my server, maybe I can afford to pay $150 for PlexPass features. Just throwing that out there.

Overall, it’s honestly nuts that hardware encoding isn’t supported. If Emby manages to get it working before Plex does, I’m going to use Emby instead.

Then go use Emby, nobody is retaining you.
If you don’t get why this is not implemented, read the post from rcombs just above.
GPU encoding is not easy to implement contrary to your belief.

I especially love the fact that non-plexpass user is bitching about this, and use the word maybe afford the plex pass if this gets implemented.

I> @starbetrayer said:

@RedSocks157 said:
I don’t get why this hasn’t been implemented. This feature has been requested for ages, just look how far back this thread goes and there were others before it. And they haven’t even addressed the issue. I don’t need lyrics for my music, I don’t need half the crap they keep shoehorning into this software. GPU encoding on the other hand would be easy to implement (the libraries already exist for god’s sake, why not just include them?) and it would make a HUGE difference for a ton of users. It wouldn’t take a freaking Xeon or i7 processor to stream multiple HD movies at once, or to transcode a bluray rip for an off-network client. Suddenly, APUs and i3s would be able to handle WAY more stuff, and a system with a video card would be even better.

The improvement in lower-end hardware being used for servers would be huge, and it would make Plex more appealing to people who can’t afford to have a server rack in their basement. And if I’m not spending $300 on the processor for my server, maybe I can afford to pay $150 for PlexPass features. Just throwing that out there.

Overall, it’s honestly nuts that hardware encoding isn’t supported. If Emby manages to get it working before Plex does, I’m going to use Emby instead.

Then go use Emby, nobody is retaining you.
If you don’t get why this is not implemented, read the post from rcombs just above.
GPU encoding is not easy to implement contrary to your belief.

I especially love the fact that non-plexpass user is bitching about this, and use the word maybe afford the plex pass if this gets implemented.

@starbetrayer said:

@RedSocks157 said:
I don’t get why this hasn’t been implemented. This feature has been requested for ages, just look how far back this thread goes and there were others before it. And they haven’t even addressed the issue. I don’t need lyrics for my music, I don’t need half the crap they keep shoehorning into this software. GPU encoding on the other hand would be easy to implement (the libraries already exist for god’s sake, why not just include them?) and it would make a HUGE difference for a ton of users. It wouldn’t take a freaking Xeon or i7 processor to stream multiple HD movies at once, or to transcode a bluray rip for an off-network client. Suddenly, APUs and i3s would be able to handle WAY more stuff, and a system with a video card would be even better.

The improvement in lower-end hardware being used for servers would be huge, and it would make Plex more appealing to people who can’t afford to have a server rack in their basement. And if I’m not spending $300 on the processor for my server, maybe I can afford to pay $150 for PlexPass features. Just throwing that out there.

Overall, it’s honestly nuts that hardware encoding isn’t supported. If Emby manages to get it working before Plex does, I’m going to use Emby instead.

Then go use Emby, nobody is retaining you.
If you don’t get why this is not implemented, read the post from rcombs just above.
GPU encoding is not easy to implement contrary to your belief.

I especially love the fact that non-plexpass user is bitching about this, and use the word maybe afford the plex pass if this gets implemented.

@starbetrayer said:

@RedSocks157 said:
I don’t get why this hasn’t been implemented. This feature has been requested for ages, just look how far back this thread goes and there were others before it. And they haven’t even addressed the issue. I don’t need lyrics for my music, I don’t need half the crap they keep shoehorning into this software. GPU encoding on the other hand would be easy to implement (the libraries already exist for god’s sake, why not just include them?) and it would make a HUGE difference for a ton of users. It wouldn’t take a freaking Xeon or i7 processor to stream multiple HD movies at once, or to transcode a bluray rip for an off-network client. Suddenly, APUs and i3s would be able to handle WAY more stuff, and a system with a video card would be even better.

The improvement in lower-end hardware being used for servers would be huge, and it would make Plex more appealing to people who can’t afford to have a server rack in their basement. And if I’m not spending $300 on the processor for my server, maybe I can afford to pay $150 for PlexPass features. Just throwing that out there.

Overall, it’s honestly nuts that hardware encoding isn’t supported. If Emby manages to get it working before Plex does, I’m going to use Emby instead.

Then go use Emby, nobody is retaining you.
If you don’t get why this is not implemented, read the post from rcombs just above.
GPU encoding is not easy to implement contrary to your belief.

I especially love the fact that non-plexpass user is bitching about this, and use the word maybe afford the plex pass if this gets implemented.

Oh, so because I don’t have $150 to pony up I don’t get to share my opinions? Plex started as FREE software, and people would do well to remember that. It’s always been community based. I have just as much reason and right to share my thoughts as anyone who has already paid.

Yes, FFMPEG has libraries that provide hardware encoding. All the Plex team would have to do is merge those libraries into their software. Maybe if they spent less time doing stupid crap like adding lyrics to my music, it would be a feature instead of a drawback. I’m not willing to pay for lyrics in my music. Hardware transcoding, I’d pay for. And guess what? How I spend my money is my business. Maybe you should try not sending people to Emby, I don’t think Plex’s employees would be too happy to see their potential revenue leaving just because some forum-poster took it upon himself to defend them.

197

@WhatPlantsCrave said:

@RedSocks157 said:
I don’t get why this hasn’t been implemented. This feature has been requested for ages, just look how far back this thread goes and there were others before it. And they haven’t even addressed the issue. I don’t need lyrics for my music, I don’t need half the crap they keep shoehorning into this software. GPU encoding on the other hand would be easy to implement (the libraries already exist for god’s sake, why not just include them?) and it would make a HUGE difference for a ton of users. It wouldn’t take a freaking Xeon or i7 processor to stream multiple HD movies at once, or to transcode a bluray rip for an off-network client. Suddenly, APUs and i3s would be able to handle WAY more stuff, and a system with a video card would be even better.

The improvement in lower-end hardware being used for servers would be huge, and it would make Plex more appealing to people who can’t afford to have a server rack in their basement. And if I’m not spending $300 on the processor for my server, maybe I can afford to pay $150 for PlexPass features. Just throwing that out there.

Overall, it’s honestly nuts that hardware encoding isn’t supported. If Emby manages to get it working before Plex does, I’m going to use Emby instead.

Emby already has this available.
GPU Transcoding · MediaBrowser/Emby Wiki · GitHub

Other than the “easy to implement”, I agree with you. Plex pushes an astonishing number of fringe “features” while major issues go unaddressed and bugs fester in core functions. I’m glad that rcombs addressed this thread and helped to clarify some of the issues. That said, I’d really hate to see QS delayed because of something as simple as requiring customers to download an extra package. My Plex server is Linux based, and it sounds like I won’t be seeing QS support for quite some time. Very frustrating.

Drives me nuts. This would be a huge feature, and ffmpeg already has some of the functionality. Hell, AMD even opensourced VCE (Video Coding Engine) back in '14, so there’s really no excuse for that to be working at least! Intel QS would be huge for anyone running a NAS with an Atom processor in it, because the Atom might actually be able to handle some encoding if hardware encoding was enabled. Emby has been around a lot less time than Plex, and it already is working on getting HW transcoding working AND has a dev version that can do it, and do it well! There’s really no excuse. I’m not paying for fringe features. I want real functionality first.

198

@RedSocks157 said:
Oh, so because I don’t have $150 to pony up I don’t get to share my opinions? Plex started as FREE software, and people would do well to remember that. It’s always been community based. I have just as much reason and right to share my thoughts as anyone who has already paid.

But without having a Plex Pass you don’t have access to the proper forums to make your request. There is a whole section of this site for PP members only to post requests and to vote on what they would like to see implemented.

Plex’s first client started out as open source but not the server. It’s not community based software. It’s closed source and unless you are an employee you can’t make changes with the exception of some of the software they have open sourced.

Yes, FFMPEG has libraries that provide hardware encoding. All the Plex team would have to do is merge those libraries into their software. Maybe if they spent less time doing stupid crap like adding lyrics to my music, it would be a feature instead of a drawback. I’m not willing to pay for lyrics in my music. Hardware transcoding, I’d pay for. And guess what? How I spend my money is my business. Maybe you should try not sending people to Emby, I don’t think Plex’s employees would be too happy to see their potential revenue leaving just because some forum-poster took it upon himself to defend them.

They don’t pull ffmpeg into their software. They aren’t allowed to do that without going GPL for their software. Instead they modify ffmpeg but keep it stand-alone.

Your other points concerning features and use of time is well shared by many people.

199

@cayars said:

@RedSocks157 said:
Oh, so because I don’t have $150 to pony up I don’t get to share my opinions? Plex started as FREE software, and people would do well to remember that. It’s always been community based. I have just as much reason and right to share my thoughts as anyone who has already paid.

But without having a Plex Pass you don’t have access to the proper forums to make your request. There is a whole section of this site for PP members only to post requests and to vote on what they would like to see implemented.

Plex’s first client started out as open source but not the server. It’s not community based software. It’s closed source and unless you are an employee you can’t make changes with the exception of some of the software they have open sourced.

Yes, FFMPEG has libraries that provide hardware encoding. All the Plex team would have to do is merge those libraries into their software. Maybe if they spent less time doing stupid crap like adding lyrics to my music, it would be a feature instead of a drawback. I’m not willing to pay for lyrics in my music. Hardware transcoding, I’d pay for. And guess what? How I spend my money is my business. Maybe you should try not sending people to Emby, I don’t think Plex’s employees would be too happy to see their potential revenue leaving just because some forum-poster took it upon himself to defend them.

They don’t pull ffmpeg into their software. They aren’t allowed to do that without going GPL for their software. Instead they modify ffmpeg but keep it stand-alone.

Your other points concerning features and use of time is well shared by many people.

Interesting, so they aren’t using ffmpeg’s most recent updates (which support the features we’re asking for) because they don’t want to have an open source license? Well that’s just crummy of them. Their feature took XBMC and made it better, but it still started with free software and much of their work came from open source. I’m liking what I hear less and less…if they can’t open source things for the community to work on, then they should be more responsive to requests like this which have been ongoing for quite some time. Unfortunately, I’m not about to pay $150 to get access to a forum where I can request a feature just so they can tell me no. I really love Plex but if they want money from people like me they have to either respond to major feature requests or at least make it possible to add the functionality we are looking for.

200

@RedSocks157 said:
I don’t get why this hasn’t been implemented. This feature has been requested for ages, just look how far back this thread goes and there were others before it. And they haven’t even addressed the issue. I don’t need lyrics for my music, I don’t need half the crap they keep shoehorning into this software. GPU encoding on the other hand would be easy to implement (the libraries already exist for god’s sake, why not just include them?) and it would make a HUGE difference for a ton of users. It wouldn’t take a freaking Xeon or i7 processor to stream multiple HD movies at once, or to transcode a bluray rip for an off-network client. Suddenly, APUs and i3s would be able to handle WAY more stuff, and a system with a video card would be even better.

The improvement in lower-end hardware being used for servers would be huge, and it would make Plex more appealing to people who can’t afford to have a server rack in their basement. And if I’m not spending $300 on the processor for my server, maybe I can afford to pay $150 for PlexPass features. Just throwing that out there.

Overall, it’s honestly nuts that hardware encoding isn’t supported. If Emby manages to get it working before Plex does, I’m going to use Emby instead.

I relate to this, except that i do own perpetual plexpass… and i use NONE of its features (cause i tried and droped them all…). The only benefit is that now that my wife has an iphone, i did not have to pay for plex there (i payed for the plex app in the amazon store for android before buying plexpass).

@starbetrayer said:

Then go use Emby, nobody is retaining you.
If you don’t get why this is not implemented, read the post from rcombs just above.
GPU encoding is not easy to implement contrary to your belief.

I especially love the fact that non-plexpass user is bitching about this, and use the word maybe afford the plex pass if this gets implemented.

@WhatPlantsCrave said:
Emby already has this available.
GPU Transcoding · MediaBrowser/Emby Wiki · GitHub

Other than the “easy to implement”, I agree with you. Plex pushes an astonishing number of fringe “features” while major issues go unaddressed and bugs fester in core functions. I’m glad that rcombs addressed this thread and helped to clarify some of the issues. That said, I’d really hate to see QS delayed because of something as simple as requiring customers to download an extra package. My Plex server is Linux based, and it sounds like I won’t be seeing QS support for quite some time. Very frustrating.

@RedSocks157 said:

Oh, so because I don’t have $150 to pony up I don’t get to share my opinions? Plex started as FREE software, and people would do well to remember that. It’s always been community based. I have just as much reason and right to share my thoughts as anyone who has already paid.

Yes, FFMPEG has libraries that provide hardware encoding. All the Plex team would have to do is merge those libraries into their software. Maybe if they spent less time doing stupid crap like adding lyrics to my music, it would be a feature instead of a drawback. I’m not willing to pay for lyrics in my music. Hardware transcoding, I’d pay for. And guess what? How I spend my money is my business. Maybe you should try not sending people to Emby, I don’t think Plex’s employees would be too happy to see their potential revenue leaving just because some forum-poster took it upon himself to defend them.

I have to agree that most of the features added are of no consecuense to VIDEO. (the trailers one might be cool in the first world with fast internet tho).

I find it weird that PLEXPASS users who i had seen as the people who had access to experimental stuff first have no option to follow “maybe hard/poweruser instructions” to download something or set something up, and then get the option to choose the EXTRA experimental whatever (currently the default player/transcoder is named experimental) and get access to this.

I myself, have a decent (albeit old :P) first generation overclocked i7-920, that many times strugles to stream to my chromecast (i only download 720p or sometimes 1080p stuff). I have a mini pc with a much newer (but weaker) intel processor that has quicksync support.

I use plex in my livingroom TV that has a PC behind it, so i could use plex there, but no luck when i go to bed… so my mini pc only has sickrage/couchpotato for downloading stuff and then i have automatic processes to copy my stuff back to my “server” (gaminig pc), for plex T_T

It would be much better (And cheaper on my electricity bill) if quicksync was an option.

Maybe i will check emby, but it pains me cause i already payed for plexpass.