If you truly thought it was "trivial", you wouldn't have added support for it at all. Clearly you do, since you already support it on Windows and Linux. You're free to dislike Quick Sync and not understand the merits of it, but many other people do. If it's good enough for Premiere (an extremely widely used product by professionals), why isn't it for you? I don't understand what's preventing you from doing exactly what they have. Most video professionals use Macs, so to exclude Macs from Quick Sync support doesn't make sense to me.įinal Cut, Compressor, Premiere, Media Encoder, and MacX Video Converter have all managed to implement QSV on the Mac with acceptable quality and performance. I'm not a developer, I'm a professional video editor who has used HandBrake for years, and would love a Quick Sync option for many different reasons. There are other options out there for users, but unfortunately, most aren't as good in other areas. I want working prototype so I have a clean set of numbers to base a decision - If you decide not to listen to what users want, that's certainly your prerogative. I didn't say that code would get committed. Most of HandBrakes features are simply not implemented in hardware.įourth, I said I was going to hook up via the ffmpeg interface (also uses VT). If the patch is accepted, it's not going to be a full code path which would allow for the ultra low power encoding. Third, HandBrake Core (including sync), Video Decode, Filters, Audio, Subtitles will all still run on the CPU.
What I said was Superfast is close enough and if folks are happy with VT compromises, then using a faster x264 preset is a good measure until we decide either way whether to incorporate this. The number of people asking for a feature is only one aspect of that decision and doesn't overrule other concerns. It's our choice whether we decide if a feature is a good fit for HandBrake or not. Read more carefully.įirst, it does matter. Please don't put words in my mouth that I didn't say.
0 kommentar(er)
