Can any of the following ffmpeg encoders be built on all machines (rather than just machines with the specific hardware), and can the built binaries be loaded on all machines without linkage issues?
probably an untenable thought, but why not use native api’s for the platforms that support them (macOS, windows) which should support hardware encoding where possible. it would mean separate code paths for each platform, and likely linux would be left out, but it might provide a good experience for macOS and windows.
conversely, I wasn’t able to record video with recorder when I tried earlier today; even with an egpu and very little cpu utilization for rack - video would record but audio would drop out of the recording for 30 seconds at a time, where quicktime doesn’t blink. so as-is it isn’t really an option for me.
If anyone wants to help OP’s request, pick an encoder in my above list and show that it can be compiled into ffmpeg with the requirements I listed above. For example, if you want to look at h264_videotoolbox (which requires Mac 10.8+ or something), tell me how to compile it into ffmpeg so that loading the library in Mac 10.7 works but fails gracefully when asked to use that particular encoder. This is half of the crux of OP’s request (the other half being licensing), so suggestions that do not address this are unfortunately not sufficient to solve this problem.
that’s not what I’m suggesting, I’m suggesting not using ffmpeg or another wrapper and using the native APIs directly, hence the not really tenable comment. using the native APIs directly should allow for hardware encoding that works with those APIs - and should eliminate the licensing issue: you’re not distributing code that implements patent-encumberred compressing, you’re distributing code that uses the operating system (or hardware encoder) API to do that compression. for example, AVFoundation Overview - Apple Developer directly on macOS.
Actually that doesn’t solve the problem either. The same question about VideoToolbox could be asked about AVFoundation. How can you produce a plugin binary that uses AVFoundation’s encoders if your version of Mac supports it and fails gracefully if it doesn’t?
Same for Nvidia and without, AMD and without, Intel Quick Sync Video and without, etc.
[quote=“Vortico, post:12, topic:6044”]
if your version of Mac supports it and fails gracefully if it doesn’t
[/quote]`
for macOS, that’d be a target level, if it can compile and is supported by the compilation target, it should work - no failure mode - I can’t speak for windows though.
I’m not interested in compile-time checks because a single package must be delivered to the 8000 users with Recorder added to their VCV account. It must, at runtime, use or not use AVFoundation.
it’s a target compilation option, not a compile-time check, same as when you’re compiling rack itself - rack targets 10.6 and above, correct? compiling against a framework is the same thing: either it will work for the target (10.6) that you’re compiling for, or it won’t. there’s not an option of compiling and having it targeted toward 10.6 and only work on 10.11. as to whether AVFoundation is that framework or CoreAVC would still need to be determined.
since it sounds like it’s not an avenue you want to pursue, it’s likely a moot point, but it does behave different than you what you’re describing.
I hope you didn’t give any identification of the “VCV Recorder” project, because if you did, they’ll find some way of saying “yes”, and we won’t ever be able to have H.264/HEVC now.
Okay, cool. Asking a licensing question is one thing, but asking permission on behalf of someone is another, which shouldn’t happen. (I’ve had complications in the past where a random VCV user asks a Eurorack manufacturer “Can VCV have permission to port your modules?” and of course they say “no” because it wasn’t a proper/well-thought-out negotiation. And then when I ask them later with an actual offer, they say “I already said no.”)
I read this: MP4 / h.264 patent issues? - Video Production Stack Exchange
As usual with anything involving patents it’s murky, but I did get half the idea, that VCV:Recorder being distributed for free actually might let both Andrew and users off the hook, since licensing is primarily about outfits using these capabilities on a big scale to make money, but I’m definately not a lawyer, nor do I ever want to be one
I would disagree. My understanding is that if the VCV Recorder binary includes an implementation of a patented invention, I would be subject to patent fees regardless of whether the product is commercial or noncommercial. The only question that can save me here is “If VCV Recorder uses ffmpeg’s h264_nvenc for example, is enough of the implementation of H.264 offloaded onto hardware that the binary wouldn’t include patented algorithms?”
What I do know is that the first-sale doctrine means that since users have already paid the license fees for H.264 when they bought their GPU, they (or I) would not have to pay it again if used in VCV Recorder. However, this is only true if Recorder uses the GPU’s implementation and doesn’t bundle its own implementation (as that would be another “unit” of the invention.)