[FFmpeg-user] Cutting out part of a video does not work

[Peter White]

On Sat, Mar 27, 2021 at 08:29:26AM +0100, Cecil Westerhof via ffmpeg-user wrote:
> Peter White <peter.white at posteo.net> writes:
> 
> > On Sat, Mar 27, 2021 at 06:18:59AM +0100, Cecil Westerhof via ffmpeg-user wrote:
> >> Peter White <peter.white at posteo.net> writes:
> >> 
> >> > On Fri, Mar 26, 2021 at 05:28:40PM +0100, Cecil Westerhof via ffmpeg-user wrote:
> >> >> Peter White <peter.white at posteo.net> writes:
> >> >> 
> >> >> > On Fri, Mar 26, 2021 at 09:55:21AM +0100, Cecil Westerhof via ffmpeg-user wrote:
> >> >> >> I want to publish a speech I gave during a Zoom meeting. But cutting
> >> >> >> it out does not work.
> >> >> >> 
> >> >> >> When I use:
> >> >> >>     ffmpeg -y -i 2021-03-25ToastmastersClubAvond.mp4 -ss 1190 -to 1631
> >> >> >> -acodec copy -vcodec copy -async 1 speech.mp4
> >> >> >> 
> >> >> >> The video starts just a bit to late. But when I use:
> >> >> >>     ffmpeg -y -i 2021-03-25ToastmastersClubAvond.mp4 -ss 1185 -to 1631
> >> >> >> -acodec copy -vcodec copy -async 1 speech.mp4
> >> >> >> 
> >> >> >
> >> >> > If you can live with further quality loss in the video, you can
> >> >> > transcode it, i.e. -c:v libx264.
> >> >> >
> >> >> 
> >> >> I now use:
> >> >>     ffmpeg -y -ss 1189 -i 2021-03-25ToastmastersClubAvond.mp4 -to 442
> >> >> -acodec copy -vcodec libx264 -crf 8 -async 1 speech.mp4
> >> >
> >> > CRF 8 seems excessive. Try 16 for a start. From various online sources I
> >> > gathered that it is pretty much transparent, as in no noticeable
> >> > difference to the original. My own experience shows the same.
> >> 
> >> So crf is useful? (Other post said not.) I am now running it without
> >> crf (and async). When it is finished I will try it with crf 16.
> >
> > I am pretty certain Carl Eugen also meant that CRF 8 is excessive for
> > no visible gain in quality. From the documentation of x264 I remember
> > that an decrement of 1 results in a size increase of the video of
> > roughly 12.5 %, so when you use 8 instead of 16 that is 1.125 to the
> > power of 8 the size of the same video encoded with CRF 16, so roughly
> > 2.5 times the size. And you won't notice the difference. Might even try
> > higher values for CRF. Since I, personally, are very conscious about not
> > losing any quality, I use 16. But even that might be too conservative.
> > Consider it a rough ball park figure to get you started.
> 
> Before working with the video I narrowed it.

Do you mean, that you already transcoded it before cutting? That should
be avoided, because of the propagation of losses.

> (If I do not my processor gets to hot and the computer shuts down.)

You should do something about cooling then. Or, since you are using
Debian, you could use the powersave CPU frequency governor, i.e.:

# cpupower -c all frequency-set --governor powersave

This should mitigate the overheating issue for the time being, but it
will most certainly slow down the encoding process.

> There I use crf 23, maybe I should redefine that to 16.

CRF 23 should run a bit faster since the codec takes some more
"shortcuts". At least that is my experience. If the quality is
acceptable, that is perfectly fine. As I said, I am rather conservative
in that regard.

> >> >> This takes about 8 minutes instead of a second. But I have to live
> >> >> with that.
> >> >
> >> > You could try to do this in multiple stages, maybe. Only transcode the
> >> > first few seconds up to the next keyframe and then stitch that and the
> >> > copied rest together. In theory this should work, but may be not as easy
> >> > to achieve. Obviously the codecs, frame rates and resolutions need to
> >> > match. I guess codec parameters need to match as well, not sure. The
> >> > question is if it is worth the effort.
> >> 
> >> I was thinking about a variant of this. Create a few seconds of the
> >> start and a few seconds of the end until I entered the correct values
> >> and then generate the complete file.
> >
> > Don't worry about the end, because there is no restriction on what kind
> > of frame is allowed there. The encoder will simply stop encoding.
> 
> I need to. ;-) If it is wrong I need to enter a better one an convert
> again.

What I mean is: you do not need to take extra care for the end of the
video, not even with the copy codec, because there is no restriction on
the frame type for the end. The reason for having to start on a keyframe
is that only that type of frame is an actual full picture. Others
following and referencing a keyframe basically only contain the
differences, greatly reducing the size. Since the last frame must have a
keyframe somewhere before itself, there is no problem, because the whole
picture can be reconstructed.

And if you only need to cut something off the end, but the start is
correct, you can simply use the copy codec. The problem (keyframe) only
exists, if you need to use -ss, which won't be the case for trimming the
end.

> >> It seems that without crf the video is generated faster. It now only
> >> took five minutes. (But maybe my computer was doing less.) It is a lot
> >> smaller: 41.5 MB instead of 147.8 MB.
> >
> > Have a look at the defaults of the x264 encoder. If memory serves, CRF
> > is 23 by default and you will most certainly notice artifacts,
> > especially since you are transcoding from one lossy format to another,
> > because losses propagate.
> >
> >> Now trying with crf 16. And then comparing the video quality.
> >
> > You will see a difference between not specifying CRF and 16. I am pretty
> > sure about that. ;)
> 
> I did not, but that is probably because I already did a conversion
> with crf 23.

As I said above, you should avoid multiple transcoding stages. If I
understand "narrowed it" correctly, you mean cropping the black borders?
You can do that in one go with transcoding the original and cutting,
i.e.:

    ffmpeg -ss start -to end -i input -c copy -c:V libx264 -filter:V crop...


Cheers,
Peter