I just discovered this post, and I'm really happy to see a lot of satisfied long time users as well as excited new users who recently discovered this.
I think the most common criticism is that the app is large and uses a lot of memory (compared to Notepad?:P) due to it being Electron based. Somewhat unpopular opinion, but here goes: Developing an app using Electron gives such tremendous benefits that it far outweighs any downsides. It lets you easily build a cross-OS app on a super optimised, stable and secure platform that's being battle tested by billions of people around the world every day (Chromium). It gives you all the features of the web, and it "just works" on almost any popular OS. The web has all the big tech pushing new features and improvements all the time and it maintains really good backwards compatibility. I don't think I ever had the LosslessCut app actually crash on me. CI, automatic building and releasing to all different kinds of channels is a breeze due to tools like `electron-builder`.
I think if you compare it to most other lossy video editors, you'll find that the CPU usage is much lower (especially per minute of produced video!), and the memory footprint is probably lower than many other popular video editors. Storage is cheap, and what is 500mb when working with 4K video anyways, so optimising for size is mostly a waste of time and doesn't really benefit 99% of users. Counter arguments are welcome :)
> Developing an app using Electron gives such tremendous benefits that it far outweighs any downsides.
As someone who wrote performant Electron apps, I disagree. Electron has great documentation, but I found little else to praise.
> stable and secure platform
A major factor to me stopping to write Electron apps was the frequent updates needed due to some new flaw upstream. To make matters unbearable, every time there was an update something else had changed with the build tool or the Electron API, which I then had to relearn and painstakingly change everywhere.
I like apps to be done, I don’t want to be forced to babysit in perpetuity an otherwise working app.
> Storage is cheap
It is not. People buy computers and mostly stick to the internal disk which they can’t or don’t know how to change. No one is happy to have to buy and use an external hard drive because their apps—which are orders of magnitude larger than they could be—are eating up all available space.
> It lets you easily build a cross-OS app on a super optimised, stable and secure platform ... Storage is cheap, and what is 500mb when working with 4K video anyways, so optimising for size is mostly a waste of time
I get this perspective from the developer point of view, but I'm not a video editor. I'm a person who occasionally edits videos. Elsewhere in this thread I mentioned that I use vidcutter, a free and open source tool that does the same basic task. After installation it takes 14 MB on my Linux distribution (it's a 4 MB download).
The thing is, I have dozens or hundreds of tiny little utilities like this installed that make one-off tasks that I do once a month or so much easier. I can't afford for them to be Electron based on my 128 GB SSD. For people who edit videos every day it's obviously not an issue, but I wouldn't be surprised if the majority of people who use tools like this don't use them every day. Maybe not even every week. All this extra space adds up.
I think, in fairness, that a lot of the anti-Electron criticism comes from Linux users like myself. Windows users expect to have everything packaged as one gigantic binary with all the dependencies. (Vidcutter is a 175 MB download on Windows.) This strikes most of us as "poorly engineered", which for some is already enough of a reason not to use something. On Linux, the norm is that distribution maintainers put together a package with the dependencies separate, and these are shared between multiple packages. Electron applications are rarely distributed this way, and that's the biggest part of the problem and the source of a lot of the bloat from a Linux user's perspective.
I understand why devs choose Electron and the benefits seems worth it overall and I'm glad it exists (and as you point out, a video editor might be an especially appropriate application for electron). That being said, it has a cost, and part of that cost is that there are certain users who don't like the experience of using electron apps. You may not agree with how big a deal this is for them, but the tone of this seems to be that they are wrong for having that preference. As a dev you don't really get to decide what users do and don't like; it's of course your prerogative to make whatever tradeoffs you wish, but I'd be careful about denying people's experience of your software.
I object to Electron apps when they use a lot of my CPU cycles AND they're for functions that I want to run all the time, like chat programs. Not a problem for a video editor.
thank you very much for it being free and open source.
can container repacking be avoided? currently hls ts container is being extracted which takes time.
seeking "unsupported videos" is much slower than supported
Used this for ages. People will bring up various alternatives (including just strictly using FFmpeg) and I have to wonder if the only use case they can fathom is clipping 1 segment out of a longer video. All suggested alternatives would involve such a garbage workflow and unintuitive experience for any real project. I dislike Electron as much as anyone else but it works fine here, and does the job better than anything else I've tried. I am very comfortable with FFmpeg and have used pretty much any tool you can name, I still use Losslesscut daily.
Not sure exactly what your use case is, but I use vidcutter for lossless clip extraction and it works great and does not require Electron (it's QT based I believe). https://github.com/ozmartian/vidcutter
To answer a point that's been brought up elsewhere in the thread, one nice feature of vidcutter is that you can either cut fully losslessly (on keyframes) or cut frame-perfect while only encoding the frames before and after the first and last keyframes in the cut.
The Arch Linux package for vidcutter is only 4 MB. It has dependencies, of course, but I already have all of them installed for other things. (There's nothing uncommon.) All praise to dynamic linking.
I use FFmpeg for multiple streams and mux them into another container file format. Don't see what LosslessCut does outside of FFmpeg expect for the UI. The backend is anyway FFmpeg as another comment mentions. CLI haters I can understand, not me.
Been using this for years, it's a very good and simple tool. There's a surprising amount of garbage in this space. SEO spam infects any searches you do for video editing software. Many "cut" tools actually just fiddle some start media timestamp in the file so the output file isn't smaller, just a video player will start at the right timestamp. Ie: not an actual cut. This one does the job.
It's implemented in Javascript with Chromium and the HTML5 video player. Not the way I would have thought to do it but makes cross platform a lot easier. You can do the same with ffmpeg on the command line of course but having a GUI to pick the cut points makes all the difference.
LosslessCut is a lifesaver for cutting segments out of my usually-unedited podcast[1].
The workflow to do a minor edit in a full editor like Final Cut Pro looks roughly like:
- open Final Cut Pro
- create a new proj... oh shoot no, a new library? Yeah that's right.
- click import and track down the videos on my hard drive
- now create a new project and drag the videos into the timeline
- use the blade tool to cut out a segment
- export the video which is... uh... oh yes under the share menu bar and then the format needs to be... hmmm... I think export for YouTube
- wait approximately `videoLength/5` for the video to export
- oh my goodness my hard drive somehow has `videoSize*4` less space
In LosslessCut that workflow looks like:
- open LosslessCut[2]
- drag and drop your videos in
- mark the start and end times of either the segments you want to keep or the ones you want to take out
- hit export and... wow, it's already done? How is that possible?! And it's just in the same format as my source video! Perfect. Oh man and it even saved a little xml file so if I happen to open the same file again I haven't lost my human work of marking the in and out points.
The cuts are usually slightly off from where I'd ideally like them to be, I think because LosslessCut can only cut on i-frames[3], but it's a totally fair tradeoff for my use case.
I liked the minimalist editor interface so much I copied the timeline part of it for a dedicated social media video clipper I'm working on[4].
If you'd like to try it out I strongly suggest installing it from GitHub and donating the amount you would've spent in the macOS app store. The macOS app store version has fewer disk permissions and adds an extra step asking for access to each folder you want to edit in.
1. makers.dev
2. frustratingly, right clicking a video and selecting "open in LosslessCut" doesn't work
3. i-frames in most video codecs are "key frames" that repaint the entire frame. Most frames are p-frames or "predicted frames" which just store a delta from the last frame.
> The cuts are usually slightly off from where I'd ideally like them to be, I think because LosslessCut can only cut on i-frames[3], but it's a totally fair tradeoff for my use case.
There is an experimental "smart cut" mode where it re-encodes the video between your cut and the next keyframe. It will of course not be entirely lossless though
> The cuts are usually slightly off from where I'd ideally like them to be
That is (probably) because the editor uses certain marks in the video (I don't remember how they are called) that "group" the frames together, and you can't use simple editors to re encode the video.
I had this issue some time I tried to cut videos from my gf. Then I moved to ShotCut, that cuts the videos exactly where you want, although the walkthrough is a little longer.
> This app is not for exact cutting. Start cut time will be "rounded" to the nearest previous keyframe, which may be a fraction of a second before your desired cut point, or up to several seconds, depending on the encoding.
I found this problem with all ffmpeg-based editors...does anybody know of an editor capable of cutting between inter-frames? The same happens with sound files, which is inconvenient.
As has been said, this happens because of cutting on the closest keyframe, which is the only point where the cut can be done losslessly.
This is how it's been done traditionally, since basically forever as far as I can remember. To be honest, I think modern tools could do better. If you happen to want a cut just 20 frames after a keyframe, those 20 frames could be computed (decoded) in order to create a new keyframe right in the spot you wanted. There are a myriad tools to do the typical lossless easy cut, but no idea of one that goes the extra mile to do this more advanced technique.
That's not "a problem with ffmpeg-based editors"; that's the only way to do it lossless.
Some containers such as Matroska are able to store an offset (and ffmpeg does that), so it starts playing from exact wanted position even though the actual stream contains data since the last keyframe. Some players ignore that though.
You can't do that at all in long-GOP formats without re-encoding.
What happens is that every so often it sends a complete image - the intra frame - and then sends differences to show what changes from frame to frame. This is a complete and utter pain in the tits to edit with, so most people transcode to an intraframe codec like DNxHR or ProRes although there's absolutely nothing wrong with MJPEG or MPEG2 intra-only.
If you don't re-encode, you're limited to cutting at an intra frame because that's where it starts drawing from. If you don't you get all this weird "ghost trail" stuff happening.
LosslessCut is a magnificent tool.
I use it as the final step for my lecture recordings, which have been disassembled with ffmpeg, edited with Audacity, encoded with Handbrake, and finally reassembled using ffmpeg. LosslessCut combines the speed of ffmpeg with a quick and pleasingly minimal UI.
Sort of related - anyone know of an open source tool that can repair video streams that get broken during the download process (using youtube-dl) due to internet interruption.
Everything I've researched into this says that it cannot be done because there is final metadata that gets added at the end of the stream that is missing. This does not seem right - if you have already download frames of video there should be some way to recreate any metadata instead of being left with an unplayable broken mpg file.
The internet has many shady third party paid products that claim to do this but I don't trust them.
LosslessCut is great, but I needed something quick when I cleaned up old GoPro videos. Just open an mp4/mov in QuickTime Player, trim it and save under a new name. It will create a lossless cut. If you need several from same video, you would need to repeat the process on the original file.
(unfortunately, the trimmed video won't get the same metadata, so I also needed to use exiftool -TagsFromFile oldvid.mp4 -all:all newvid.mp4 )
I sure hope this does something Virtualdub can't / anything better than Virtualdub, my current preferred lossless video / audio editing Swiss army knife.
Can anyone confirm whether that is the case?
BTW downloads that don't require approaching Lord Appstore cap in hand can be found here:
LosslessCut looks awesome! I also created a lossless video trimming tool a couple of months ago: https://videotrim.app
LosslessCut seems to be more featureful but mine works in the browser without having to install it. It also has the same limitations since cutting times are rounded to the closest keyframes, but this way there's no need to re-encode anything.
FFmpeg also works of course (it's what LosslessCut uses internally), but in my experience I've occasionally run into files where FFMpeg doesn't properly cut on keyframes and I end up with a few seconds of no image at the start of the video. No such problems with mkvmerge, and the API is much simpler.
Never realised the site was so bad... It's a fantastic tool, but it'd be nice if the site opened with why you'd want to use it, and what it can do, rather than jumping straight into user testimonials from people who mean nothing to you, followed by a complete nonsense "them vs us" image set. In what universe does a reencode-on-save using any of the dozens of normal tools that people use turn a normal video file into a 7 bit palette gif?
LosslessCut works great if the keyframes of the video are not too far apart and if you already know where you want to cut. I posted something similar (a web app for automatic silence removal) a few months ago in Show HN: https://www.savvycut.com.
We also use keyframe based cutting for lossless cuts and a smart-cut mode that only re-encodes parts around keyframes (at least for h264 and vp8 codecs). I see that you also experiment with a similar smart-cut feature: https://github.com/mifi/lossless-cut/issues/126.
That seems to work quite well if you re-encode with the same parameters as the original but I guess there are a lot of edge cases.
It's rare that I come across software with such thoughtfully designed UI and great UX where everything just works™, including things you didn't know you needed. I felt like I immediately knew where everything was (even without toggling the simplified mode). I use LosslessCut from time to time to make small looping videos for my blog, and after my first use I immediately went to donate to the developer. I remember even writing some detailed paragraphs about why it's so good in the PayPal message, but something went wrong and PayPal lost it, so it was a silent donation in the end. Definitely in my global top 5.
HN saves the day again. This is exactly what I needed to edit some videos on a deadline today. Thanks for posting it! I usually use ffmpeg from command line to trim a video but needed to do some more complex edits that LosslessCut makes easy.
If lossless, why doesn't LosslessCut export the original media codec and wrapper? Seems to have its own unique file format.
What I want is a 64-bit version of Quicktime 7 Pro. Q7P has interface issues (handles are too small, and it is clumsy to get to specific time index), but otherwise it is a Swiss Army Knife of clipping. Apple's 64-bit Quicktime X is absolutely worthless (I don't want to re-encode, and I don't want to share anything!).
Don't do this. Place both ss and t before the input -i.
As output options, ss waits till the first KF after the given value, it's not a seek. With a t of 2, that may very well result in an empty video stream.
Of course (pretty sure LosslessCut using ffmpeg under the covers). But this is probably one of those instances where having a GUI comes in handy. You can quickly scrub the video for the exact point you want, see where the closest I frame is (read: the place where your cut is going to start), create multiple cut segments, etc.
[+] [-] mifino|3 years ago|reply
I think the most common criticism is that the app is large and uses a lot of memory (compared to Notepad?:P) due to it being Electron based. Somewhat unpopular opinion, but here goes: Developing an app using Electron gives such tremendous benefits that it far outweighs any downsides. It lets you easily build a cross-OS app on a super optimised, stable and secure platform that's being battle tested by billions of people around the world every day (Chromium). It gives you all the features of the web, and it "just works" on almost any popular OS. The web has all the big tech pushing new features and improvements all the time and it maintains really good backwards compatibility. I don't think I ever had the LosslessCut app actually crash on me. CI, automatic building and releasing to all different kinds of channels is a breeze due to tools like `electron-builder`.
I think if you compare it to most other lossy video editors, you'll find that the CPU usage is much lower (especially per minute of produced video!), and the memory footprint is probably lower than many other popular video editors. Storage is cheap, and what is 500mb when working with 4K video anyways, so optimising for size is mostly a waste of time and doesn't really benefit 99% of users. Counter arguments are welcome :)
-Mikael Author of LosslessCut
[+] [-] latexr|3 years ago|reply
As someone who wrote performant Electron apps, I disagree. Electron has great documentation, but I found little else to praise.
> stable and secure platform
A major factor to me stopping to write Electron apps was the frequent updates needed due to some new flaw upstream. To make matters unbearable, every time there was an update something else had changed with the build tool or the Electron API, which I then had to relearn and painstakingly change everywhere.
I like apps to be done, I don’t want to be forced to babysit in perpetuity an otherwise working app.
> Storage is cheap
It is not. People buy computers and mostly stick to the internal disk which they can’t or don’t know how to change. No one is happy to have to buy and use an external hard drive because their apps—which are orders of magnitude larger than they could be—are eating up all available space.
[+] [-] bscphil|3 years ago|reply
I get this perspective from the developer point of view, but I'm not a video editor. I'm a person who occasionally edits videos. Elsewhere in this thread I mentioned that I use vidcutter, a free and open source tool that does the same basic task. After installation it takes 14 MB on my Linux distribution (it's a 4 MB download).
The thing is, I have dozens or hundreds of tiny little utilities like this installed that make one-off tasks that I do once a month or so much easier. I can't afford for them to be Electron based on my 128 GB SSD. For people who edit videos every day it's obviously not an issue, but I wouldn't be surprised if the majority of people who use tools like this don't use them every day. Maybe not even every week. All this extra space adds up.
I think, in fairness, that a lot of the anti-Electron criticism comes from Linux users like myself. Windows users expect to have everything packaged as one gigantic binary with all the dependencies. (Vidcutter is a 175 MB download on Windows.) This strikes most of us as "poorly engineered", which for some is already enough of a reason not to use something. On Linux, the norm is that distribution maintainers put together a package with the dependencies separate, and these are shared between multiple packages. Electron applications are rarely distributed this way, and that's the biggest part of the problem and the source of a lot of the bloat from a Linux user's perspective.
[+] [-] mrcrumb1|3 years ago|reply
[+] [-] spindle|3 years ago|reply
I object to Electron apps when they use a lot of my CPU cycles AND they're for functions that I want to run all the time, like chat programs. Not a problem for a video editor.
[+] [-] kmlben65|3 years ago|reply
can container repacking be avoided? currently hls ts container is being extracted which takes time. seeking "unsupported videos" is much slower than supported
[+] [-] dddw|3 years ago|reply
[+] [-] Mojave3|3 years ago|reply
[+] [-] bscphil|3 years ago|reply
To answer a point that's been brought up elsewhere in the thread, one nice feature of vidcutter is that you can either cut fully losslessly (on keyframes) or cut frame-perfect while only encoding the frames before and after the first and last keyframes in the cut.
The Arch Linux package for vidcutter is only 4 MB. It has dependencies, of course, but I already have all of them installed for other things. (There's nothing uncommon.) All praise to dynamic linking.
[+] [-] chungy|3 years ago|reply
Best tool for the job. I'll probably keep using ffmpeg to clip out a single segment, but it gets hairy when you have more complicated edits.
[+] [-] legends2k|3 years ago|reply
[+] [-] NelsonMinar|3 years ago|reply
It's implemented in Javascript with Chromium and the HTML5 video player. Not the way I would have thought to do it but makes cross platform a lot easier. You can do the same with ffmpeg on the command line of course but having a GUI to pick the cut points makes all the difference.
[+] [-] christiangenco|3 years ago|reply
The workflow to do a minor edit in a full editor like Final Cut Pro looks roughly like:
- open Final Cut Pro
- create a new proj... oh shoot no, a new library? Yeah that's right.
- click import and track down the videos on my hard drive
- now create a new project and drag the videos into the timeline
- use the blade tool to cut out a segment
- export the video which is... uh... oh yes under the share menu bar and then the format needs to be... hmmm... I think export for YouTube
- wait approximately `videoLength/5` for the video to export
- oh my goodness my hard drive somehow has `videoSize*4` less space
In LosslessCut that workflow looks like:
- open LosslessCut[2]
- drag and drop your videos in
- mark the start and end times of either the segments you want to keep or the ones you want to take out
- hit export and... wow, it's already done? How is that possible?! And it's just in the same format as my source video! Perfect. Oh man and it even saved a little xml file so if I happen to open the same file again I haven't lost my human work of marking the in and out points.
The cuts are usually slightly off from where I'd ideally like them to be, I think because LosslessCut can only cut on i-frames[3], but it's a totally fair tradeoff for my use case.
I liked the minimalist editor interface so much I copied the timeline part of it for a dedicated social media video clipper I'm working on[4].
If you'd like to try it out I strongly suggest installing it from GitHub and donating the amount you would've spent in the macOS app store. The macOS app store version has fewer disk permissions and adds an extra step asking for access to each folder you want to edit in.
1. makers.dev
2. frustratingly, right clicking a video and selecting "open in LosslessCut" doesn't work
3. i-frames in most video codecs are "key frames" that repaint the entire frame. Most frames are p-frames or "predicted frames" which just store a delta from the last frame.
4. thevideoclipper.com
[+] [-] korv|3 years ago|reply
There is an experimental "smart cut" mode where it re-encodes the video between your cut and the next keyframe. It will of course not be entirely lossless though
https://github.com/mifi/lossless-cut/issues/126
[+] [-] rand0mx1|3 years ago|reply
[+] [-] ericol|3 years ago|reply
That is (probably) because the editor uses certain marks in the video (I don't remember how they are called) that "group" the frames together, and you can't use simple editors to re encode the video.
I had this issue some time I tried to cut videos from my gf. Then I moved to ShotCut, that cuts the videos exactly where you want, although the walkthrough is a little longer.
[+] [-] pestatije|3 years ago|reply
I found this problem with all ffmpeg-based editors...does anybody know of an editor capable of cutting between inter-frames? The same happens with sound files, which is inconvenient.
[+] [-] j1elo|3 years ago|reply
This is how it's been done traditionally, since basically forever as far as I can remember. To be honest, I think modern tools could do better. If you happen to want a cut just 20 frames after a keyframe, those 20 frames could be computed (decoded) in order to create a new keyframe right in the spot you wanted. There are a myriad tools to do the typical lossless easy cut, but no idea of one that goes the extra mile to do this more advanced technique.
UPDATE: Navigating the GitHub issues I found out that this is indeed an in-progress experimental feature! That's amazing -- https://github.com/mifi/lossless-cut/issues/126
[+] [-] seba_dos1|3 years ago|reply
Some containers such as Matroska are able to store an offset (and ffmpeg does that), so it starts playing from exact wanted position even though the actual stream contains data since the last keyframe. Some players ignore that though.
[+] [-] Gordonjcp|3 years ago|reply
What happens is that every so often it sends a complete image - the intra frame - and then sends differences to show what changes from frame to frame. This is a complete and utter pain in the tits to edit with, so most people transcode to an intraframe codec like DNxHR or ProRes although there's absolutely nothing wrong with MJPEG or MPEG2 intra-only.
If you don't re-encode, you're limited to cutting at an intra frame because that's where it starts drawing from. If you don't you get all this weird "ghost trail" stuff happening.
[+] [-] mizaru|3 years ago|reply
[+] [-] smallstepforman|3 years ago|reply
https://github.com/smallstepforman/Medo
[+] [-] btdmaster|3 years ago|reply
[0] https://video.stackexchange.com/a/18285
[+] [-] andrewia|3 years ago|reply
[+] [-] QuantumGood|3 years ago|reply
[+] [-] behnamoh|3 years ago|reply
Costs $18.99 on App Store!
[+] [-] bouvin|3 years ago|reply
[+] [-] existingone|3 years ago|reply
Everything I've researched into this says that it cannot be done because there is final metadata that gets added at the end of the stream that is missing. This does not seem right - if you have already download frames of video there should be some way to recreate any metadata instead of being left with an unplayable broken mpg file.
The internet has many shady third party paid products that claim to do this but I don't trust them.
[+] [-] swyx|3 years ago|reply
[+] [-] brink|3 years ago|reply
https://avidemux.sourceforge.net/
[+] [-] TonyTrapp|3 years ago|reply
Or mp3splt for MP3 and Ogg Vorbis: https://mp3splt.sourceforge.net/mp3splt_page/home.php
[+] [-] RGamma|3 years ago|reply
[+] [-] penner_im_auto|3 years ago|reply
[+] [-] ripperdoc|3 years ago|reply
(unfortunately, the trimmed video won't get the same metadata, so I also needed to use exiftool -TagsFromFile oldvid.mp4 -all:all newvid.mp4 )
[+] [-] RunSet|3 years ago|reply
This downloads as an 84.9 MB zip file.
I sure hope this does something Virtualdub can't / anything better than Virtualdub, my current preferred lossless video / audio editing Swiss army knife.
Can anyone confirm whether that is the case?
BTW downloads that don't require approaching Lord Appstore cap in hand can be found here:
https://github.com/mifi/lossless-cut/releases
[+] [-] laszlov|3 years ago|reply
[+] [-] dang|3 years ago|reply
Lossless-cut: The swiss army knife of lossless video/audio editing - https://news.ycombinator.com/item?id=24883030 - Oct 2020 (10 comments)
LosslessCut – Save space by quickly and losslessly trimming video files - https://news.ycombinator.com/item?id=22026412 - Jan 2020 (1 comment)
Show HN: LosslessCut – Cross-platform GUI tool for fast, lossless video cutting - https://news.ycombinator.com/item?id=12885585 - Nov 2016 (33 comments)
[+] [-] severak_cz|3 years ago|reply
[+] [-] datagram|3 years ago|reply
FFmpeg also works of course (it's what LosslessCut uses internally), but in my experience I've occasionally run into files where FFMpeg doesn't properly cut on keyframes and I end up with a few seconds of no image at the start of the video. No such problems with mkvmerge, and the API is much simpler.
[+] [-] TheRealPomax|3 years ago|reply
[+] [-] behel|3 years ago|reply
We also use keyframe based cutting for lossless cuts and a smart-cut mode that only re-encodes parts around keyframes (at least for h264 and vp8 codecs). I see that you also experiment with a similar smart-cut feature: https://github.com/mifi/lossless-cut/issues/126. That seems to work quite well if you re-encode with the same parameters as the original but I guess there are a lot of edge cases.
[+] [-] paraknight|3 years ago|reply
[+] [-] simple10|3 years ago|reply
[+] [-] jtbayly|3 years ago|reply
https://www.rogueamoeba.com/fission/
[+] [-] Pr0ject217|3 years ago|reply
[+] [-] Maursault|3 years ago|reply
What I want is a 64-bit version of Quicktime 7 Pro. Q7P has interface issues (handles are too small, and it is clumsy to get to specific time index), but otherwise it is a Swiss Army Knife of clipping. Apple's 64-bit Quicktime X is absolutely worthless (I don't want to re-encode, and I don't want to share anything!).
[+] [-] seba_dos1|3 years ago|reply
ffmpeg -ss 3 -t 2 -i in.mkv -c copy out.mkv
[edited to put -ss and -t before -i]
[+] [-] gyan|3 years ago|reply
As output options, ss waits till the first KF after the given value, it's not a seek. With a t of 2, that may very well result in an empty video stream.
[+] [-] xienze|3 years ago|reply
[+] [-] genericacct|3 years ago|reply