HEVC video cutting issues using FFmpeg

Question

I need to cut videos using FFmpeg and I cannot transcode original videos (because of the performance reason). And I ran into a problem with HEVC videos from IPhone: there are glithes in the beginning of the cutted video.

Here is how we converted videos before issue:

ffmpeg.exe -i original.MOV -c:v copy -c:a aac -ss 4 -y good.mp4

But for HEVC video there are glitches for 1 second in the beginning of the cutted video:

Then I've tried to put seek option before input video:

ffmpeg.exe -ss 4 -i original.MOV -c:v copy -c:a aac -y good.mp4

The result seems good:

After some googling it turns out that -ss option before input is faster but less accurate whereas -ss option after input and before output is slower but more accurate.

So my questions are:

• Why -ss option behaves differently then it is put before/after input?

• Is there a way to avoid glitches using output seek ffmpeg option?

• What does 'more/less accurate' mean? Does it mean that the seek may be too big or to little (bigger/less than we specified)? How big may be this difference?

Answer 1

Why -ss option behaves differently then it is put before/after input?

When used as an input option ( -ss … -i … ), ffmpeg first seeks to the specified position in the input stream and then starts decoding the frames.

When used after the input ( -i ), ffmpeg will decode the stream from the beginning and discard all frames that precede the given timestamp.

Note that normally the timestamps are reset when using -ss before -i , meaning that:

• -ss 10 -i … -t 10 produces a 10-second clip starting from 00:00:10,
• -i … -ss 10 -to 20 does the same,
• -ss 10 -i … -to 10 does the same.

Is there a way to avoid glitches using output seek ffmpeg option?

Yes. There should be no glitches at all when transcoding, as the stream will be first decoded, including all needed previous frames, even if not inside the seeking range. Then, transcoding starts and new timestamps will be assigned to the output frames.

What does 'more/less accurate' mean? Does it mean that the seek may be too big or to little (bigger/less than we specified)? How big may be this difference?

Before FFmpeg 2.1, this was a bigger issue, but now seeking before the input option is accurate when you transcode. See the Seeking wiki entry for more info.

The accuracy question only applies to stream copying ( -c copy ). Here, you can only start producing valid output from a keyframe ; all previous frames are useless.

Hence, if you have keyframes at, for example, seconds 2, 4, 6, …, but you specify cutting at second 5, ffmpeg will only be able to produce output from second 6. It will however include the frames from seconds 5–6, albeit with a negative timestamp, so that they won't be shown by the decoder.

This is where glitches might happen. Decoders do not respect these negative timestamps and still show the frames, which then appear broken, since the previous keyframe is not part of the stream. Some decoders might only play audio and show no video.

In such cases, it's best to transcode the video.