Hacker News Reader

Comment by gsnedders | Hacker News Reader

What happens when the start time doesn't match up with a keyframe? Presumably some re-encoding has to happen there?

Don’t quote me on this, but I think ffmpeg lets you choose between starting at the nearest Iframe or re-encoding the first GOP.

I believe by default it snaps to the nearest iframe. At least that's been my experience.

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.

No it is possible, but the -ss needs to be after the -i not before:

https://ffmpeg.org/ffmpeg.html#Main-options

> -ss position (input/output)

> 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).

There is no provision for partial stream encoding. It's either complete streamcopy or encoding.

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

Coincidentally, I refined the above approach very recently and posted the result to my own blog: https://csrd.science/blag/2020/trimming-an-h264-video-and-pr...

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.

I have used a similar command, maybe the same thing, and had an issue where audio didn't sync to video in some cases.

It was an instant processing thing but I don't remember for sure if it was the same command.

It will just start at the closest keyframe I believe.

Certainly if the duration specified doesn't land you on a key frame it also ends at the closest keyframe.

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.

Agreed. The post was written for an audience that doesn't care about exact frame editing.

Would the following work?

# Calculate the exact start time (in s.msec format) via: START = start_frame_number/frames_per_second

ffmpeg -ss $START -i video.mp4 -c copy -map 0 -frames 1400 output.mp4

Afaik ffmpeg requires a specific option to disable snapping to key frames. Don't remember which, but it can be easily found with a web search.

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.

A friend = lots of devs

Screencasts don't need frame precision fortunately. A set up that isn't completely polished also feels more authentic.

You may want to use -noaccurate_seek

Reply on news.ycombinator.com