mirror of
https://github.com/NickeManarin/ScreenToGif.git
synced 2026-04-25 23:25:52 +03:00
[GH-ISSUE #389] Bundling FFmpeg #1692
Labels
No labels
copy cats
duplicated
future feature
pull-request
⬜ Accepted
⬜ Completed
⬜ Help Wanted 💪
⬜ In Progress
⬜ Missing Details
⬜ Pending
⬜ Waiting For Answer ⏳
🆕 feature preview
🔷 Bug 🐛
🔷 Out Of Scope
🔷 Out Of Scope
🔷 Question
🔷Enhancement
🔷Enhancement
🔷Invalid / External
🔷Knowledge Base
🔷Won't Fix
🕑 High
🕑 High
🕑 High
🕕 Medium
🕙 Low
🕛 Critical
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ScreenToGif#1692
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @longzheng on GitHub (Oct 16, 2018).
Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/389
Originally assigned to: @NickeManarin on GitHub.
I just tried ScreenToGif for the first time and was a bit surprised to see that exporting to MP4 wasn't natively supported. I realized that it supports FFmpeg output, but it requires it to be installed.
I was wondering if there any limitation to bundle FFmpeg as part of ScreenToGif so users don't have to install it separately?
(I guess retain the ability to override the FFmpeg install as an advanced option)
@longzheng commented on GitHub (Oct 16, 2018):
Also noticed that you do have a button to download FFmpeg in the options, but it prompts the user to specify a download location.
Could I suggest if the app is installed, then at least this button by default would save FFmpeg to the installation directory (so it's 1 step less for the user)?
@smaragdus commented on GitHub (Oct 16, 2018):
ScreenToGif is a tiny program, as of version 2.14.1 is less than 3 MB. Bundling FFmpeg will make it monstrously huge. Anyway, the name of the program is ScreenToGif, not ScreenToMp4 so main priority should be image formats while video formats should be just an extra as it is now. This is my opinion as a user- I hate tools which came bundled with FFmpeg and I hope that ScreenToGif will not follow the route to bloatware.
@vatterspun commented on GitHub (Oct 16, 2018):
You might also want to do what ShareX has integrated with their software: an auto-download feature. That will maintain a small download size and enable video export for the users that need it.
Alternatively, you might point to one of a number of available open FFMPEG font-ends for a video export tool that works with the amazing number of features built into that tool. That would enable greater control over format, quality, bitrate, etc.
Some possibilities:
Related thread: #376
@riverar commented on GitHub (Oct 16, 2018):
@smaragdus Worrying about the size of the program is completely wrong headed. Also, ffmpeg encodes to a mind-boggling number of formats, in various containers, and isn't specifically tied to MP4 at all.
@vatterspun commented on GitHub (Nov 25, 2018):
@riverar I think @smaragdus is concerned less about the obvious feature benefit of including FFMPEG (huge) versus just this ongoing move in software to grab everything and worry about it later. Java used to take serious heat for it's high overhead size from libraries, JRE, etc. but now it's everywhere, especially the Electron framework.
I don't have strong feelings one way or the other for ScreenToGif in particular (which overall isn't especially large for its feature set), I just know where @smaragdus is coming from.
@smaragdus commented on GitHub (Nov 25, 2018):
I searched my machine and it turned out that there are 71 instances of ffmpeg.exe used by various programs- players, converters, video, audio and tag editors, downloaders, catalogs, servers, etc. Most of these programs come with absolute, hard-coded paths to ffmpeg.exe and as a result I have not just multiple instances but also different (in most cases- outdated) versions of ffmpeg.exe. Besides a huge waste of space it is also a huge waste of time to update these instances one by one.
@vatterspun commented on GitHub (Nov 25, 2018):
I know it's not the point of your post, but there used to be a tool that would find outdated libraries and allow you to update them all in batch. I can't seem to find it. Will keep my eyes open and post back here if I do.
@majkinetor commented on GitHub (Jan 14, 2019):
Could be done via #431 too and looks like more semantically correct as each tool can lead its own life.
@NickeManarin commented on GitHub (Dec 13, 2019):
#563