5 ms·

The ultimate guide for me would include how to extract a short clip from a longer video specifying the start time in (minutes:)seconds and the duration or, alte

by narag 4y ago

The ultimate guide for me would include how to extract a short clip from a longer video specifying the start time in (minutes:)seconds and the duration or, alternatively, stop time. Actually I created a GUI to do exactly that, calling the ffmpeg executable. So? It doesn't work as it should. Depending in what point you start, you will find a very noticeable interval with black video. I do understand why it happens, but that's not the point.

hnarn 4y ago
handbrake-cli does this well but the syntax for begin and end timestamps is pretty confusing when combined
deleted 4y ago
[deleted]
Wowfunhappy 4y ago
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.)
- antegamisou 4y ago
  See also: Cutting the videos based on start and end time using ffmpeg https://stackoverflow.com/a/18449609 https://stackoverflow.com/a/18449609
  - narag 4y ago
    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.
    - pessimizer 4y ago
      https://superuser.com/questions/138331/using-ffmpeg-to-cut-up-video/704118#704118 https://superuser.com/questions/138331/using-ffmpeg-to-cut-u... Looks like the ordering of the parameters makes a difference.
      - narag 4y ago
        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.
        pessimizer 4y ago
        I understand the problem. >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.
- narag 4y ago
  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.
  - Wowfunhappy 4y ago
    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.
    - narag 4y ago
      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!
- btdmaster 4y ago
  Maybe avoid_negative_ts[0] would work? [0] https://video.stackexchange.com/a/18285 https://video.stackexchange.com/a/18285
sylware 4y ago
GUI frontend to command line is "why" the command line output should be machine parseable, I think this is true for most of relevant ffmpeg output.
pessimizer 4y ago
-ss <start time> AND (-t <duration> OR -to <end time>) edit: https://shotstack.io/learn/use-ffmpeg-to-trim-video/ https://shotstack.io/learn/use-ffmpeg-to-trim-video/

by narag 4y ago

hnarn 4y ago

handbrake-cli does this well but the syntax for begin and end timestamps is pretty confusing when combined

deleted 4y ago

[deleted]

Wowfunhappy 4y ago

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

antegamisou 4y ago
See also: Cutting the videos based on start and end time using ffmpeg https://stackoverflow.com/a/18449609 https://stackoverflow.com/a/18449609
- narag 4y ago
  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.
  - pessimizer 4y ago
    https://superuser.com/questions/138331/using-ffmpeg-to-cut-up-video/704118#704118 https://superuser.com/questions/138331/using-ffmpeg-to-cut-u... Looks like the ordering of the parameters makes a difference.
    - narag 4y ago
      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.
      - pessimizer 4y ago
        I understand the problem. >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.
narag 4y ago
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.
- Wowfunhappy 4y ago
  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.
  - narag 4y ago
    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!
btdmaster 4y ago
Maybe avoid_negative_ts[0] would work? [0] https://video.stackexchange.com/a/18285 https://video.stackexchange.com/a/18285

sylware 4y ago

GUI frontend to command line is "why" the command line output should be machine parseable, I think this is true for most of relevant ffmpeg output.

pessimizer 4y ago

-ss <start time> AND (-t <duration> OR -to <end time>) edit: https://shotstack.io/learn/use-ffmpeg-to-trim-video/ https://shotstack.io/learn/use-ffmpeg-to-trim-video/