Cutting out part of a video does not work

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Cutting out part of a video does not work

FFmpeg-users mailing list
Peter White <[hidden email]> writes:

> On Sat, Mar 27, 2021 at 06:18:59AM +0100, Cecil Westerhof via ffmpeg-user wrote:
>> Peter White <[hidden email]> writes:
>>
>> > On Fri, Mar 26, 2021 at 05:28:40PM +0100, Cecil Westerhof via ffmpeg-user wrote:
>> >> Peter White <[hidden email]> 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. (If I do not my processor
gets to hot and the computer shuts down.) There I use crf 23, maybe I
should redefine that to 16.


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


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

--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Cutting out part of a video does not work

Bo Berglund
In reply to this post by Peter White
On Sat, 27 Mar 2021 02:50:13 +0100, Peter White <[hidden email]> wrote:

>> I tested your command ona typical video file and found that the output looks
>> basically like this:
>>
>> [FRAME]
>> best_effort_timestamp_time=3900.000000
>> [/FRAME]
>> [FRAME]
>> best_effort_timestamp_time=3905.000000
>> [/FRAME]
>> [FRAME]
>> best_effort_timestamp_time=3910.000000
>> [/FRAME]
>> [FRAME]
>> best_effort_timestamp_time=3915.000000
>> [/FRAME]
>>
>> It seems like there are "frames" at every 5 seconds.
>
>Not to be picky, but there are certainly very many more frames. The
>distinction is between *keyframes* and everything else called a frame.
>
Of course this is not the entire output! It streams past at high speed so covers
many many pages.
But it all looks the same with the time incrementing at exactly 5 seconds...


--
Bo Berglund
Developer in Sweden

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Cutting out part of a video does not work

Bo Berglund
In reply to this post by FFmpeg-users mailing list
On Sat, 27 Mar 2021 08:29:26 +0100, Cecil Westerhof via ffmpeg-user
<[hidden email]> wrote:

>Before working with the video I narrowed it. (If I do not my processor
>gets to hot and the computer shuts down.) There I use crf 23, maybe I
>should redefine that to 16.
>
I also encountered overheating and shutdown when using ffmpeg.
Turns out I had to blow out all of the dust accumulated inside the cooling
system on my HP 8440w with compressed air. After that the computer did no longer
shut down even though it revved up the fan to max.

Worth a check of your computer.
It should be able to run at 100% CPU for quite a while in normal surroundings
(if the air flow is not obstructed, please check the inlets on the underside of
the laptop).

--
Bo Berglund
Developer in Sweden

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Cutting out part of a video does not work

FFmpeg-users mailing list
Bo Berglund <[hidden email]> writes:

> On Sat, 27 Mar 2021 08:29:26 +0100, Cecil Westerhof via ffmpeg-user
> <[hidden email]> wrote:
>
>>Before working with the video I narrowed it. (If I do not my processor
>>gets to hot and the computer shuts down.) There I use crf 23, maybe I
>>should redefine that to 16.
>>
> I also encountered overheating and shutdown when using ffmpeg.

The problem is not ffmpeg, but playing videos with mpv. Especially if
Firefox is also running.


> Turns out I had to blow out all of the dust accumulated inside the cooling
> system on my HP 8440w with compressed air. After that the computer did no longer
> shut down even though it revved up the fan to max.

Did already look at that, but seems OK.


> Worth a check of your computer.
> It should be able to run at 100% CPU for quite a while in normal surroundings
> (if the air flow is not obstructed, please check the inlets on the underside of
> the laptop).

Running ffmpeg with 100% CPU is not a problem. But running mpv with
60% CPU is. I find this quit weird.

--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Cutting out part of a video does not work

Peter White
In reply to this post by FFmpeg-users mailing list
On Sat, Mar 27, 2021 at 08:29:26AM +0100, Cecil Westerhof via ffmpeg-user wrote:

> Peter White <[hidden email]> writes:
>
> > On Sat, Mar 27, 2021 at 06:18:59AM +0100, Cecil Westerhof via ffmpeg-user wrote:
> >> Peter White <[hidden email]> writes:
> >>
> >> > On Fri, Mar 26, 2021 at 05:28:40PM +0100, Cecil Westerhof via ffmpeg-user wrote:
> >> >> Peter White <[hidden email]> 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
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Cutting out part of a video does not work

Peter White
In reply to this post by FFmpeg-users mailing list
On Sat, Mar 27, 2021 at 09:39:38AM +0100, Cecil Westerhof via ffmpeg-user wrote:
> Bo Berglund <[hidden email]> writes:
>
> > Worth a check of your computer.
> > It should be able to run at 100% CPU for quite a while in normal surroundings
> > (if the air flow is not obstructed, please check the inlets on the underside of
> > the laptop).
>
> Running ffmpeg with 100% CPU is not a problem. But running mpv with
> 60% CPU is. I find this quit weird.

That is quite unusual. Are you by any chance using hardware acceleration
in mpv? 60% CPU tells me, the answer is probably no, but maybe it is yes
and can explain overheating because GPU usage is not prominently
reported, so you might not see that the actual heat is caused by a busy
GPU not the CPU.

Anyway, overheating and shutdown because of it definitely points to a
problem in your cooling. But this is out of scope for this mailing list,
I guess, since it is unrelated to ffmpeg.


Cheers,
Peter
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Cutting out part of a video does not work

Peter White
In reply to this post by Bo Berglund
On Sat, Mar 27, 2021 at 09:13:10AM +0100, Bo Berglund wrote:

> On Sat, 27 Mar 2021 02:50:13 +0100, Peter White <[hidden email]> wrote:
>
> >> I tested your command ona typical video file and found that the output looks
> >> basically like this:
> >>
> >> [FRAME]
> >> best_effort_timestamp_time=3900.000000
> >> [/FRAME]
> >> [FRAME]
> >> best_effort_timestamp_time=3905.000000
> >> [/FRAME]
> >> [FRAME]
> >> best_effort_timestamp_time=3910.000000
> >> [/FRAME]
> >> [FRAME]
> >> best_effort_timestamp_time=3915.000000
> >> [/FRAME]
> >>
> >> It seems like there are "frames" at every 5 seconds.
> >
> >Not to be picky, but there are certainly very many more frames. The
> >distinction is between *keyframes* and everything else called a frame.
> >
> Of course this is not the entire output! It streams past at high speed so covers
> many many pages.

That I did understand. I just wanted to be extra clear that there most
certainly are many more *non-key* frames between those keyframes listed
above, usually motion pictures have at least 24 frames per second.

> But it all looks the same with the time incrementing at exactly 5 seconds...

Looks like someone took extra care to have a static keyframe interval.
One can do that. With default codec options x264 won't produce such
output though.


Cheers,
Peter
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Cutting out part of a video does not work

Bo Berglund
On Sat, 27 Mar 2021 10:06:03 +0100, Peter White <[hidden email]> wrote:

>> But it all looks the same with the time incrementing at exactly 5 seconds...
>
>Looks like someone took extra care to have a static keyframe interval.
>One can do that. With default codec options x264 won't produce such
>output though.
>

The source is using a youtube URL for the streaming video and I use either
youtube-dl or ffmpeg directly to get it in my scripts.

Is the fact that the times are so exact indication of recoding by Youtube, or is
the source like that?
I really have no idea how Youtube video streaming works, I just use YouTube if
that is the source...
And I have never published any video on Youtube so I don't know the process.


--
Bo Berglund
Developer in Sweden

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Cutting out part of a video does not work

Peter White
On Sat, Mar 27, 2021 at 05:18:18PM +0100, Bo Berglund wrote:

> On Sat, 27 Mar 2021 10:06:03 +0100, Peter White <[hidden email]> wrote:
>
> >> But it all looks the same with the time incrementing at exactly 5 seconds...
> >
> >Looks like someone took extra care to have a static keyframe interval.
> >One can do that. With default codec options x264 won't produce such
> >output though.
> >
>
> The source is using a youtube URL for the streaming video and I use either
> youtube-dl or ffmpeg directly to get it in my scripts.
>
> Is the fact that the times are so exact indication of recoding by Youtube, or is
> the source like that?

I believe this has to do with multi-bitrate streaming. I have recently
read some guidelines about preparing videos for that. One recommendation
is to use rather small GOP (group of pictures) sizes, thus small
keyframe intervals. Some go as far as recommending static GOP sizes.
From my understanding it is not a hard requirement. Like cutting, one
can only switch to a different stream, from 720p to 1080p, on a
keyframe, hence above recommendation for short intervals.

> I really have no idea how Youtube video streaming works, I just use YouTube if
> that is the source...
> And I have never published any video on Youtube so I don't know the process.

Then you need not bother with keyframe intervals. Let the codec make the
decisions, which gives a rather good tradeoff between seekability
(keyframe interval) and size. The more unnecessary keyframes there are,
maybe even at fixed intervals, the more wasteful is the result, as in
bigger than necessary.


Cheers,
Peter
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Cutting out part of a video does not work

FFmpeg-users mailing list
In reply to this post by Bo Berglund
Bo Berglund <[hidden email]> writes:

> On Sat, 27 Mar 2021 10:06:03 +0100, Peter White <[hidden email]> wrote:
>
>>> But it all looks the same with the time incrementing at exactly 5 seconds...
>>
>>Looks like someone took extra care to have a static keyframe interval.
>>One can do that. With default codec options x264 won't produce such
>>output though.
>>
>
> The source is using a youtube URL for the streaming video and I use either
> youtube-dl or ffmpeg directly to get it in my scripts.
>
> Is the fact that the times are so exact indication of recoding by Youtube, or is
> the source like that?
> I really have no idea how Youtube video streaming works, I just use YouTube if
> that is the source...
> And I have never published any video on Youtube so I don't know the process.

I know from experience that Youtube automatically transcodes uploaded
videos from unpaid sources (e.g. me). It likely does the same for paid
sources. After all, youtube streams at various resolutions, etc.

Leo
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
12