[HN Gopher] VidCutter: A program for lossless video cutting
___________________________________________________________________
VidCutter: A program for lossless video cutting
Author : pkkm
Score : 109 points
Date : 2023-08-20 14:28 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| karmakaze wrote:
| Cool. I was wondering why this didn't exist.
| ShadowBanThis01 wrote:
| It has existed for decades.
| jackhab wrote:
| Avidemux is another alternative existing for many years. I've
| used it a lot to quickly edit videos without recompression -
| saved me tons of time.
| schemescape wrote:
| Yes, I recall using Avidemux for this purpose roughly 20
| years ago.
| haunter wrote:
| It does
|
| https://avidemux.sourceforge.net/
| mintplant wrote:
| There's also LosslessCut: https://github.com/mifi/lossless-cut
| CharlesW wrote:
| Fun fact: The history of lossless editing goes back to the dawn
| of digital video on personal computers. For example, QuickTime
| Movies1 have always been based on an EDL2 model. Only when you
| "export" (vs. "save") is the content re-encoded.
|
| The most popular tool in this category that I know of is
| https://mifi.no/losslesscut/.
|
| 1 The object, vs. the QuickTime Movie file format 2
| https://en.wikipedia.org/wiki/Edit_decision_list
| Rovanion wrote:
| Does anyone know of a software that can do motion detection and
| spit out timestamps in a video for use in ffmpeg or the like?
| j45 wrote:
| What would you like ffmpeg to do with the timestamps, extract
| them?
| sunlite99 wrote:
| How about https://opencv.org/ ?
| passion__desire wrote:
| https://github.com/roboflow/supervision
| brucethemoose2 wrote:
| What do you mean by motion detection? Scene changes?
|
| But whatever you mean, the answer is probably VapourSynth. In
| fact, you can probably do whatever you are trying to do inside
| VapourSynth instead of ffmpeg.
| jamesfmilne wrote:
| You could cut on any frame if your container and decoder
| supported decoding two tracks at once, then switching the active
| track. You could decode two tracks in parallel, each from the
| last keyframe, then switch whenever your want.
|
| Scope-creep would of course require that to expand to include
| dissolves, transitions, etc until you've got a whole
| editor/compositor engine running just to playback a single
| composition.
|
| However this would be quite possible with technologies like
| WebCodecs+WebGPU.
| josteink wrote:
| Decoding a single frame can be done a completely deterministic
| constant-time basis using hardware acceleration, common in
| embedded systems.
|
| Decoding two consecutive frames would obviously require two
| such cycles, which the hardware may or may not be spec'd for.
| With three, four or n skipped frames, you would require (at
| least) n frames prebuffering, rendering and graphics memory to
| guarantee smooth playback.
|
| I think it makes sense to differentiate between mastering
| formats and consumption formats.
|
| One does not, after all, ship studio masters of albums or songs
| people listen to.
| nico wrote:
| A video in the readme would go a long way
| Lucent wrote:
| How does it compare to https://github.com/mifi/lossless-cut?
| alexsantos201 wrote:
| [dead]
| pdntspa wrote:
| It's not an electron app, for one
| IshKebab wrote:
| It uses PyQt. I'm not sure I'd put much money on it being
| faster than an Electron app. The only other PyQt app I have
| used is Cura and that is ridiculously slow. Takes like a
| minute to start up and you can watch it loading the controls
| when there are a lot of them.
|
| I'd take Electron over that tbh.
| traspler wrote:
| Last time I tried VidCutter it was incredibly slow. So slow
| that it seemed completely glitched sometimes. It was such
| an incredibly slow and laggy chore to do anything in the
| app I could not keep using it.
| pdntspa wrote:
| I've been writing some code in PyQT and it's been rather
| pleasant and performant. A lot of decent GUI apps are
| written in QT. Python is just slow.
|
| I will take that over some stupid app cramming an entire
| instance of Chromium down my throat any day.
| madeofpalk wrote:
| I've been writing some code in React.js and its been
| rather pleasent and performant.
| pdntspa wrote:
| Yeah but it's web tech. Desktop apps should feel like
| desktop apps, not a glorified webpage
| IshKebab wrote:
| Have fun copying that error message from a non-selectable
| label widget...
| pdntspa wrote:
| Platform native dialogs almost always let you copy text
| with CTRL+C
|
| And winforms labels have a selectable mode.
| afavour wrote:
| React Native it is, then
| pdntspa wrote:
| Why so in love with React? There are a million other ways
| to write good GUI apps without involving Facebook's
| clockwork
| firen777 wrote:
| Why?
|
| Perhaps I'm missing something, but I only care about the
| functionality and not whether the button should have
| round edges or the background having the right shade of
| grey. The consistent "feel" is nice to have (cough
| winform/wpf/uwp cough), but I would take "web-ish"
| applications over no application/crappy native
| application anytime (especially with Linux)
| pdntspa wrote:
| Native's not crappy, it's the best and most supported. We
| just happen to be in love with the web aesthetic and
| cross-platform. And that decisionmaking is mostly made by
| MBAs who see tech as a means to a financial end and not
| for the joy of writing good code
|
| Web shit is fucking ugly, it eschews platform native
| conventions, and it just feels cheap.
|
| But when I load up a winforms-esque app with toolbars and
| a statusbar and all the nice accoutrements we're
| accustomed too behaving in the way we are accustomed
| to... now I feel like I'm going to get shit done.
|
| Literally the only electron app that feels serious is
| VSCode and the amount of optimizing MS has had to do has
| cut into seven figures
| refulgentis wrote:
| What makes Python native and JS not?
|
| n.b. just because CPython exists doesn't mean Python is
| native.
|
| n.b. native vs. web is colloquially a discussion from 00s
| macOS and 10s mobile about fidelity to the platform's
| standard UI toolkit.
|
| n.b. when people shit on Electron its because of RAM use
| and lack of fidelity to the platform toolkit, and the
| waste of have a full JS engine compiled into an app,
| ideally they'd all use some base WebView from the system
| instead of Chromium
| phailhaus wrote:
| This is some weird flavor of moralizing technology.
| Normal people literally do not care or even notice.
| pdntspa wrote:
| Fuck the normies, they ruined tech. People out there
| dismissing concerns because "normal people" don't care
| completely misses the point. "Normal people" are a
| fucking poison. Let them have their mobile apps and GTFO
| of computing
| phailhaus wrote:
| They are the overwhelming majority of users, whether you
| like it or not. This is the free market at work.
|
| There isn't even a valid concern here to complain about.
| Electron apps are cross-platform out of the box. The
| tradeoff for open access and low-cost development is more
| RAM. Turns out, _developers_ are more than happy to make
| that deal.
| johnnyworker wrote:
| > They are the overwhelming majority of users, whether
| you like it or not.
|
| Yes, and? They're not here. This is not where they hang
| out. The point isn't why someone who doesn't even know
| the difference must not run bloatware, but rather why
| people who do know better frown on bloatware.
|
| > This is the free market at work.
|
| Anything but. The bit that's missing is _transparency_.
| As in, both the buyer and the seller know everything
| there is to know about the product in question and other
| options available.
|
| > Turns out, developers are more than happy to make that
| deal.
|
| Yes, developers. Not users, who aren't _actually_ keen on
| upgrading machines to achieve the same stuff, but have
| been mislead to think this is how it has to be -- because
| from personal computer and user empowerment, we got to
| corporate empowerment. And the same way (too many)
| corporations outsource costs to society and their
| employees, we now consider doing the same as very
| professional. You called it "low-cost development", as
| if the externalized costs simply don't exist. It's just a
| few seconds here, a few dollars there, multiplied over
| thousands or millions or actually-who-even-cares
| instances.
|
| > Electron apps are cross-platform out of the box
|
| So are apps that achieve the same or more with way, way
| less. When you talk about the box the _users_ take them
| out of, that is. When it comes to developers who can
| "just use what they already know", sure, for them
| Electron works "out of the box", while other things
| "require assembly". Okay, so what? Isn't that what coding
| is?
|
| Imagine architects building shittier bridges that use
| more resources, because that's easier and quicker. That's
| perfectly fine for individual architects, but as a trend
| it's just regression.
| pdntspa wrote:
| Why does everything have to boil down to making money?
| This is exactly what I mean.
|
| The free market is meaningless when minds are corrupted
| by people who profit from them
| phailhaus wrote:
| Because developers need to eat, this should not be hard
| to understand. It is cheaper and faster to build an
| Electron app and have it immediately work cross platform,
| than to build several native apps just to please some
| random internet purist.
| pdntspa wrote:
| And if that eating is already covered? To say nothing of
| QT, Avalonia, Uno, GTK, and others. Many of those manage
| to figure out cross-platform with native controls.
|
| But no, we have to use electron because she can throw
| cheap oversaturated webdevs at the problem and call it a
| day.
| johnnyworker wrote:
| It's _even_ easier to make a 3 screenshot tutorial to
| explain how to do it in Avidemux. Slightly more work
| would be to fork Avidemux and rip out everything but the
| lossless cutting. But then you 'd at least have a tool
| worth calling it that.
|
| It's not a one-way street, either. Even just putting a
| link in front of me is asking for my attention. I then
| read the description, which doesn't mention that it's
| giant and totally pointless if you use Avidemux, and have
| to click to the releases page to realize yes, it's
| another one of these that seem to quickly become the
| norm, and that I know won't be maintained in 5 years. But
| hey, _I_ don 't have anything better to do with my time,
| surely!
| tredre3 wrote:
| That's nice but in practice it doesn't mean anything.
|
| Here's a comparison of both apps with the same video file
| open and the same clip cut:
|
| Startup time (time between double click and window appears
| and ready):
|
| - Losslesscut: 2 seconds
|
| - VidCutter: 12 seconds
|
| Time to load the video file:
|
| - Losslesscut: 1 second (to be fair it doesn't show
| thumbnails)
|
| - VidCutter: 3 seconds
|
| Memory usage:
|
| - Losslesscut: 368MB
|
| - VidCutter: 455MB
|
| Idle CPU usage:
|
| - Losslesscut: 0%
|
| - VidCutter: 0%
|
| Network requests:
|
| - Losslesscut: 7
|
| - VidCutter: 0
|
| Installed size:
|
| - Losslesscut: 455MB
|
| - VidCutter: 178MB
|
| Source, kinda (the memory shown is the sum of all
| subprocesses. taken when idle so no ffmpeg subprocess
| included.):
|
| https://imgur.com/a/DwrNdxT
| pdntspa wrote:
| Vidcutter's startup time isn't PyQT, that initializes
| nearly instantly. Considering how both defer to ffmpeg a
| lot of these stats dont mean anything
| refulgentis wrote:
| They are a direct response to the GP post's offhand quip
| about Electron. GP found the difference relevant, and I
| believe you're GP, but I am confused now given the change
| in interest.
| pdntspa wrote:
| My point is that startup time may not have anything to do
| with the GUI. It is not a good metric. I could write both
| an electron and pyQT app that takes minutes to start if
| it has other shit it needs to be doing. I haven't used
| electron in years but pyQT apps start up instantly,
| therefore this app must be doing something else.
|
| If the two apps were programmed identically then you
| might have a comparison.
| speedgoose wrote:
| Most people don't care whether an app uses Python with Qt
| or Javascript with Chromium. They care about more about
| useability and features.
| refulgentis wrote:
| > pyQT apps start up instantly
|
| ????
| MaxikCZ wrote:
| Network requests:
|
| - Losslesscut: 7
|
| Whyyyy
| thot_experiment wrote:
| Does this do anything clever to enable actual frame perfect
| cutting, or is it just splitting on keyframes like avidemux or
| `ffmpeg -i input.mp4 -ss "START_TIME" -to "END_TIME" -c:v copy
| output.mp4`?
| izacus wrote:
| There's nothing "clever" you can do to losslessly cut outside
| the keyframe boundaries. Since reencoding is required, loss of
| quality for at least the cut GOP is a given.
| thot_experiment wrote:
| I'm not sure about that, naively you could turn the entire
| cut GOP into i-frames couldn't you? I'm not super familiar
| with the nitty gritty of h264/h265 but intuitively I think
| you wouldn't even need to turn _everything_ in the GOP into
| i-frames. You could trace out the inter-frame topology of the
| GOP and then replace only the "orphan" frames with i-frames,
| then the remaining p and b-frames would retain the necessary
| reference data for decoding.
|
| I would love it if someone who knows more about this than I
| do would confirm/deny since this is something I've been
| curious about for a long time now. (Though I would also love
| a tool for near-lossless cutting that just re-encodes the cut
| GOP, please link such a thing if it exists)
| ShadowBanThis01 wrote:
| "naively you could turn the entire cut GOP into i-frames
| couldn't you"
|
| Yes, but then you'd have to render the result into a truly
| uncompressed format and it would have to stay in that
| format perpetually. If you wanted to deliver in another
| lossy format, you'd actually lose quality across the entire
| file instead of just the one GOP.
|
| What I'm curious about is whether you can cut in the middle
| of GOPs, recompress the afflicted ones, and then
| concatenate the stream back together without recompressing
| all GOPs. If the file specifies a 12-frame GOP, cutting any
| GOPs is going to break that cadence. So can you have, say,
| a few thousand 12-frame GOPs... then an 8-frame GOP... then
| go back to 12-frame GOPs?
|
| Update: Did some research and you can have "adaptive" GOPs
| of varying lengths:
| https://docs.aws.amazon.com/mediaconvert/latest/ug/gop-
| struc...
| thot_experiment wrote:
| Yeah there's no issue there, most codecs support variable
| bitrates and variable iframe-pacing, and ffmpeg will
| happily concat such files. Also, there's no need to
| render into an "uncompressed format" the i-frames are
| still compressed, and even in the naive case you'd only
| need small number of i-frames because you only need to
| replace any orphans in the cut GOP after which you can
| just go back to normal decoding.
| izacus wrote:
| Yeah, you can absolutely reencode just the GOP where the
| cut happens and IIRC quite a few tools support that.
| synarchefriend wrote:
| I believe the SmartCut feature reencodes just the frames needed
| to reach the closest keyframe.
| ilaksh wrote:
| Technically a front end for ffmpeg which does the actual video
| cutting. Like most other tools like this.
| [deleted]
| washadjeffmad wrote:
| I was hired recently to author a set of DVDs (yes, I know!),
| discovered there's almost no commercial software still
| available outside of Scenarist and TMPGEnc, and tried a dozen
| modern projects while putting together a FOSS workflow, just in
| case I couldn't the conjure CDs, licenses, and keys for
| software I hadn't needed in a decade+.
|
| vidcutter ultimately didn't help in this process. I built it
| from source and then tried the flatpak, but for all of its
| beauty, it hung or crashed when importing common but dated
| formats and containers, handling more than a few clips, and
| didn't allow precise jogging for splitting (when it didn't hang
| or crash). It's good for trimming up a smartphone video, but
| it's not on par with an NLE.
|
| I ended up giving up and scripting out most of the project in
| ffmpeg and dvdauthor. If you know how to use core utilities,
| it's such an exercise in tedium struggling against
| underdeveloped front ends.
| [deleted]
| qbasic_forever wrote:
| I've also noticed playback of DVDs is terrible these days
| too. Long ago I ripped my DVD collection to iso files so I
| could preserve the full experience of the menus, etc. But
| almost nothing these days supports DVD iso playback and
| menus, not even VLC! The only software I can get to work to
| play them is Kodi. It's wild how much DVD software has
| disappeared, I don't remember it being this bad 20 years ago.
| nolok wrote:
| Mount the ISO as a drive and play it ? It's a double click
| worth of effort on windows, and probably one mount call
| away on linux
| qbasic_forever wrote:
| I was trying to play it on Android devices and can't
| mount it unfortunately.
| pastorhudson wrote:
| We found DVD Styler [0] to work well enough for making dvds
| of our church service for elderly who had no internet during
| pandemic.
|
| [0] https://www.dvdstyler.org/en/
| voltaireodactyl wrote:
| FWIW, LosslessCut works similarly to Vidcutter except it's
| functionality is flawless (within limitations) in my
| experience. Def worth a look if you run into a similar need
| in the future.
| josteink wrote:
| That's not to say it doesn't provide value. Using raw ffmpeg is
| a pretty technical task, with lots of pitfalls, and not for
| your average user.
| SparkyMcUnicorn wrote:
| And it gives you nice drag/drop/seek/preview type stuff.
|
| That said, since I've been using an AI assisted terminal
| (warp.dev currently) my use of GUI wrappers for different
| tools has faded quite a bit. I like being able to "Clip 0:10
| through 0:30 of file.mp4 and turn it into a web optimized
| gif", and this NLP workflow works as a "wrapper" for almost
| any CLI. It's a nice interface without the loss of any
| functionality.
| [deleted]
| Kiro wrote:
| What's the reason video editing is not lossless by default?
| CharlesW wrote:
| Non-linear (i.e. normal) video (and audio) editing is lossless
| until you export the result. The neat thing that tools like
| this one, LosslessCut, Avidemux, etc. do is that they don't re-
| encode the video on save/export.
|
| There are a few caveats, though. Examples: (1) You're limited
| to cuts-only edits. (2) Because the base unit of video encoded
| for distribution is a GOP1, edits either have to happen on GOP
| boundaries (i.e. at a keyframe) _or_ the apps have to re-encode
| the GOP.
|
| 1 https://en.wikipedia.org/wiki/Group_of_pictures
| _flux wrote:
| E.g. MPEG4 videos are usually made of I-frames (full frames),
| P-frames (predictions based on older images) and B-frames
| (predictions based on older and future pictures), and from
| these Group Of Pictures are made, which always start with an
| I-frame.
|
| You cannot make frame-precise cuts within this sequence unless
| you wish to carry on the frames that won't be visible (and I
| don't think anyone tries to do these cuts by keeping some
| invisible frames), so you only get to make such edits that
| always include the first I-frame of the sequence.
|
| Therefore if you want to make completely lossless edits your
| editing precision is lost. For frame-precise editing one
| usually ends up re-encoding the stream.
|
| Of course, you could only re-encode only the GoPs that get
| broken while keeping the rest intact, and I guess this would be
| better and a lot faster than re-encoding everything. I don't
| know if any application tries to do this. But that is also a
| bit troublesome, as you'd like to use the same encoding
| parameters--and maybe the same encoder--as the other frames, to
| not have quality differences between the edits and original.
| nuxi wrote:
| Smart Cutter[1] does frame-accurate edits without re-
| encoding. I'm not sure what black magic it uses, but it seems
| to work really well (tested on a couple of MPEG-TS IPTV
| streams).
|
| [1] - https://www.fame-ring.com/smart_cutter.html
| darcien wrote:
| >Of course, you could only re-encode only the GoPs that get
| broken while keeping the rest intact, and I guess this would
| be better and a lot faster than re-encoding everything. I
| don't know if any application tries to do this.
|
| LosslessCut does have experimental support for this partial
| re-encode called "smart cut" [1]. Since it's using ffmpeg
| internally, the challenge become how to instruct ffmpeg to do
| this[2]?
|
| [1]: https://github.com/mifi/lossless-cut/issues/126
|
| [2]: https://github.com/mifi/lossless-cut/issues/1216
| runlevel1 wrote:
| I suspect QuickTime Player.app's trim (Edit menu > Trim)
| does this as well when you save the result (as opposed to
| exporting it).
|
| It's far too fast to be re-encoding the whole video and is
| too precise to be cutting at the nearest keyframe.
|
| It has limited codec and container support, though.
| CharlesW wrote:
| > _It 's far too fast to be re-encoding the whole video
| and is too precise to be cutting at the nearest
| keyframe._
|
| Correct! For example, if you trim the end of a video in
| the middle of a GOP, it _includes_ the entire GOP as is,
| but only _plays_ up to the point where you trimmed.
| j1elo wrote:
| Which is a very bad solution! Imagine cutting a video to
| remove some _very_ privacy sensitive material, and some
| of those frames still ending up in the file, just not
| viewed because _in theory_ the video file politely asks
| the player to skip until a later timestamp.
|
| I'd for sure rather have tools that actually do what they
| claim to do. Using container metadata tricks feels to me
| as lazy and misleading to the user.
| pony_sheared wrote:
| I don't know if there are many cricket fans here, but I
| wondered if this is why - when watching the Ashes highlights
| of the cricket on BBC iPlayer or YouTube - the ball seems
| transparent as it runs over the grass.
| izacus wrote:
| > and I don't think anyone tries to do these cuts by keeping
| some invisible frames
|
| My experience shows that if you try, this confuses and breaks
| many (especially hardware) players trying to play that file.
___________________________________________________________________
(page generated 2023-08-20 23:00 UTC)