Hot answers tagged ffmpeg
This should work faster... ffmpeg -ss 1:00 -t 5 -i in.mkv -ss 2:00 -t 5 -i in.mkv \ -filter_complex "concat=n=2:v=1:a=1" \ out.mkv There's no need to specify -t on the output. There's no need to split the audio and video before the concat.
I finally made it work in splicing directly the VOB files with the commands below : ffmpeg -i VTS_01_2.VOB -ss 463 -c copy -vframes 325 2-manuchoisit.vob ffmpeg -i VTS_01_2.VOB -ss 353 -t 16 -c copy 3-manutombe.vob and then concat the extracts and convert with ffmpeg -analyzeduration 200M -probesize 150M -i ...
In the first step you are doing a lossy conversion, you transcode from vob to mp4, and then to ts. For a lossless re-mux you should just re-mux, better to specify both video and audio: ffmpeg -i VTS_01_1.VOB -c:v copy -c:a copy -bsf:v h264_mp4toannexb -f mpegts intermediate1.ts However, if you re-mux for the purpose of slicing then you should be aware ...
What you want is a very long GOP or I-frame interval. I believe the ffmpeg option -g nnnn will do that, where nnnn is the length of your video in frames. I don't know how to specify "no B-frames", and this will certainly all be codec-dependent. Give it a try.
If you just want to embed a cover you might consider keeping the result as mp3, for example: ffmpeg -i original.mp3 -i cover.png -map 0:0 -map 1:0 -metadata:s:v title="Album cover" -metadata:s:v comment="Cover (Front)" -id3v2_version 3 -write_id3v1 1 result.mp3 If you are creating mp4's, e.g. for YouTube, then I suggest to split the process to two steps - ...
The first frame of a video from any codec will always be an I frame. There is no previous picture for other frame types to use as a reference. B frames might still work. The video will start to distort ahead of the cut point, too, if any B frames are trying to reference a future frame that's not there anymore. Actually, with B frames present, display ...
In the end I have discovered what the problem was here, to an extent, and thanks to a post on the BMXlib forum: By changing the option in raw2bmx from --vc3_1080p_1238 to simply --vc3, this forced raw2bmx to look at the data to determine what video format it was - and it turns out that in this case, it wasn't vc3_1080p_1238.
Only top voted, non community-wiki answers of a minimum length are eligible