I frequently deal with .mp4 footage files which are game recordings from my computer. Because I'm dealing with a laggy game I end up with footage that has both duplicate frames and a variable frame rate. I want to cut out lagspikes from my video, lagspikes that can have the form of variable frame rates and/or duplicate frames. The end goal is to have video with a constant frame rate and no more lagspikes.
I'm well aware that this will destroy or at least damage the audio, but keeping the audio intact is not necessary for my application.
I have come across the mpdecimate filter for FFmpeg. As far as I have seen this is able to remove duplicate frames, however it does this in a way that does not make the output file a shorter video, but it introduces more variable frame rate.
Is it possible to reach my goal with FFmpeg? And if so, how?
Thanks in advance for help!
ffmpeg -i input.mp4 -vf mpdecimate,setpts=N/FRAME_RATE/TB out.mp4
as Gyan showed in a comment on my original question, this is the solution. Works like a charm, thanks a lot!
(FRAME_RATE can be replaced with a number if you wish to have a set framerate)
Related
When extracting segments from a media file with video and audio streams without re-encoding (-c copy), it is likely that the requested seek & end time specified will not land precisely on a keyframe in the source.
In this case, ffmpeg will grab the nearest keyframe of each track and position them with differing starting PTS values so that they remain in sync.
Video keyframes tend to be a lot more spaced apart, so you can often end up with something like this:
Viewing the clip in VLC, the audio will start at 5 seconds in.
However, in other video players or video editors I've noticed this can lead to some playback issues or a/v desync.
A solution would be to re-encode both streams when extracting the clip, allowing ffmpeg to precisely seek to the specified seek time and generating equal length & synced audio and video tracks.
However, in my case I do not want to re-encode the video, it is costly and produces lower quality video and/or greater file sizes. I would prefer to only re-encode the audio, filling the initial gap with generated silence.
This should be simple, but everything I've tried has failed to generate silence before the audio stream begins.
I've tried apad, aresample=sync=1, and using amerge to combine the audio with anullsrc. None of it works.
All I can think to possibly get around this is to use ffprobe on the misaligned source to retrieve the first audio PTS, and in a second ffmpeg process apply this value as a negative -itoffset, then concatting the audio track with generated silence lasting the duration of silence... But surely there's a better way, with just one instance of ffmpeg?
Any ideas?
I just stumbled across the solution by trying some more things.
I take the misaligned source media and process it with another ffmpeg instance with some audio filters:
ffmpeg -fflags +genpts -i input.mkv -c copy -c:a aac -af apad,aresample=async=1:first_pts=0 -ac 2 -shortest -y output.mkv
And it does exactly what I want, pads the beginning (and end) of the audio stream with silence making the audio stream equal length to the video.
The only drawback is that I can't combine this with my original ffmpeg command that extracts the clip, the only way this works is as a 2-step process.
As input I get one mp3 file(input.mp3), then I need to split it into two separate parts(done that) and insert between those parts another mp3(second.mp3).
The problem:
I tried using every single command for concatenating files, converting them to .ts etc etc.
But I always get only the sound of the first mp3 file and the sound of the second is lost. I guess I have to transform my mp3 file into the exact same format as the input.mp3(bitrates, sample rates number of channels) file before I can concatenate it to it.
I could concatenate the two parts of the input.mp3, but no matter what I do I cannot concatenate with second.mp3.
I am using php with exec and ffmpeg.exe file. Is it possible to code it so no matter the input, I can transform second.mp3 into suitable for concatenating mp3?
How can I concatenate two very different mp3 files(diff bitrate, channels, samplerate, bitdeph)?
Let's start with each component...
bitrate
This one doesn't matter. MP3 streams can (and do!) change bitrate mid-stream. As long as you join on a frame header, you're fine.
bitdepth
The concept of sample bit depth doesn't exist within MP3. You can capture at 24-bit, encode to MP3, and the decoder will decode to 16-bit. (Or, with some command line switches, vice versa!) It's not a problem because bit depth doesn't apply.
sample rates
This is usually a problem. Most players don't assume they're going to change output sample rate mid-stream. Most players don't attempt to resample to stick to the rate they were already outputting at. I'm not surprised that you'd have some trouble with a changing sample rate.
channels
This is similar to the sample rate problem in that it requires changing the configuration of the output device. Even if the player supports it, it isn't going to be seamless. (Unless you were going from stereo to mono, where the mono could be easily upmixed to stereo.)
As input I get one mp3 file(input.mp3), then I need to split it into two separate parts(done that) and insert between those parts another mp3(second.mp3).
This actually presents another problem you haven't asked about... timing. MP3 works in relatively large frames (typically 576 samples), which becomes the resolution at which you can splice. Not good. Also, the starts of tracks often have a frame or two of initialization.
A third issue is the bit reservoir. This is where content from one frame is stored in a different frame that might have extra space.
At the end of the day, you're going to have to decode everything to regular PCM samples, do your splicing, and re-encode to MP3. You'll also have to re-sample everything to a common clock rate, and mix to a particular channel count. Fortunately, once decoded to PCM, this is all trivial and standard. Once your input streams are compatible, you an arbitrarily splice on a PCM frame which is the most granular possible.
If you want to concatenate or merge different bit rate and Mono and Stereo mp3 files into one mp3 file use ffmpeg libmp3lame library.
Command :
ffmpeg -i "concat:'url1.mp3'|'mono_url2.mp3'|'stereo_url3.mp3'" -c:a libmp3lame output_file.mp3
Use the atrim, asetpts, and concat filters:
ffmpeg -i input.mp3 -i second.mp3 -filter_complex "[0:a]atrim=end=10,asetpts=N/SR/TB[begin];[0:a]atrim=start=10,asetpts=N/SR/TB[end];[begin][1:a][end]concat=n=3:v=0:a=1[a]" -map "[a]" output
Note: All corresponding streams must have the same parameters in all segments; the filtering system will automatically select a common sample format, sample rate, and channel layout for audio streams. These common parameters will vary depending on the input parameters, so add the aformat filter (or equivalent) if you want consistent results:
ffmpeg -i input.mp3 -i second.mp3 -filter_complex "[0:a]atrim=end=10,aformat=sample_rates=44100:channel_layouts=stereo,asetpts=N/SR/TB[begin];[1:a]aformat=sample_rates=44100:channel_layouts=stereo[middle];[0:a]atrim=start=10,aformat=sample_rates=44100:channel_layouts=stereo,asetpts=N/SR/TB[end];[begin][middle][end]concat=n=3:v=0:a=1[a]" -map "[a]" output
I'm using an ffmpeg script (in Windows) that extracts all the keyframes from a video and pastes them into a folder. I've made sure that my drive speed, CPU, and RAM are not causing a bottleneck.
The quality of the video is actually not important at all in this case. I need to encode the video that the script extracts frames from so that it has the fastest possible decoding speed. File size and quality are not important, only read speed. The video does not have audio. What would work best for me?
If it matters, here's the script I'm working with:
ffmpeg -i input.mp4 -vf "select=eq(pict_type\,I)" -vsync 1 %%3d.bmp
Sorry if sound like I don't know what I'm talking about, this is not a topic I am super familiar with. I appreciate your help!
The below will be much faster for a codec like H.264
ffmpeg -discard nokey -i input.mp4 -vsync 0 %%3d.bmp
Your present approach decodes all frames and then the select filter gets to do gating, but the above command discards everything but keyframes at the demuxer level. It only works with MP4/MOV like containers.
I am programatically extracting multiple audio clips from single video files using ffmpeg.
My input data (start and end points) are specified in frames rather than seconds, and the audio clip will be used by a frame-centric user (an animator). So, I'd prefer to work in frames throughout.
In addition, the framerate is 30fps, which means I'd be working in steps of 0.033333 seconds, and I'm not sure it's reasonable to expect ffmpeg to trim correctly given such values.
Is it possible to specify a frame number instead of an ffmpeg time duration for start point (-ss) and duration (-t)? Or are there frame-centric ffmpeg commands that I've missed?
Audio frame or sample numbers don't correspond to video frame numbers, and I don't see a way to specify audio trim points by referencing video frame indices. Nevertheless, see this answer for more details.
Hey, I want to split a video which is one second long (25fps)into 25 seperate video files. I know I can split it up into jpegs but I need to retain the audio. So when I recompile audio is still there.
This is what I tried to grab the first frame only (with audio):
ffmpeg -i 1.mov -vcodec mjpeg -qscale 1 -an -ss 00:00:00:00 -t 00:00:00:1 frame1.mov
But it doesn't seem to work. Am I wrong in assuming ffmpeg supports time stamps in this format? hh:mm:ss:f?
Thanks
You are wrong in assuming ffmpeg supports timestamps in that format, but that's not the only problem
ffmpeg does not support the time format you're using. Options are either the time in seconds, or hh:mm:ss[.xxx] (two colons and a dot instead of three colons).
Your example code specifically strips the audio. That's what -an does.
Splitting by time when you actually want frames is not a great idea. Though since the audio frames are unlikely to match 1:1 with the video frames, it might be the best option.
Most importantly, most video and audio codecs are lossy and thus do not take well to being broken up into lots of pieces and then put back together. To do this without horribly mangling the quality, you need to first convert both video and audio into raw formats, manipulate those, and then re-transcode to compressed formats once you've done whatever you want to do with the pieces. You'll still lose some quality, but not as much as otherwise.