Even more instantly, if your file is not in a "fixed" container format like MP4 or AVI but one designed for streaming use like an MPEG TS or PS, you can simply cut a (suitably large) range of bytes from it using any generic file manipulation tool; on POSIX-like systems, head and tail would work.
After all, it is called a stream for a reason... while there's definitely a lower limit to how small you can cut out a piece and have it still decode, as far as I know, all common audio and video codecs are designed with sync codes and "markers" so that a decoder can easily find a valid data block to start decoding from. Something like a broadcasted signal from a TV channel has no start nor end, so decoders need to be able to just jump in at any point and start decoding.
This is essentially how we broke apart long streams into manageable archive files at Justin.tv. You can get slightly better decoder behavior if you’re careful about where you make the cut: some frames are encoded as a difference from the previous frame and others are self-contained. If you cut before one of the self-contained frames, the decoder can start immediately instead of throwing away some data.
Yes, indeed, I had worked on a small project of mine and needed a really efficient and cheap way to serve terabytes of data to a lot of users, fast. I was poor and young (15 years old).
I re-created (I haven't invented this, obviously) a way to split the video file into keyframe segments and mark down the start byte offsets of the keyframes, and then I could "virtually" split the file for streaming, so that a user wouldn't 1) buffer the whole file, 2) need to have the whole file to share to others (P2P in the browser), 3) need to restart the stream and sharing if the connection broke.
This could've obviously been done with HLS or DASH, but that required remuxing the files and keeping lots of them. I instead remuxed files into TS container, indexed all the files, made JSON manifests, and had a network of reverse proxy "CDN" servers on continents that would pull the files from a few central servers, cache the small virtual chunks, which were created by reading byte offsets from the file and serving it as a "file" with PHP.
In the end, the project collapsed due to non-technical issues, and me loosing interest and doing more legitimate and useful things. I then resold the technology a few times to some people who wanted the similar thing but wouldn't have the issues I had, then I moved on and forgot it all.
It's history, it's made my career in some way, at least from my side, it was innovative for it's time, and made me nerdy-cool in school, both with other kids and the school staff.
Nice one. The key is the `-c copy -map 0` option which preserves the same codecs and stream metadata. This makes the edit operations nearly instant too.
While on the topic of ffmpeg uses, here is a script I posted that speedup videos by a factor of 1.5: https://news.ycombinator.com/item?id=22584131 (use case record an unscripted screencast or demo with lots of pauses and uhms, then speed it up to make it look like you are super well prepared and caffeinated --- hidden bonus: if demoing a software product it will appear to be 33% faster!)
VLC can speed video or audio up/down on the fly, preserving audio pitch. I'm using it with audiobooks and old movies, and also occasionally (without pitch lock) to turn hard house into sweet groovy house or breakcore into playful idm, as suggested by RDJ himself—see https://youtube.com/watch?v=5yBvP3616Wc and https://youtube.com/watch?v=aWqf17mUyoQ
Btw, for some reason ffmpeg doesn't do well with changing speed of music—the result sounds poor compared to VLC. I found that `sox` gives better quality.
Ah, and I neglected to note that VLC does the speed-trick both on desktop and Android. On a phone, it's not quite perfect for audiobooks due to some hiccups in controls, but the versatility is its favor.
Lots of love to mpv in general because it's an awesome tool, but VLC also have hotkeys for those things + I'm pretty sure VLCs feature set is much larger than mpv while still being super lightweight.
I dont know what it is called but they use to start radio shows some seconds (or minutes?) before broadcasting them. Some technology was used to skip tiny parts where the host was silent (breathing or going uhhhmmm)
I haven't tried speeding up TV before, I think that would ruin some of what I like about TV (and I use Plex which doesn't have that option) but podcasts I speed up with Overcast and I've been watching a little more on Youtube (news, tutorials, etc) lately and I've really used the playback speed options a lot. Normally 1.5 is fine as long as I'm paying attention. Sometimes if I'm trying to get something down word-for-word I'll slow it down to .5 so I can keep up (I guess I'm not a very fast typer). I love being able to control it so easily.
Thanks! I'll check out your speed up trick. I also discovered the ffmpeg reddit today.
I've been playing around a bunch with FFmpeg these last few days because I thought it was ridiculous I had to manually perform certain tasks in ScreenFlow which appeared entirely programmable.
I have another more interesting post on subtitles / captions, but that is for a more niche audience.
Pretty interesting how H.265/HEVC Hardware encoding differs across platforms and how software encoding produces much smaller files at the same quality.
Pretty interesting how H.265/HEVC Hardware encoding differs across platforms and how software encoding produces much smaller files at the same quality.
Consumer hardware encoders are more constrained than software in what they can do, and thus are usually designed to optimise what they are best at: encoding speed and power efficiency.
My friend has been using ffmpeg for trimming game clips for a while. His workflow is: opening a video in a video player, making note of start and stop times, and plugging the times into his ffmpeg script.
Avidemux is a FOSS video editing tool I ran into that implements ffmpeg. Since this workflow requires a human to manually evaluate points in time in a video, a single tool seems like a better choice.
I wrote a graphical tool with Lazarus that invokes ffmpeg. I used it to create clips to report cheaters in an online game, from videos created with OBS.
A word of warning: ffmpeg can't always cut where you want. Sometimes cutting in a certain point gives you a few blank (black screen) seconds. I guess it's because codecs work by storing what's different from previous frames.
If someone uses Lazarus (or maybe Delphi) it's as simple as:
That’s where .net (if you use windows) is super useful. You can create a wpf app with a video player and some shortcuts to fast forward or mark timestamps in a few lines of code. I did that to solve a similar problem (and use ffmpeg to execute the editing too - extract segments and remerge them).
yeah, the first impression is a bit cluttered/overwhelming, especially if you're just looking to do a very basic trim with a preview. but a simple tutorial with some annotated screenshots could fix that.
There is an interesting GUI tool that is supposed to allow you to do this with frame accuracy by re-encoding the section of the cut video before the first keyframe, and merging it with the losslessly copied section. However unfortunately in practice I have found it so unreliable as to be useless. I wonder if there is a similar better tool for this.
As usual it fails to calculate exact frame timings, which means the cuts may not end up exactly where the GUI is telling you (even if you take care to define the cut start at a keyframe).
Avidemux is great for what it is but doesn't make any attempt to allow frame-exact cutting by partial reencoding afaik, which is what I found unique/interesting about VidCutter
The notable function that does video cuts without a full re-encode is shortenVideo, which cuts a certain number of seconds off the beginning of a video. I've never had any issues with it, but I only used it on h264 mp4 files.
I tried installing VidCutter on Windows. When I enabled the re-encode mode, trying to render a video made the program stuck with no CPU activity, and did not encode a video at all.
Yep I had that recently. I tried it another time before that and then it decided to spawn dozens of ffmpeg instances at once basically forcing me to reset my PC. It's a good idea but just not implemented well it seems.
Speaking of FFMPEG, anyone have a command-line they can share for a good de-shake filter? (Like the kind that keeps the subject in the center by rotating/moving the frame if needed?)
I've Googled and tried this so many times but there are so many filters and knobs I half-understand (at best) that I haven't really managed to find one I actually like in practice, but I feel like it must be possible given that people post videos online that do this extremely well.
Update: Just tried it. It seems to do some kind of blurring to smooth the vibrations over several frames instead of trying to cancel the shaking by inverse-transforming the frame with respect to the shake. I think I've tried this in my experiments before -- and I guess it's the difference between "de-shake" and "stabilization"? Sadly it doesn't really seem better to my eyes sadly, but thanks for the help anyway.
It works by applying a low-pass filter on the camera's motion, so a sudden kick turns into a slow, low amplitude bob.
Perhaps you just need to increase the smoothing parameter. I found the default of 10 way too low, and needed around 50-100 for my very shaky 50 fps home videos.
It is stabilizing, just not in the way (or as much) as I imagined, is the issue. I tried to describe it, not really sure how else to. But it's not really the same kind of output I'm expecting from a deshaking filter. I'd expect black margins etc. to bleed in for example, but I don't see that here.
They stay stable in the center whereas the rest of the frame is transformed. This necessarily requires introducing black/white crop frames into the image with all kinds of shapes and sizes, but it turns out incredibly smooth and doesn't lose any of the frame. It also requires no noticeable blurring at all from what I can tell. But that doesn't seem to be quite what's happening with these commands though.
I believe what you're looking for is what Reddit's popular bot u/stabbot does.
I was able to find this comment thread where a user posted some ffmpeg scripts to replicate the behavior. Am on mobile currently so I can't verify they do what you're looking for but here's a snippet.
I don't think vidstab can do exactly what's being asked for here, I've never seen it rotating the frame completely to keep a rotating pen stabilized, or move the frame inside a larger canvas to keep a moving subject centered. I think you have to use video editing and do that manually.
Despite the above example apparently applying an actual blur filter, you always might get a bit of blur on videos in general because of the motion blur inherent in the source, which becomes more obvious once the motion is removed. You can't really do much about that except for refilm the video with a shorter shutter speed.
I'm sure it is possible, but YouTube has a built in one you can select which may explain why lots of online videos have it even if they aren't using pro software.
I think vidstab is the only option for ffmpeg and it doesn't seem that great. I recently compared it to Premiere and Premiere was quite a bit better. I would also love a top tier option in ffmpeg.
Blender will be able to able to you to apply transformation to stabilize the footage, granted you'll need to cut the final output to remove the blank areas around the footage since it's moving around.
What Blender won't help you with (I haven't found it at least) is removing the motion blur that happens because of the camera shake. Which is fine, Blender is not a post-production tool, but worth knowing that if you want to stabilize footage, you probably need Blender + insert-favorite-post-production-tool.
The problem with this is that it can only cut on i-frames which depends on the way your file was encoded. A lot of cameras encode around 1 i-frame per second so that means that you can not accurately cut your videos from say 0.5 to 2.5, you must cut from 0 to 3. This may or may not be a big deal for your specific need
Yeah, my understanding is that it's actually very hard to get ffmpeg not to do this, which is why I'd be interested in understanding exactly what this link is supposedly doing. I believe it's almost certainly iframe snapping. If anyone knows of anyway to enforce reencoding up to the first iframe in the copy, I'd love to hear it.
> When used as an input option (before -i), seeks in this input file to position. Note that in most formats it is not possible to seek exactly, so ffmpeg will seek to the closest seek point before position. When transcoding and -accurate_seek is enabled (the default), this extra segment between the seek point and position will be decoded and discarded. When doing stream copy or when -noaccurate_seek is used, it will be preserved.
> When used as an output option (before an output url), decodes but discards input until the timestamps reach position.
It is much slower when used an output option, and I don't really know what it does when you do stream copy, but I suspect it leaves the whole segment with some sort of offset instruction. I often get artefacts when I play it back on vlc, so I try to avoid that option (unless I am re-encoding).
It's slower when used as an output option because it only has an effect on ffmpeg's output; that is, ffmpeg literally has to decode the whole stream up to that point because it doesn't know it can seek.
I believe this has no effect on whether or not you can cut precisely - if transcoding is not enabled, even if ffmpeg is sticking the frames before the first keyframe in the output file, they're effectively garbage from the point of view of the decoder (which might explain why you see artifacts in some players).
This indeed does snap to keyframes when input seeking is used. On output seeking, it cuts the video at the exact time, but there isn't enough information to rebuild the image as it's still a truncated copy of the stream.
It's possible to reencode a (h264-encoded, at least) video up to the first keyframe; it's discussed in this StackExchange submission: https://video.stackexchange.com/a/23542
The gist is to extract and reencode the segment containing the group of pictures to be cut (using the stream segment muxer), then rejoin the subsequent segments and remux the trimmed audio back in afterwards.
Nice work! Would definitely like to see the complete write up and code you talk about at the end, especially if you manage to test it on mkv or mp4 containers.
As always, ffmpeg is terrific, but unfortunately the solution given here is not frame-exact editing, so to me it is just another quick-and-dirty solution when a re-encode is not desired, sort of like avidemux in that regard.
Absolutely. If you need something precise and quality, this isn't the tool. It's definitely for a very quick chop in the command-line, when you want to share some 30s clip in a 2 hour video with a friend or something.
Note that ffmpeg isn't super fast when you want to cut a file into several pieces, mostly because you'll have to start it over and over for each piece (unless you delve into some black magic with its filter graph, which is beyond my patience).
For splitting an audiobook into pieces, so that you can use the seek bar sanely, `mp3splt` can be used in one run pretty much at the disk's speed. Its format language for metadata is atrocious, but thankfully putting the result into a script frees me from revisiting the horror.
Here's the command I use to cut into 10-minute pieces without a 1-minute piece hanging at the end, and to name and title the pieces sequentially—so you can be spared the ordeal:
With ffmpeg, if you use -ss in input mode (ie before the -i), it looks for the nearest keyframe before but it doesn’t scan the full video so running it multiple time for each segment shouldn’t take much more time than a one pass software (and gives you the opportunity to do the segments in parallel if you can afford the I/O).
Alas! I turned to mp3splt after having rather, erhm, prolonged experience with ffmpeg, and found the difference to be night and day. IIRC ffmpeg also utilized the CPU considerably.
I've been using Avidemux for this purpose for years now, very nice open source tool. It can trim any video from either end without re-encoding. I've also been using it to remove sound from videos without re-encoding too.
FFmpeg normalizes input timestamps unless told otherwise via -copyts. So, in the first command, output timestamps start from 0, effectively making -to a duration limiter.
Both -ss and -to should be on the same side of the input for (close to) expected result.
If you have a Mac, you can also do this with QuickTime's Trim option. It lets you adjust the trim points easily and you can then click Save (not export) to trim the file losslessly.
I’ll have to try this! I was under the impression that it was lossy in Quicktime X. I’ve been going back to Quicktime 7 for this option (which has apparantly finally stopped working in Catalina, but the Apple downloadable version originally released for Snow Leopard works fine under Mojave still!). I’ve been using Quicktime 7 Pro to do all kinds of things FFMPEG can do, not only cropping losslessly but also removing, extracting and changing the soundstream. It’s simpler for me than having to remember the commands :)
This one has a UI, but no screenshotS of it (scroll down to jpegcrop), and it also mentions lossless rotation which I haven’t investigated: https://jpegclub.org/
Is someone aware of how popular tools do video trimming (also JPEG cropping).
I have been looking for lossless (reencode-less) trimming of videos since the end of 90s and always just found huge video editing tools that never had these features. And then ypu were stuck with some CLI tools where you need to count the number of frames or milliseconds or something like that. Like if a WYSIWYG tool isn‘t what most people would want to use.
How does the native iOS photo editing tool handle video trimming? And photo cropping? iMovie?
And what about google android tools? Or popular Windows tools?
I used to crop my photos with XnView, which supports lossless cropping. And I‘m always puzzled this hasn‘t really take off in other popular tools.
Lossless crop of photos and lossless trim of videos should always be included as a feature.
Most video editing software (that I've ever used) supports making clips or setting in/out points in longer videos. This doesn't necessarily make new trimmed clips as files on disk because that's expensive (storage and computation) depending on the video's codecs. Editors also expect to export a wholly new output from source so they don't need to make those intermediate clips. It's like pass by reference instead of pass by value.
On iOS the trimming is done losslessly, when you trim a clip it basically does the same as what `ffmpeg` is doing here. It seeks to the new start time and copies all the GOPs (group of pictures) to the new end point. The camera records video with really short GOPs so the trimming can be pretty accurate. Only if you apply filters or crop the dimensions of the video will the trimmed clip be reencoded. Any iOS software using AVKit can do the same lossless trims, I imagine most editors on iOS do.
When doing rotation I know the Photos app just changes the JPEG rotation flag in the EXIF data. If you send the raw photo to something that ignores or doesn't understand EXIF rotation you'll see just the sensor's default orientation. I believe HEIF works the same way (the container has a rotation atom). When exporting an image (reencoding for sharing or after editing) it will bake in the rotation to the image data, actually performing the rotation to the image.
When you use ffmpeg with macOS, you can save a lot of reencoding time (a magnitude of time for H.264) by using videotoolbox, the Apple supplied harware acceleration backend.
Admittedly it's aging a bit and doesn't support a lot of newer formats, but I still find it useful. As much as I enjoy command line, having the gui is nice to mark in&out points and do the trimming all in one spot. You'd still have to open a video player to figure out where to start & end.
With FFmpeg builds being produced for browsers[1], it'd be great see this working in a web app. I tried making one a few years back, but it was a little early. It only worked in Chrome, on a desktop, and with smallish MP4s at the time[2].
I have been using this for some time now. 6 months back, while I was trying to cut a 10mins video to extract a section of 2 mins, I had discovered this. It was a real time saver. Quie a gem.
I recently had to cut (for reasons) an mp4 video somebody sent me over Whatsapp.
After fighting with ffmpeg for a day - they hey word here is "keys" - because there were issues with the video: Sound would start at point but video didn't, or the first part before the first key in it of the video was re encoded and the quality was crap I finally resorted to using Handbrake, that did the job I needed.
Just get any short video somebody sent you and try do use this script, and you'll see what I'm talking about.
The ffmpeg command used in the article is key frame seeking because the -ss argument comes before the -i argument. If the -ss argument is placed after the -i argument, an all frame seeking mode is used.
This is so good. Trying to do the same with Davinci Resolve for GoPro videos in 2.7k resolution took me hours.
p.s. I'm more than sure that there's ffmpeg port to windows, but I've just used it via Ubuntu on WSL (1.0) and it worked perfectly on a 3.72GB file of 8 something minutes length:
I found how to trim the beginning of a video to an arbitrary amount without reencoding. I think the `-itsoffset` flag in ffmpeg causes ffmpeg to add metadata to shift the video in time, without reencoding or actually trimming the underlying video.
I think it's typically the Tim & Eric skit that gets used for mind blown reaction. You could maybe use a different meme format, like the Drake one... But honestly I don't mind :)
Coincidentally, I was looking at the same problem this morning. I found that exact snippet on an SO answer. Amazing!
I was also happy that this FFmpeg approach properly maintained all my subtitle streams. That's something I was working with a few days ago if you look at the other post on my blog.
After all, it is called a stream for a reason... while there's definitely a lower limit to how small you can cut out a piece and have it still decode, as far as I know, all common audio and video codecs are designed with sync codes and "markers" so that a decoder can easily find a valid data block to start decoding from. Something like a broadcasted signal from a TV channel has no start nor end, so decoders need to be able to just jump in at any point and start decoding.