6 ms·

Show HN: LosslessCut – Cross-platform GUI tool for fast, lossless video cutting

98 points by mifino 10y ago

pritambaral 10y ago
I guessed from the title it was going to be using ffmpeg, because I myself have used ffmpeg's `-ss`, `-t`/`-to`, and `-codec copy` numerous times for this exact purpose. Then I saw that this bundles its own piece of Chromium and ffmpeg and is ~70 MB in size. Something is seriously wrong with today's app development ecosystem if it takes 70 MB, even when I already have both Chromium and ffmpeg on my system. EDIT: On the other end is QtAV, a cross-platform multimedia player and SDK which took me only 1 MB of network download. It uses Qt and ffmpeg, both of which I already have on my system, so it doesn't have to redundantly bundle anything. On OSes without Qt and ffmpeg in their package repos (OS X and Windows), the players are ~ 20 MBs in size. So even if one argues "cost of cross-platform compatibility", it still doesn't make sense to bundle the entirety of a web browser for something as simple as this.
- Kadin 10y ago
  Bandwidth and storage space are cheap; hassle is expensive. I can't tell you the number of times I've ended up cursing the IT gods while sorting out some hellish dependency / shared-libary-versioning fiasco (and apps that use ffmpeg and other media libraries are especially prone to this), and wished I could have just gotten a statically-compiled binary off of the developer's CI server instead. Most of the arguments for shared libraries seem like a misplaced optimization on modern systems (e.g. saves disk space, saves distribution bandwidth), or don't really shake out in reality (e.g. "only have one copy of a crypto library so it's easy to update!") and just lead to a proliferation of library versions on the same system.
  - voltagex_ 10y ago
    I spent most of last week using 2-8 megabit LTE as my only network connection. Bandwidth is not always cheap.
    - andyfleming 10y ago
      True, but time is more valuable.
    - shakna 10y ago
      The most I get here is 1.5 megabits. Yes, Australia. Yes, a terrible data cap: 100GB. Electron apps don't get downloaded. One app is one less Netflix video I can watch.
  - shakna 10y ago
    musl lets you have statically linked C nice and easy. (glibc can't really be made static). It produces executables that can fit on a floppy disc even for large stuff. Alpine has a statically linked ffmpeg, though it can be difficult to compile occasionally. Bandwidth can be cheap, depending on where you are, but giant applications just sort of smell of "get it working now" instead of "make sure it will give the user a good experience".
- mifino 10y ago
  You are correct, it's a GUI for ffmpeg's -ss -t commands. It's always a tradeoff between ease of installation and development for multiple platforms vs reusing already installed components. I know ffmpeg has historically been changing their API alot between their versions. I wanted to make something that just works, built on battle tested technologies. Space is cheap too, and the size of the app is tiny compared to the videos you are processing. The windows binary of QtAV is btw 35MB (i assume compressed), so quite big too. Fun fact though: ffmpeg is actually bundled twice in LosslessCut. once in Electron(Chromium) and once as a CLI :)
  - pritambaral 10y ago
    > The windows binary of QtAV is btw 35MB (i assume compressed) Perhaps you're looking at player+SDK. The player alone[0] is 21MB > ffmpeg is actually bundled twice in LosslessCut. once in Electron(Chromium) and once as a CLI If you use a custom build of Electron, you can at least cut down ffmpeg to just one version. Like the way my distro does it with Chromium and ffmpeg. ---- 0: https://www.microsoft.com/en-us/store/p/qtav-video-player/9nblggh68q9n https://www.microsoft.com/en-us/store/p/qtav-video-player/9n...
    - mifino 10y ago
      Yes, I could call ffmpeg from native code. But it's a bit more of a hassle to do from javascript than to just start the ffmpeg exe. And if the included ffmpeg lib was to crash, I can imagine that the whole application would crash too. But I'm open to suggestions.
      - voltagex_ 10y ago
        I'm surprised there isn't a Node binding for libav/ffmpeg yet. I have the same problem with lots of other open source video tools. I wish it was easier to use ffmpeg via library and then more people might do it.
        mifino 10y ago
- Sir_Cmpwn 10y ago
  I'm legitimately pissed off by this. Electron apps are always annoying to see but this one is genuinely offensive. I hate the culture and ecosystem Electron has allowed to flourish. This project is an insult to computer science.
  - mifino 10y ago
    Embrace the future :) If you really want a small footprint app, you could build your own electron linked to your locally installed libchromium and locally installed node.js, then you can run the app against your local ffmpeg (from PATH, which is the default behaviour if the bundled ffmpeg is missing). Now it's only a few MB in size.
  - tambourine_man 10y ago
    70MB is less then U$0.01 And for that, you get one hell of a text/layout engine, hardware accelerated 2D/3D graphics, integrated IDE, one the fastest interpreted runtimes around, which happens to be the most popular programing language… All Open Source, cross platform. Yeah, insulting indeed. Who needs those damn Electron apps.
    - mintplant 10y ago
      > one the fastest interpreted runtimes around Maybe tangential but I think V8's speed has become somewhat mythologized. In AWFY [0] benchmarks I've seen JSC routinely come in 30-50% faster. [0] https://arewefastyet.com/ https://arewefastyet.com/
    - Sir_Cmpwn 10y ago
      >you get one hell of a text/layout engine, hardware accelerated 2D/3D graphics, integrated IDE, one the fastest interpreted runtimes around, which happens to be the most popular programing language… All so you can provide a graphical interface for two ffmpeg flags.
      - syngrog66 10y ago
        > All so you can provide a graphical interface for two ffmpeg flags. "everything old becomes new again" reminds me also of the hot new trend of chat based interfaces. (hmmm, pretty sure that was our default computer interface back in 60's/70's/80's)
- mintplant 10y ago
  > Something is seriously wrong with today's app development ecosystem if it takes 70 MB, even when I already have both Chromium and ffmpeg on my system. I used to think this way about Electron as well, but then I tried bundling up a ~30 lines long Python/NumPy+SciPy script for standalone use on Windows. pyinstaller produced a 300mb blob; the smallest I could get the whole thing was around 100mb.
  - pritambaral 10y ago
    > for standalone use on Windows There's the difference. In your case, you were bundling for a system that didn't already have Python+NumPy+SciPy. In my case, I already have Chromium/Chrome and ffmpeg on my system.
revelation 10y ago
So you're playing with version X of ffmpeg and cutting with version Y. It seems that X+Y equals disaster.
tckr 10y ago
Check out AviDemux, http://fixounet.free.fr/avidemux/ http://fixounet.free.fr/avidemux/ it offers a simple UI and also lossless cutting.
- stefantalpalaru 10y ago
  That's what I use for lossless cutting. Jumping to the next/previous I-frame is as simple as pressing up/down arrow.
- pkroll 10y ago
  Amusingly, AviDemux, which has a LOT more ability than just cutting... is about 71 meg.
cm3 10y ago
How do you deal with the fact that some video tracks do not provide the needed cross-frame data or the times you're cutting are at unfortunate points which would require a re-encoding because a quick byte copy of the existing stream doesn't work or at the very least will complain later about missing things like color info (although it's played back correctly by mpv)?
- mifino 10y ago
  I don't know what you mean by cross-frame data. The program is using ffmpeg's -ss, -t, and vcodec copy functionality, and I'm not sure how it handles these issues. I know that if you cut between keyframes (which is very likely to happen), then the data before the next keyframe will be lost, so it is not an exact cutting mechanism.
  - cm3 10y ago
    That's another issue, but it can also lose other data which will cause warnings but play most likely with correct color reproduction. I don't have such a source file handy to reproduce, but if you try enough ISO MP4 containers with H246, you will hit one where this is the case. Is `-t` different from `-to` which I've been using?
    - astrange 10y ago
      libavcodec tries to recover from missing frames (you need this for TV broadcasts) but it's actually not very good at it for H.264. You'd almost always see major artifacts. Any idea what the exact warning text is?
arjie 10y ago
I think including everything is super cool because I had the app installed and running in under 10 seconds. What wasn't cool was that I asked to cut a short 15 s video to the first second, and there was no feedback but the spinning gear for 5 minutes.
- mifino 10y ago
  That's a bug then: https://github.com/mifi/lossless-cut/issues https://github.com/mifi/lossless-cut/issues Edit: could you check if ffmpeg was still running while it was spinning? Maybe we need to kill it if it takes too long.

98 points by mifino 10y ago

I guessed from the title it was going to be using ffmpeg, because I myself have used ffmpeg's `-ss`, `-t`/`-to`, and `-codec copy` numerous times for this exact purpose. Then I saw that this bundles its own piece of Chromium and ffmpeg and is ~70 MB in size. Something is seriously wrong with today's app development ecosystem if it takes 70 MB, even when I already have both Chromium and ffmpeg on my system. EDIT: On the other end is QtAV, a cross-platform multimedia player and SDK which took me only 1 MB of network download. It uses Qt and ffmpeg, both of which I already have on my system, so it doesn't have to redundantly bundle anything. On OSes without Qt and ffmpeg in their package repos (OS X and Windows), the players are ~ 20 MBs in size. So even if one argues "cost of cross-platform compatibility", it still doesn't make sense to bundle the entirety of a web browser for something as simple as this.

Kadin 10y ago
Bandwidth and storage space are cheap; hassle is expensive. I can't tell you the number of times I've ended up cursing the IT gods while sorting out some hellish dependency / shared-libary-versioning fiasco (and apps that use ffmpeg and other media libraries are especially prone to this), and wished I could have just gotten a statically-compiled binary off of the developer's CI server instead. Most of the arguments for shared libraries seem like a misplaced optimization on modern systems (e.g. saves disk space, saves distribution bandwidth), or don't really shake out in reality (e.g. "only have one copy of a crypto library so it's easy to update!") and just lead to a proliferation of library versions on the same system.
- voltagex_ 10y ago
  I spent most of last week using 2-8 megabit LTE as my only network connection. Bandwidth is not always cheap.
  - andyfleming 10y ago
    True, but time is more valuable.
  - shakna 10y ago
    The most I get here is 1.5 megabits. Yes, Australia. Yes, a terrible data cap: 100GB. Electron apps don't get downloaded. One app is one less Netflix video I can watch.
- shakna 10y ago
  musl lets you have statically linked C nice and easy. (glibc can't really be made static). It produces executables that can fit on a floppy disc even for large stuff. Alpine has a statically linked ffmpeg, though it can be difficult to compile occasionally. Bandwidth can be cheap, depending on where you are, but giant applications just sort of smell of "get it working now" instead of "make sure it will give the user a good experience".
mifino 10y ago
You are correct, it's a GUI for ffmpeg's -ss -t commands. It's always a tradeoff between ease of installation and development for multiple platforms vs reusing already installed components. I know ffmpeg has historically been changing their API alot between their versions. I wanted to make something that just works, built on battle tested technologies. Space is cheap too, and the size of the app is tiny compared to the videos you are processing. The windows binary of QtAV is btw 35MB (i assume compressed), so quite big too. Fun fact though: ffmpeg is actually bundled twice in LosslessCut. once in Electron(Chromium) and once as a CLI :)
- pritambaral 10y ago
  > The windows binary of QtAV is btw 35MB (i assume compressed) Perhaps you're looking at player+SDK. The player alone[0] is 21MB > ffmpeg is actually bundled twice in LosslessCut. once in Electron(Chromium) and once as a CLI If you use a custom build of Electron, you can at least cut down ffmpeg to just one version. Like the way my distro does it with Chromium and ffmpeg. ---- 0: https://www.microsoft.com/en-us/store/p/qtav-video-player/9nblggh68q9n https://www.microsoft.com/en-us/store/p/qtav-video-player/9n...
  - mifino 10y ago
    Yes, I could call ffmpeg from native code. But it's a bit more of a hassle to do from javascript than to just start the ffmpeg exe. And if the included ffmpeg lib was to crash, I can imagine that the whole application would crash too. But I'm open to suggestions.
    - voltagex_ 10y ago
      I'm surprised there isn't a Node binding for libav/ffmpeg yet. I have the same problem with lots of other open source video tools. I wish it was easier to use ffmpeg via library and then more people might do it.
      - mifino 10y ago
Sir_Cmpwn 10y ago
I'm legitimately pissed off by this. Electron apps are always annoying to see but this one is genuinely offensive. I hate the culture and ecosystem Electron has allowed to flourish. This project is an insult to computer science.
- mifino 10y ago
  Embrace the future :) If you really want a small footprint app, you could build your own electron linked to your locally installed libchromium and locally installed node.js, then you can run the app against your local ffmpeg (from PATH, which is the default behaviour if the bundled ffmpeg is missing). Now it's only a few MB in size.
- tambourine_man 10y ago
  70MB is less then U$0.01 And for that, you get one hell of a text/layout engine, hardware accelerated 2D/3D graphics, integrated IDE, one the fastest interpreted runtimes around, which happens to be the most popular programing language… All Open Source, cross platform. Yeah, insulting indeed. Who needs those damn Electron apps.
  - mintplant 10y ago
    > one the fastest interpreted runtimes around Maybe tangential but I think V8's speed has become somewhat mythologized. In AWFY [0] benchmarks I've seen JSC routinely come in 30-50% faster. [0] https://arewefastyet.com/ https://arewefastyet.com/
  - Sir_Cmpwn 10y ago
    >you get one hell of a text/layout engine, hardware accelerated 2D/3D graphics, integrated IDE, one the fastest interpreted runtimes around, which happens to be the most popular programing language… All so you can provide a graphical interface for two ffmpeg flags.
    - syngrog66 10y ago
      > All so you can provide a graphical interface for two ffmpeg flags. "everything old becomes new again" reminds me also of the hot new trend of chat based interfaces. (hmmm, pretty sure that was our default computer interface back in 60's/70's/80's)
mintplant 10y ago
> Something is seriously wrong with today's app development ecosystem if it takes 70 MB, even when I already have both Chromium and ffmpeg on my system. I used to think this way about Electron as well, but then I tried bundling up a ~30 lines long Python/NumPy+SciPy script for standalone use on Windows. pyinstaller produced a 300mb blob; the smallest I could get the whole thing was around 100mb.
- pritambaral 10y ago
  > for standalone use on Windows There's the difference. In your case, you were bundling for a system that didn't already have Python+NumPy+SciPy. In my case, I already have Chromium/Chrome and ffmpeg on my system.

revelation 10y ago

So you're playing with version X of ffmpeg and cutting with version Y. It seems that X+Y equals disaster.

tckr 10y ago

Check out AviDemux, http://fixounet.free.fr/avidemux/ http://fixounet.free.fr/avidemux/ it offers a simple UI and also lossless cutting.

stefantalpalaru 10y ago
That's what I use for lossless cutting. Jumping to the next/previous I-frame is as simple as pressing up/down arrow.
pkroll 10y ago
Amusingly, AviDemux, which has a LOT more ability than just cutting... is about 71 meg.

cm3 10y ago

How do you deal with the fact that some video tracks do not provide the needed cross-frame data or the times you're cutting are at unfortunate points which would require a re-encoding because a quick byte copy of the existing stream doesn't work or at the very least will complain later about missing things like color info (although it's played back correctly by mpv)?

mifino 10y ago
I don't know what you mean by cross-frame data. The program is using ffmpeg's -ss, -t, and vcodec copy functionality, and I'm not sure how it handles these issues. I know that if you cut between keyframes (which is very likely to happen), then the data before the next keyframe will be lost, so it is not an exact cutting mechanism.
- cm3 10y ago
  That's another issue, but it can also lose other data which will cause warnings but play most likely with correct color reproduction. I don't have such a source file handy to reproduce, but if you try enough ISO MP4 containers with H246, you will hit one where this is the case. Is `-t` different from `-to` which I've been using?
  - astrange 10y ago
    libavcodec tries to recover from missing frames (you need this for TV broadcasts) but it's actually not very good at it for H.264. You'd almost always see major artifacts. Any idea what the exact warning text is?

arjie 10y ago

I think including everything is super cool because I had the app installed and running in under 10 seconds. What wasn't cool was that I asked to cut a short 15 s video to the first second, and there was no feedback but the spinning gear for 5 minutes.

mifino 10y ago
That's a bug then: https://github.com/mifi/lossless-cut/issues https://github.com/mifi/lossless-cut/issues Edit: could you check if ffmpeg was still running while it was spinning? Maybe we need to kill it if it takes too long.