Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port to Linux #3

Closed
wants to merge 65 commits into from
Closed

Port to Linux #3

wants to merge 65 commits into from

Conversation

PaulBGD
Copy link

@PaulBGD PaulBGD commented Oct 7, 2016

If you want to test it, just run ./linux/capture.sh with the same arguments that you'd pass to the swift binary.

@PaulBGD
Copy link
Author

PaulBGD commented Oct 7, 2016

This can easily be ported to Mac, replacing all of the Swift code. The changes we'd need to make to the bash script are here: https://trac.ffmpeg.org/wiki/Capture/Desktop#OSX

@matheuss
Copy link
Member

matheuss commented Oct 8, 2016

@PaulBGD thank you for the PR!

I'm afraid we can't use ffmpeg for the job – at least on macOS. I spent countless hours on it (history | grep ffmpeg | wc -l currently returns 839 😛) and I'm almost sure that it isn't a viable solution:

Recording the entire screen with ffmpeg -f avfoundation -i 1 -y test.mp4:

ffmpeg

Recording the entire screen with aperture.js:

aperture

Besides that, we can't record a section of the screen with ffmpeg on macOS 😕

It would be awesome if you could gather some benchmarks from ffmpeg on Linux 😄 Also, do you know how to record the screen natively on Linux, like I did with Swift?

@PaulBGD
Copy link
Author

PaulBGD commented Oct 9, 2016

Yeah we could do it native, but ffmpeg is incredibly fast on Linux. I'll grab some benchmarks.

@doot0
Copy link

doot0 commented Oct 10, 2016

Yo @PaulBGD, I'm curious about those benchmarks - have you had any time to run any? 😅

@PaulBGD
Copy link
Author

PaulBGD commented Oct 10, 2016

ffmpeg could record 345 frames using 1 CPU core, recordMyDesktop could barely record 60 using the same core. From what I can tell its because rMD uses a custom encoder that is nowhere as fast as ffmpeg. With the time that we'd have to put in to make a native implementation as fast as ffmpeg ourselves, I think ffmpeg is the better choice.

@PaulBGD PaulBGD changed the title [Incomplete] Port to Linux Port to Linux Nov 19, 2016
@PaulBGD
Copy link
Author

PaulBGD commented Nov 19, 2016

This is ready to go!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants