Are you using -codec copy? If so, this happens because (most) frames in modern codecs are not discrete. They rely on information from previous frames to construct the image.
If you cut a stream in the middle, it takes many frames before there's enough information to be displayed.
(The solution would be to re-encode up until the first discrete "keyframe"... and I don't know how to do that with ffmpeg.)
Thanks, I see there's talking about the frames problem, but not sure if it's just solved in a new version or I should change some parameters, I'll give it a try next time I need to use the program.
That seems another different issue. The problem, as Wowfunhappy explained, is that the codecs compress the frames making a diff with the previous frames. So if you start in a frame that depends on other frames that you don't want to include in the clip, there's information missing. The result is that the clip starts playing the sound, but with all-black video for a few seconds.
In the previous link there are a couple of solutions that might work. One is "recoding", that's somehow ambiguous: could be understood as changing the codec, but also making a new compression from the decompressed frames.
I have the program in another computer so I can't test it now, but I certainly will.
>Also note this important point from that page: "If you use -ss with -c:v copy, the resulting bitstream might end up being choppy, not playable, or out of sync with the audio stream, since ffmpeg is forced to only use/split on i-frames."
> This means you need to re-encode the video, even if you want to just copy it, or risk it being choppy and out of sync. You could try just -c copy first, but if the video sucks you'll need to re-do it.
From the link.
-----
edit: if it aids understanding, I think i-frame means "interpolated frame" i.e. frame that depends on the previous and next frames.
edit2: and "-c:v copy" means don't transcode (or "recode" as you say) the video, but simply copy it.
I didn't use anything that was not obviously neeeded. What you say about previous frames was also my guess, but that doesn't seem a reasonable behaviour to me.
If ffmpeg needs more information, it should take it. That's what the logic in the parameters say. Instead of that it forces me to include some seconds that I don't want in the clip or blackening the video, both of them useless results.
Well that's why I thought you must have specified `-codec copy`. If you force ffmpeg to not re-encode the video, and also cut the video, it will perform that impossible action as best it can.
But I legitimately don't know why that would happen otherwise. Usually it defaults to re-encoding when I use it.
It's been a couple of years at least, so it isn't fresh. I don't remember anything about dealing with codecs. Anyway, it seems from all the links that using some re-encoding option will fix it. Thanks again!
If you cut a stream in the middle, it takes many frames before there's enough information to be displayed.
(The solution would be to re-encode up until the first discrete "keyframe"... and I don't know how to do that with ffmpeg.)