vid.yadif3.1,mcdeint3.1.10.ffvhuff.mkv -an -shortest -aspect 16:9 -c:v libx264 -preset veryslow -x264-params nr=250:ref=6 -crf 22 -filter:v "setpts=3.0*PTS" -movflags +faststart -r 20 clip.mp4 This is the command line I actually used, to make a short slo-mo clip with no sound.įfmpeg -ss 120.2 -t 0.75 -i. I haven't tried using -c:v copy, since I'm cutting out a really short clip to loop, so I know there won't be I frames where I need them. start decoding without actually generating the references that the current frame requires, just use all-gray?) (but it runs faster, since it doesn't have to decode up to the requested point.)Īnother possibly relevant option is -seek2any, but it says "seek to non-keyframe on demuxer level", which sounds like it would let you seek in ways that would produce garbled output. Maybe -accurate_seek is the default? I also get the same result (byte-for-byte identical gif output) as when I use a ffvhuff lossless source as input. Wasn't just a coincidence of an I frame where I wanted one. It's NOT all I frames, it's P frames with a normal keyframe interval.Īdjusting -ss by 0.2 secs did exactly what I hoped, so ffmpeg must handle decoding up to the required point.
The source is a lossless x264 encode ( -qp 0) from the output of a very slow yadif=3:1,mcdeint=3:1:10 (on some BFF interlaced video from an NTSC DVD, probably from a DV camera). Neither opus nor pcm_s16le can go in mp4, so I used an mkv container for this example. On startup, it takes fraction of a second for the audio to get ahead of the video by that offset, and until then the video is playing at very low FPS. It probably grabs audio from the beginning of the audio frame containing the start, and then has to use a a/v offset in the container. With -c:a copy (source has AC3 audio), playback starts up wonky with mplayer. mkv -c:a libopus -shortest -aspect 16:9 -preset veryslow -x264-params nr=250:ref=6 -crf 22 -movflags +faststart clip2.mkv (actually tweaked to be a better example, since I left in audio for this, and didn't slo-mo it.)įfmpeg -ss 120.2 -t 0.75 -i. Here's a command line I used to make a clip recently. When including audio in the output, I had to use -shortest as an option for the output file, or I'd get 2 mins of audio with 2 secs of video.įfmpeg version N-67413-g2a88c74 (basically git source from Dec 14 2014) Used correctly, before the input file they're meant to apply to, -ss and -t worked fine for me. It's often not obvious where an option needs to go, so sometimes trial and error is required. Most ffmpeg options aren't global, but instead only apply to the file they precede. I think the problem the question and other answers are having is that they're using -ss as an option on the output file, not on the input file.
0 kommentar(er)
