Are there plans of integrating hardware encoding for video recordings, specifically NVENC?
I’m asking because i’m running a pretty high resolution and both mpeg and avi recording are bringing VCV to 7 frames a second when trying to record.
- 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?
h264_amf
h264_nvenc
h264_omx
h264_qsv
h264_v4l2m2m
h264_vaapi
h264_videotoolbox
hevc_amf
hevc_nvenc
hevc_qsv
hevc_v4l2m2m
hevc_vaapi
hevc_videotoolbox
vp8_v4l2m2m
vp8_vaapi
vp9_vaapi
- Does using a hardware encoder for H.264 and HEVC prevent the need to pay patent royalties to MPEG-LA?
1 Like
I don’t know know if this is still correct, but to my understanding at least H.264 should be free in this context.
https://www.engadget.com/2010/05/04/know-your-rights-h-264-patent-licensing-and-you/
https://www.mpegla.com/wp-content/uploads/avcweb.pdf
I can’t specifically answer those questions, but just wanted to note that OBS has NVENC. So maybe its source code is worth a look.
Where in either of your sources does it support your claim?
My question #2 is simply a matter of “does the patent royalty apply to VCV Recorder if it only uses the nvenc, vaapi, amf, etc APIs?”
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.
That’s what this discussion is about.
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.
not exactly.
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.
Ah, in that case, sure, if I had 20 full-time employees.
I did say “probably an untenable thought” 
but, to get that level of performance, it might be what’s required.
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 asked the MPEGLA whether a payed licence is necessary. Maybe they take the time to answer it.
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.
No I didn’t.
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 kept my inquiry rather vague, only asking about free software.
1 Like
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 
1 Like