Cutting out part of a video does not work

[FFmpeg-users mailing list]

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

which is five seconds earlier. I get the same output.

Am I doing something wrong?


Output:
ffmpeg version 4.1.6-1~deb10u1 Copyright (c) 2000-2020 the FFmpeg developers
  built with gcc 8 (Debian 8.3.0-6)
  configuration: --prefix=/usr --extra-version='1~deb10u1' --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --enable-avresample --disable-filter=resample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librsvg --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared
  libavutil      56. 22.100 / 56. 22.100
  libavcodec     58. 35.100 / 58. 35.100
  libavformat    58. 20.100 / 58. 20.100
  libavdevice    58.  5.100 / 58.  5.100
  libavfilter     7. 40.101 /  7. 40.101
  libavresample   4.  0.  0 /  4.  0.  0
  libswscale      5.  3.100 /  5.  3.100
  libswresample   3.  3.100 /  3.  3.100
  libpostproc    55.  3.100 / 55.  3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '2021-03-25ToastmastersClubAvond.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 0
    compatible_brands: isommp42
    creation_time   : 2021-03-25T19:02:11.000000Z
  Duration: 01:34:26.16, start: 0.000000, bitrate: 2198 kb/s
    Chapter #0:0: start 0.000000, end 4016.120000
    Metadata:
      title           : Recording Started
    Chapter #0:1: start 4016.120000, end 4048.200000
    Metadata:
      title           : Sharing Started
    Chapter #0:2: start 4048.200000, end 5666.160000
    Metadata:
      title           : Sharing Stopped
    Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 32000 Hz, mono, fltp, 126 kb/s (default)
    Metadata:
      creation_time   : 2021-03-25T19:02:11.000000Z
      handler_name    : AAC audio
    Stream #0:1(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080, 2070 kb/s, 25 fps, 25 tbr, 30k tbn, 60k tbc (default)
    Metadata:
      creation_time   : 2021-03-25T19:02:11.000000Z
      handler_name    : H.264/AVC video
      encoder         : AVC Coding
    Stream #0:2(und): Data: bin_data (text / 0x74786574)
    Metadata:
      creation_time   : 2021-03-25T19:02:11.000000Z
      handler_name    : Text
Output #0, mp4, to 'speech.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 0
    compatible_brands: isommp42
    encoder         : Lavf58.20.100
    Chapter #0:0: start 0.000000, end 446.000000
    Metadata:
      title           : Recording Started
    Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080, q=2-31, 2070 kb/s, 25 fps, 25 tbr, 30k tbn, 30k tbc (default)
    Metadata:
      creation_time   : 2021-03-25T19:02:11.000000Z
      handler_name    : H.264/AVC video
      encoder         : AVC Coding
    Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 32000 Hz, mono, fltp, 126 kb/s (default)
    Metadata:
      creation_time   : 2021-03-25T19:02:11.000000Z
      handler_name    : AAC audio
Stream mapping:
  Stream #0:1 -> #0:0 (copy)
  Stream #0:0 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame=    0 fps=0.0 q=-1.0 size=       0kB time=00:00:00.00 bitrate=N/A speed=   0x    .frame= 2057 fps=2057 q=-1.0 size=   39168kB time=00:01:27.80 bitrate=3654.5kbits/s speed=87.8x    .frame= 7885 fps=5256 q=-1.0 size=  154112kB time=00:05:21.27 bitrate=3929.6kbits/s speed= 214x    .frame=11017 fps=5760 q=-1.0 Lsize=  232009kB time=00:07:25.97 bitrate=4261.7kbits/s speed= 233x    
video:224885kB audio:6873kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.107917%

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

[Michael Koch]

Am 26.03.2021 um 09:55 schrieb Cecil Westerhof via ffmpeg-user:

> 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
>
> which is five seconds earlier. I get the same output.
>
> Am I doing something wrong?

Without re-encoding you can only cut at keyframes.
If you want to cut at exact times, you must remove -acodec copy and
-vcodec copy

Michael

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

[Peter White]

On Fri, Mar 26, 2021 at 10:07:14AM +0100, Michael Koch wrote:

> Am 26.03.2021 um 09:55 schrieb Cecil Westerhof via ffmpeg-user:
> > 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
> >
> > which is five seconds earlier. I get the same output.
> >
> > Am I doing something wrong?
>
> Without re-encoding you can only cut at keyframes.
> If you want to cut at exact times, you must remove -acodec copy and -vcodec
> copy

-acodec copy should be fine.


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

[Peter White]

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
>
> which is five seconds earlier. I get the same output.
>
> Am I doing something wrong?

This is the expected outcome, because, due to the nature of lossy video
codecs, one can only start on keyframes. Please have a look at the
description of the -ss option for further details

>     Stream #0:1(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080, 2070 kb/s, 25 fps, 25 tbr, 30k tbn, 60k tbc (default)
>     Metadata:
>       creation_time   : 2021-03-25T19:02:11.000000Z
>       handler_name    : H.264/AVC video
>       encoder         : AVC Coding

This is a lossy codec.

If you can live with further quality loss in the video, you can
transcode it, i.e. -c:v libx264.

Or you can set the start point some seconds further back. This way you
will not get the perfect cut but at least you do not lose anything of
the content you want.

You can use ffprobe to find the keyframe timestamps:

ffprobe -select_streams V:0 -show_frames -skip_frame nokey -show_entries frame=best_effort_timestamp_time 2021-03-25ToastmastersClubAvond.mp4


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

[Peter White]

On Fri, Mar 26, 2021 at 10:59:23AM +0100, Peter White wrote:
> If you can live with further quality loss in the video, you can
> transcode it, i.e. -c:v libx264.

Forgot one thing. You can, and maybe should, use -ss as an input option.
This way ffmpeg does not decode the whole file until it reaches the cut
point. It will be an accurate cut if you use a real codec as opposed to
the copy codec. Again, see -ss and -accurate_seek for more details.


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

[Bo Berglund]

On Fri, 26 Mar 2021 10:59:23 +0100, Peter White <[hidden email]> wrote:

>You can use ffprobe to find the keyframe timestamps:
>
>ffprobe -select_streams V:0 -show_frames -skip_frame nokey -show_entries frame=best_effort_timestamp_time 2021-03-25ToastmastersClubAvond.mp4
>

Interesting, I have wondered about why my ffmpeg cut engine does not give me
clean cuts...

I tested your command ona typical video file and found thta 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.
So on such videos is it impossible to cut say from time 2603 to 3401 and get a
video of length 798 seconds?

What does ffmpeg do?
Does it skip to the closest frame border or does it include both the starting
and ending frame so giving a video time of 805 seconds?

Switching from the copy handler to something else makes ffmpeg work a lot harder
and processing time goes from 5 seconds to 30 minutes or so....


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

[FFmpeg-users mailing list]

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
>>
>> which is five seconds earlier. I get the same output.
>>
>> Am I doing something wrong?
>
> This is the expected outcome, because, due to the nature of lossy video
> codecs, one can only start on keyframes. Please have a look at the
> description of the -ss option for further details
>
>>     Stream #0:1(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p,
>> 1920x1080, 2070 kb/s, 25 fps, 25 tbr, 30k tbn, 60k tbc (default)
>>     Metadata:
>>       creation_time   : 2021-03-25T19:02:11.000000Z
>>       handler_name    : H.264/AVC video
>>       encoder         : AVC Coding
>
> This is a lossy codec.
>
> If you can live with further quality loss in the video, you can
> transcode it, i.e. -c:v libx264.
>
> Or you can set the start point some seconds further back. This way you
> will not get the perfect cut but at least you do not lose anything of
> the content you want.

No, that I cannot do. I cannot publish stuff containing other people.

I now use:
    ffmpeg -y -ss 1189 -i 2021-03-25ToastmastersClubAvond.mp4 -to 442 -acodec copy -vcodec libx264 -crf 8 -async 1 speech.mp4

This takes about 8 minutes instead of a second. But I have to live
with that.


There is only one problem. The video is 7:21 long, but both mpv and
vlc think it is 7:30 long.

And even ffprobe does think that:
ffprobe version 4.1.6-1~deb10u1 Copyright (c) 2007-2020 the FFmpeg developers
  built with gcc 8 (Debian 8.3.0-6)
  configuration: --prefix=/usr --extra-version='1~deb10u1' --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --enable-avresample --disable-filter=resample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librsvg --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared
  libavutil      56. 22.100 / 56. 22.100
  libavcodec     58. 35.100 / 58. 35.100
  libavformat    58. 20.100 / 58. 20.100
  libavdevice    58.  5.100 / 58.  5.100
  libavfilter     7. 40.101 /  7. 40.101
  libavresample   4.  0.  0 /  4.  0.  0
  libswscale      5.  3.100 /  5.  3.100
  libswresample   3.  3.100 /  3.  3.100
  libpostproc    55.  3.100 / 55.  3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'speech.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf58.20.100
  Duration: 00:07:30.90, start: 0.000000, bitrate: 2750 kb/s
    Chapter #0:0: start 0.000000, end 442.000000
    Metadata:
      title           : Recording Started
    Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1024x576, 2765 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)
    Metadata:
      handler_name    : H.264/AVC video
    Stream #0:1(und): Audio: mp3 (mp4a / 0x6134706D), 32000 Hz, mono, fltp, 34 kb/s (default)
    Metadata:
      handler_name    : AAC audio
    Stream #0:2(eng): Data: bin_data (text / 0x74786574)
    Metadata:
      handler_name    : SubtitleHandler
Unsupported codec with id 100359 for input stream 2

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

[Carl Zwanzig]

On 3/26/2021 9:28 AM, Cecil Westerhof via ffmpeg-user wrote:

> No, that I cannot do. I cannot publish stuff containing other people.

Well you -can-, may not want to.

> There is only one problem. The video is 7:21 long, but both mpv and
> vlc think it is 7:30 long.

IME, the metadata length often lies. When you say it's 7:21, is that exactly
how long it plays for or how long it ought to be?

> ffprobe version 4.1.6-1~deb10u1 Copyright (c) 2007-2020 the FFmpeg developers

That's an older version, even though it wouldn't help on this, it's always
best to check with as current as you can get.

z!
_______________________________________________
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".

[FFmpeg-users mailing list]

Carl Zwanzig <[hidden email]> writes:

> On 3/26/2021 9:28 AM, Cecil Westerhof via ffmpeg-user wrote:
>
>> No, that I cannot do. I cannot publish stuff containing other people.
>
> Well you -can-, may not want to.

I used cannot in the sense that I am not allowed to. ;-)


>> There is only one problem. The video is 7:21 long, but both mpv and
>> vlc think it is 7:30 long.
>
> IME, the metadata length often lies. When you say it's 7:21, is that
> exactly how long it plays for or how long it ought to be?

I almost never have this. (If I remember well, only with videos
created with ffmpeg. Sometimes it started on a negative timestamp
instead of 00:00:00.)

Looking at the -to you would expect 7:22, but when I just play it, it
ends at 7:21.


>> ffprobe version 4.1.6-1~deb10u1 Copyright (c) 2007-2020 the FFmpeg developers
>
> That's an older version, even though it wouldn't help on this, it's
> always best to check with as current as you can get.

I am using Debian (stable). That always uses older versions.
I could look if there is a newer version in backports.

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

[Carl Eugen Hoyos-2]

Am Fr., 26. März 2021 um 17:28 Uhr schrieb Cecil Westerhof via
ffmpeg-user <[hidden email]>:

> ffmpeg -y -ss 1189 -i 2021-03-25ToastmastersClubAvond.mp4
> -to 442 -acodec copy -vcodec libx264 -crf 8 -async 1 speech.mp4

The x264 documentation states that there is no good
reason to use "crf 8" and please don't use "acodec copy"
with "async 1", these two options are exclusive.

Carl Eugen
_______________________________________________
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".

[Peter White]

On Fri, Mar 26, 2021 at 04:40:26PM +0100, Bo Berglund wrote:

> On Fri, 26 Mar 2021 10:59:23 +0100, Peter White <[hidden email]> wrote:
>
> >You can use ffprobe to find the keyframe timestamps:
> >
> >ffprobe -select_streams V:0 -show_frames -skip_frame nokey -show_entries frame=best_effort_timestamp_time 2021-03-25ToastmastersClubAvond.mp4
> >
>
> I tested your command ona typical video file and found thta 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.

> So on such videos is it impossible to cut say from time 2603 to 3401 and get a
> video of length 798 seconds?

Extrapolating from your above example, yes and no. If there is a
keyframe every five seconds, there is none at 2603, so you would need to
either start at 2600 or 2605. You can, however, make the video 768
seconds long, because the last frame need not be a keyframe. Or you
could cut the end short at 3401 seconds, no problem.

> What does ffmpeg do?
> Does it skip to the closest frame border or does it include both the starting
> and ending frame so giving a video time of 805 seconds?

It will find the last keyframe prior to the timestamp specified by -ss.
See the documentation or try it yourself.

> Switching from the copy handler to something else makes ffmpeg work a lot harder
> and processing time goes from 5 seconds to 30 minutes or so....

That is normal since now your CPU needs to actually encode the frames
and not just copy packets.


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

[Peter White]

On Fri, Mar 26, 2021 at 07:02:13PM +0100, Cecil Westerhof via ffmpeg-user wrote:

> Carl Zwanzig <[hidden email]> writes:
>
> > On 3/26/2021 9:28 AM, Cecil Westerhof via ffmpeg-user wrote:
> >> There is only one problem. The video is 7:21 long, but both mpv and
> >> vlc think it is 7:30 long.
> >
> > IME, the metadata length often lies. When you say it's 7:21, is that
> > exactly how long it plays for or how long it ought to be?
>
> I almost never have this. (If I remember well, only with videos
> created with ffmpeg. Sometimes it started on a negative timestamp
> instead of 00:00:00.)
>
> Looking at the -to you would expect 7:22, but when I just play it, it
> ends at 7:21.

You can try using -to as an input option as well. I am not sure, but I
seem to remember having similar problems once. Also, have a look at -t
for defining the length of the file as opposed to cutting on time code.

Plus, from your original post it looks like there is some additional
"data" stream in there, which might get copied. Sometime ffmpeg needs to
wait for that to finish or an opportune position to stop. Maybe that is
the culprit here. Have a look into the -map option, i.e. -map V -map a
should only give you video and audio but drop everything else.

> >> ffprobe version 4.1.6-1~deb10u1 Copyright (c) 2007-2020 the FFmpeg developers
> >
> > That's an older version, even though it wouldn't help on this, it's
> > always best to check with as current as you can get.
>
> I am using Debian (stable). That always uses older versions.
> I could look if there is a newer version in backports.

You can compile it yourself as well. It is not that difficult. Might
need to hunt down some libraries, but that is basically just looking at
the error messages of configure and finding the appropriate packages.
Also, config.log and apt-file can help a great deal.


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

[Peter White]

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.

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


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

[FFmpeg-users mailing list]

Peter White <[hidden email]> writes:

> On Fri, Mar 26, 2021 at 07:02:13PM +0100, Cecil Westerhof via ffmpeg-user wrote:
>> Carl Zwanzig <[hidden email]> writes:
>>
>> > On 3/26/2021 9:28 AM, Cecil Westerhof via ffmpeg-user wrote:
>> >> There is only one problem. The video is 7:21 long, but both mpv and
>> >> vlc think it is 7:30 long.
>> >
>> > IME, the metadata length often lies. When you say it's 7:21, is that
>> > exactly how long it plays for or how long it ought to be?
>>
>> I almost never have this. (If I remember well, only with videos
>> created with ffmpeg. Sometimes it started on a negative timestamp
>> instead of 00:00:00.)
>>
>> Looking at the -to you would expect 7:22, but when I just play it, it
>> ends at 7:21.
>
> You can try using -to as an input option as well. I am not sure, but I
> seem to remember having similar problems once. Also, have a look at -t
> for defining the length of the file as opposed to cutting on time code.

That is what I did first. Then I got 1:34:19 (or something like it).
So even worse.


> Plus, from your original post it looks like there is some additional
> "data" stream in there, which might get copied. Sometime ffmpeg needs to
> wait for that to finish or an opportune position to stop. Maybe that is
> the culprit here. Have a look into the -map option, i.e. -map V -map a
> should only give you video and audio but drop everything else.

I will look into that.

>> >> ffprobe version 4.1.6-1~deb10u1 Copyright (c) 2007-2020 the FFmpeg developers
>> >
>> > That's an older version, even though it wouldn't help on this, it's
>> > always best to check with as current as you can get.
>>
>> I am using Debian (stable). That always uses older versions.
>> I could look if there is a newer version in backports.
>
> You can compile it yourself as well. It is not that difficult. Might
> need to hunt down some libraries, but that is basically just looking at
> the error messages of configure and finding the appropriate packages.
> Also, config.log and apt-file can help a great deal.

I will look into that also.

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

[FFmpeg-users mailing list]

Carl Eugen Hoyos <[hidden email]> writes:

> Am Fr., 26. März 2021 um 17:28 Uhr schrieb Cecil Westerhof via
> ffmpeg-user <[hidden email]>:
>
>> ffmpeg -y -ss 1189 -i 2021-03-25ToastmastersClubAvond.mp4
>> -to 442 -acodec copy -vcodec libx264 -crf 8 -async 1 speech.mp4
>
> The x264 documentation states that there is no good
> reason to use "crf 8" and please don't use "acodec copy"
> with "async 1", these two options are exclusive.

I thought that crf 8 would minimise degrading the video. So that is
not true.
Long ago I needed that, but probably I did not use acopy there,

Thanks. I will change that.

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

[FFmpeg-users mailing list]

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.


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

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.

Now trying with crf 16. And then comparing the video quality.

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

[Peter White]

On Sat, Mar 27, 2021 at 05:53:56AM +0100, Cecil Westerhof via ffmpeg-user wrote:

> Peter White <[hidden email]> writes:
>
> > On Fri, Mar 26, 2021 at 07:02:13PM +0100, Cecil Westerhof via ffmpeg-user wrote:
> >> Carl Zwanzig <[hidden email]> writes:
> >>
> >> > On 3/26/2021 9:28 AM, Cecil Westerhof via ffmpeg-user wrote:
> >> >> There is only one problem. The video is 7:21 long, but both mpv and
> >> >> vlc think it is 7:30 long.
> >> >
> >> > IME, the metadata length often lies. When you say it's 7:21, is that
> >> > exactly how long it plays for or how long it ought to be?
> >>
> >> I almost never have this. (If I remember well, only with videos
> >> created with ffmpeg. Sometimes it started on a negative timestamp
> >> instead of 00:00:00.)
> >>
> >> Looking at the -to you would expect 7:22, but when I just play it, it
> >> ends at 7:21.
> >
> > You can try using -to as an input option as well. I am not sure, but I
> > seem to remember having similar problems once. Also, have a look at -t
> > for defining the length of the file as opposed to cutting on time code.
>
> That is what I did first. Then I got 1:34:19 (or something like it).
> So even worse.

When you say "first", was that with -vcodec copy? Because that might
explain it. Although, I do not know why the file would be so much
longer. May be that data stream.

BTW, you can use "time codes" for -ss, -to and -t, too. Personally, I do
not like having to calculate in seconds when I can simply use the
timestamps shown by a player. It is much more intuitive, to me at least,
to just say: cut from (-ss) 19:45 -to 27:11 instead of from 1190 to
1631. But that, of course, depends on how you retrieved those timestamps
in the first place.

I now think, I know why I had problems in the past with -ss as an input
and -to as an output option in combination. By using -ss as input
option, the output timestamps start at 0, thus -to, in this scenario, is
the same as -t, resulting a file of that length. Hence, I suggest to
either use both -ss and -to as input or as output options and not mix
them as one input and the other as output option.

From my understanding the difference between them being used as input or
output options, respectively, is that when used as input options they
tell the *demuxer* to seek and stop at the given timestamps. Or, more
precisely, the demuxer seeks to the last keyframe before the -ss
timestamp and the decoder starts decoding from there, discarding all
frames before the accurate timestamp.

When used as output option that applies to the *decoder*, with "copy"
being a special case. Because of this, you might need to wait a long
time for the encoding to start, when using them as output options, since
the decoder needs to get to the -ss timestamp by decoding frames which
get discarded.

What I am trying to say is: use -ss and -t(o) as input option whenever
you can, unless there is a very good reason--whatever that might be--for
using them as output options.


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

[Peter White]

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.

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

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


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

[Peter White]

On Sat, Mar 27, 2021 at 05:53:56AM +0100, Cecil Westerhof via ffmpeg-user wrote:
> Peter White <[hidden email]> writes:
>
> > You can compile it yourself as well. It is not that difficult. Might
> > need to hunt down some libraries, but that is basically just looking at
> > the error messages of configure and finding the appropriate packages.
> > Also, config.log and apt-file can help a great deal.
>
> I will look into that also.

I only just remembered that there is a shortcut you can use:

# apt-get build-dep ffmpeg

The command will install all build dependencies which are required for
the building the official Debian package. That should at least be a good
start.
_______________________________________________
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".

[FFmpeg-users mailing list]

Peter White <[hidden email]> writes:

> On Sat, Mar 27, 2021 at 05:53:56AM +0100, Cecil Westerhof via ffmpeg-user wrote:
>> Peter White <[hidden email]> writes:
>>
>> > On Fri, Mar 26, 2021 at 07:02:13PM +0100, Cecil Westerhof via ffmpeg-user wrote:
>> >> Carl Zwanzig <[hidden email]> writes:
>> >>
>> >> > On 3/26/2021 9:28 AM, Cecil Westerhof via ffmpeg-user wrote:
>> >> >> There is only one problem. The video is 7:21 long, but both mpv and
>> >> >> vlc think it is 7:30 long.
>> >> >
>> >> > IME, the metadata length often lies. When you say it's 7:21, is that
>> >> > exactly how long it plays for or how long it ought to be?
>> >>
>> >> I almost never have this. (If I remember well, only with videos
>> >> created with ffmpeg. Sometimes it started on a negative timestamp
>> >> instead of 00:00:00.)
>> >>
>> >> Looking at the -to you would expect 7:22, but when I just play it, it
>> >> ends at 7:21.
>> >
>> > You can try using -to as an input option as well. I am not sure, but I
>> > seem to remember having similar problems once. Also, have a look at -t
>> > for defining the length of the file as opposed to cutting on time code.
>>
>> That is what I did first. Then I got 1:34:19 (or something like it).
>> So even worse.
>
> When you say "first", was that with -vcodec copy? Because that might
> explain it. Although, I do not know why the file would be so much
> longer. May be that data stream.

No, libx264. What I think happened that the input was stopped, but the
timestamp copied from the original. But I will keep playing with it.

By the way when I crop the video afterwards the end time is correct.
But it would be better to do everything in one swoop of-course. (At
the moment I am just finding out what to do.)


> BTW, you can use "time codes" for -ss, -to and -t, too. Personally, I do
> not like having to calculate in seconds when I can simply use the
> timestamps shown by a player. It is much more intuitive, to me at least,
> to just say: cut from (-ss) 19:45 -to 27:11 instead of from 1190 to
> 1631. But that, of course, depends on how you retrieved those timestamps
> in the first place.

Well I enter them as timestamps and my script convert it to seconds.
(It is quit an old script.) And when I use the first as input and the
second as output I need to convert them so I can calculate the length.


> From my understanding the difference between them being used as input or
> output options, respectively, is that when used as input options they
> tell the *demuxer* to seek and stop at the given timestamps. Or, more
> precisely, the demuxer seeks to the last keyframe before the -ss
> timestamp and the decoder starts decoding from there, discarding all
> frames before the accurate timestamp.

That was my understanding also.

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