WebM support is slow

[ffMathy]

In ShareX with the below settings if I record an 8K video in full-screen (full HD) on YouTube for 15 seconds, the video is almost generated instantly.

With Captura (really nice program by the way, and really awesome codebase :+1:) it takes forever (several minutes - I would say about 3 - 5 minutes actually) with the same test (although I tested using VP9 instead of VP8).

I want to write some software that uses Captura to record (now that I've figured out that the ShareX codebase is quite polluted in my opinion and not very flexible in terms of the Open-Closed principle), and then uploads a video to Imgur.

[ffMathy]

Is there a way we can make Captura as fast as ShareX, perhaps by getting inspiration from the commandline arguments displayed in the screenshot above?

Also, could it be that ShareX records directly to WebM, making it able to skip the post-processing step?

[ffMathy]

Oh, and @MathewSachin, good luck with the exams.

[MathewSachin]

Oh, and @MathewSachin, good luck with the exams.

Thank you, exams went quite well.

In the case of ShareX, all the work is done by FFmpeg. ShareX just calls the FFmpeg command-line and the screen-capture-recorder plugin is the one doing all the work. It uses DirectX behind the scenes.

Regarding the 8K video, what is your screen size? Is it 8K or Full HD. I doubt Captura will be able to record 8K screens. I've tested it only up to 1920x1080 resolution.

I've actually used similar parameters before for WebM but found the quality to be degraded as the speed increased. How was the quality of the video produced by Captura compared to that created by ShareX? I'm not encoding to WebM directly and instead first encoding to MP4 and then re-encoding to WebM because I found that the realtime use of VP8/VP9 encoders was not producing recordings with satisfactory quality.

[ffMathy]

I'm on a weird display. It's a Surface Studio 2. It has 4500 X 3000 pixels exactly, so definitely more than 4K, but not quite 8K.

The video quality was amazing, and worked really well.

I'm not encoding to WebM directly and instead first encoding to MP4 and then re-encoding to WebM because I found that the realtime use of VP8/VP9 encoders was not producing recordings with satisfactory quality.

While I do understand the decision behind this, I slightly disagree with the approach (from my perspective). The WebM conversion is so slow that I don't think a lot of people will use it in its current state. Perhaps they would even rather want worse quality if they can get higher speed?

Is there any way you can get Captura back to capturing directly through the VP9 encoder (perhaps on a branch)? If you can, perhaps I can help from there with my display and make some tests (maybe even tweak some parameters).

[MathewSachin]

You can create a custom FFmpeg encoder on FFmpeg settings page. An example Mp4 encoder is shown by default. Try changing it to (ShareX settings):

-c:v libvpx -deadline realtime -b:v 3000k -pix_fmt yuv420p

or something similar and let me know how it works.

[ffMathy]

Hmmm, it is indeed complaining that it's going too fast.

But does this have to be a critical error? Isn't it only a warning actually? Why do we crash when this happens? Can't we just skip some frames?

[ffMathy]

Also, is there a possibility to record without audio for a custom source?

[ffMathy]

Also, I tried checking out the latest master to diagnose the issue further, but I can no longer figure out how to record using my custom source in the UI? It always just records as MP4.