Closed aolszowka closed 2 years ago
We choose what to support with regards to hardware. Factors such as vendor support, driver stability, whether the hardware is still in support, whether there are known issues etc all play into it. We are a very small team of hobbyists so we simply don't have time to offer wide support.
We haven't placed any in-code limitations to prevent older hardware from working so if advanced users want to have a play, by all means. That said, we've seen quite a few reports of various degrees of brokenness on older AMD, Nvidia and Intel parts. We don't investigate these reports and we don't test any updates on older hardware so have no useful information to share.
With regards to advanced options. Experience.
The preset/tune systems that many of the encoders have is specifically designed to be simple so that users don't need a PHD in video encoding to understand options lists such as http://www.chaneru.com/Roku/HLS/X264_Settings.htm
Therefor, it's typically only very bespoke cases where you'd ever tweak them.
A simple analogy would be: A modern car has hundreds of hidden engine tuning options. 99.99% of users don't ever touch these as they require advanced levels of knowledge and changing them could result in engine damage or poor performance if set incorrectly.
Makes sense; thank you for the clarification. As I don't think there is anything actionable out of this I'll close out the issue. Thank you.
I'll add we do have some hardware at our disposal to test these features and functionalities, but it does become difficult to continually support aging tech. We don't have a firm phase-out period for anything; rather, we recommend known working configurations and for anything older, your mileage may vary.
As Scott mentions, things get particularly interesting on the hardware encoding front due to drivers being an additional variable. Unlike with a fully-contained software pipeline, it's more of a moving target. Thankfully we have some excellent vendor relationships and are able share info both ways regarding potential issues and fixes to keep things stable in most common cases.
I personally do relatively extensive hardware and systems testing for HandBrake, but have had to step back considerably for a number of months now. Coverage has suffered some because of that, so there are some oddities and documentation issues on my list to resolve. Hoping to improve the situation as life allows.
@bradleysepos is there an automated test suite that can be ran to help test on some of these older configurations? I'm imagining running a set of tests against some known libre video (Big Buck Bunny for example) and then packaging up some data gram (IE a text log file or JSON or something) to submit back to the team?
In a perfect world this tool would be runnable with minimal user interaction and the results shipped back to the mothership.
While automation helps, it doesn't solve:
The need to have every generation of hardware. That's a lot of hardware combinations / machines when you consider how many generations of hardware Intel, AMD, Nvidia, Quallcomm have put out over the last decade. Also, differences in variants of parts within a generation. You'd need a small warehouse for that.
Automated testing doesn't get you away from the fact you still need to spend a fair bit of time keeping older hardware working. Things do break. Regularly. Hardware encoding is quite dynamic in that regard.
Thus when you consider that HandBrake is an unfunded hobby, you realise just how impractical it becomes. As Bradley said, we are fortunate enough to have good vendor relationships which make it possible to have these features but there are limits to what's a reasonable ask.
We require a lot of manual testing, especially for UI and user flow concerns. That said, we do have our own internal processes for testing which we ramp up prior to new releases.
I was hoping to work on an automated test environment years ago but it got shelved due to other concerns. Sorta related, Scott's BrakeBench is pretty cool.
In the end, it's difficult to support anything we don't have personal access to and can verify, hence our current recommendations. Community testing is always welcome, however. Feel free to start a GitHub discussion on the main project or visit our forums if you feel you have something valuable to add!
On feeb0ca80549bba706575dcb90e8d6134245e339 it looks like there were several changes to the documentation pages for both Intel QSV and AMD VCE. As there doesn't appear to be an associated PR I had a few questions regarding these changes.
On the Intel QSV page:
Explicitly calls out that this is not recommended; what was the source of this exactly? Is there a specific technical reason that this is not supported? If so would it be possible to link this in the relevant documentation? (I would be happy to draft up a PR if pointed in the right direction but I can't seem to find anything).
For what its worth on the "technically possible" side here's a log showing a 3rd Generation i7 (Ivy Bridge) 3770k performing a hardware accelerated conversion using H.264:
Likewise on the AMD VCE Page:
Seems to imply that you need a relatively modern AMD Card; is there a technical resource that points this out specifically to understand what the underlying requirement is?
Again from a "technically possible" standpoint here is a Radeon HD 7870 Ghz Edition (Pitcarin/Southern Islands https://www.techpowerup.com/gpu-specs/radeon-hd-7870-ghz-edition.c339) from that same era performing a hardware assisted H.264 accelerated encoding:
Also on that page:
Can any more light be shed on where the general recommendation is coming from?
Obviously in both cases this is performing an H.264 encoding instead of the preset H.265 (and these presets are grayed out) is this why the recommendation is this way? Obviously H.265 is superior in just about every way, but when you're on ancient hardware and are not super concerned about space, but rather are looking for speed (IE streaming via Plex or Emby) its an option?