Frame counting is too slow

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

Frame counting is too slow

Peter White
Hi all,

as a follow-up to this discussion:
https://ffmpeg.org/pipermail/ffmpeg-user/2021-March/052358.html

I would like to ask, if frame counting with ffprobe can be made faster.
The way it done now is obviously by decoding every single frame and
afterwards incrementing the counter. See how slow this example runs:

time ffprobe -count_frames -select_streams v:0 -show_entries stream=nb_read_frames -of default=nokey=1:noprint_wrappers=1 input.mkv
ffprobe version n4.3.1-221-gd08bcbffff Copyright (c) 2007-2021 the FFmpeg developers
  built with AMD clang version 11.0.0 (CLANG: AOCC_2.3.0-Build#85 2020_11_10) (based on LLVM Mirror.Version.11.0.0)
  configuration: --cc='ccache clang' --cxx='ccache clang++' --objcc='ccache clang' --dep-cc='ccache clang' --extra-cflags='-march=native' --extra-cxxflags='-march=native' --extra-objcflags='-march=native' --enable-hardcoded-tables --enable-shared --enable-gpl --enable-version3 --enable-nonfree --disable-runtime-cpudetect --enable-libx264 --enable-libx265 --enable-libvorbis --enable-gnutls --enable-opengl --enable-libopus --enable-libfreetype --enable-libfontconfig --enable-libfribidi --enable-libsoxr --enable-libzvbi --enable-libmp3lame --enable-ladspa --enable-lv2 --enable-libbs2b --enable-libdrm --enable-libvpx --enable-libbluray
  libavutil      56. 51.100 / 56. 51.100
  libavcodec     58. 91.100 / 58. 91.100
  libavformat    58. 45.100 / 58. 45.100
  libavdevice    58. 10.100 / 58. 10.100
  libavfilter     7. 85.100 /  7. 85.100
  libswscale      5.  7.100 /  5.  7.100
  libswresample   3.  7.100 /  3.  7.100
  libpostproc    55.  7.100 / 55.  7.100
Input #0, matroska,webm, from 'input.mkv':
  Metadata:
    creation_time   : 2021-02-16T19:59:37.000000Z
    ENCODER         : Lavf58.45.100
  Duration: 00:21:40.91, start: -0.007000, bitrate: 1319 kb/s
    Chapter #0:0: start 0.000000, end 432.557000
    Metadata:
      title           : 00:00:00.000
    Chapter #0:1: start 432.557000, end 866.824000
    Metadata:
      title           : 00:07:12.557
    Chapter #0:2: start 866.824000, end 1267.475000
    Metadata:
      title           : 00:14:26.824
    Chapter #0:3: start 1267.475000, end 1300.906000
    Metadata:
      title           : 00:21:07.475
    Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt709), 768x432 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)
    Metadata:
      BPS-eng         : 1021384
      DURATION-eng    : 00:21:40.716000000
      NUMBER_OF_FRAMES-eng: 31186
      NUMBER_OF_BYTES-eng: 166066371
      _STATISTICS_WRITING_APP-eng: mkvmerge v45.0.0 ('Heaven in Pennies') 64-bit
      _STATISTICS_WRITING_DATE_UTC-eng: 2021-02-16 19:59:37
      _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
    Stream #0:1(eng): Audio: opus, 48000 Hz, 5.1, fltp (default)
    Metadata:
      title           : English
      ENCODER         : Lavc58.91.100 libopus
      BPS-eng         : 230805
      DURATION-eng    : 00:21:40.760000000
      NUMBER_OF_FRAMES-eng: 65039
      NUMBER_OF_BYTES-eng: 37527832
      _STATISTICS_WRITING_APP-eng: mkvmerge v45.0.0 ('Heaven in Pennies') 64-bit
      _STATISTICS_WRITING_DATE_UTC-eng: 2021-02-16 19:59:37
      _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
    Stream #0:2(eng): Audio: aac (HE-AAC), 48000 Hz, stereo, fltp
    Metadata:
      title           : English
      BPS-eng         : 63925
      DURATION-eng    : 00:21:40.906000000
      NUMBER_OF_FRAMES-eng: 30490
      NUMBER_OF_BYTES-eng: 10395117
      _STATISTICS_WRITING_APP-eng: mkvmerge v45.0.0 ('Heaven in Pennies') 64-bit
      _STATISTICS_WRITING_DATE_UTC-eng: 2021-02-16 19:59:37
      _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
    Stream #0:3(eng): Subtitle: subrip
    Metadata:
      title           : English
      BPS-eng         : 72
      DURATION-eng    : 00:21:36.169000000
      NUMBER_OF_FRAMES-eng: 370
      NUMBER_OF_BYTES-eng: 11676
      _STATISTICS_WRITING_APP-eng: mkvmerge v45.0.0 ('Heaven in Pennies') 64-bit
      _STATISTICS_WRITING_DATE_UTC-eng: 2021-02-16 19:59:37
      _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
31186
ffprobe -count_frames -select_streams v:0 -show_entries stream=nb_read_frames  55,01s user 0,10s system 99% cpu 55,182 total

And apparently ffprobe only uses one CPU core by default as opposed to
ffmpeg; see the 99% load. This machine has 8 threads, hence is capable
of 800%, theoretically. But that is just an aside.

But why do the frames need to be decoded for counting? That seems
excessive for such a supposedly mundane task. In the mentioned
discussion I inadvertently suggested counting packets instead by using
ffmpeg's copy codec with the null device as a target and looking at the
number of frames in the stats line. This way the operation finishes
almost immediately. Then I learned, that the equivalent ffprobe command
is this:
ffprobe -count_packets -select_streams v:0 -show_entries stream=nb_read_packets -of default=nokey=1:noprint_wrappers=1 input.mkv

It takes but a blink of an eye to finish. There is a catch, though,
since packets are not frames, there might be some scenario in which the
number of packets is greater than the number of frames.

Isn't there a way to count frames by some kind of dummy decoder, which
just increments a counter instead of decoding?


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: Frame counting is too slow

Ulf Zibis-2

Am 09.03.21 um 16:27 schrieb Peter White:

> Hi all,
>
> as a follow-up to this discussion:
> https://ffmpeg.org/pipermail/ffmpeg-user/2021-March/052358.html
>
> I would like to ask, if frame counting with ffprobe can be made faster.
> The way it done now is obviously by decoding every single frame and
> afterwards incrementing the counter. See how slow this example runs:
>
> time ffprobe -count_frames -select_streams v:0 -show_entries stream=nb_read_frames -of default=nokey=1:noprint_wrappers=1 input.mkv

I additionally like to suggest to add a short cut option for this operations (count frames + count packets). This would also "automatically" entail a item in the documentation, where people can find it without the need to repeat this question in the mailing list again and again.

-Ulf

_______________________________________________
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: Frame counting is too slow

Paul B Mahol
patch welcome

On Tue, Mar 9, 2021 at 4:39 PM Ulf Zibis <[hidden email]> wrote:

>
> Am 09.03.21 um 16:27 schrieb Peter White:
> > Hi all,
> >
> > as a follow-up to this discussion:
> > https://ffmpeg.org/pipermail/ffmpeg-user/2021-March/052358.html
> >
> > I would like to ask, if frame counting with ffprobe can be made faster.
> > The way it done now is obviously by decoding every single frame and
> > afterwards incrementing the counter. See how slow this example runs:
> >
> > time ffprobe -count_frames -select_streams v:0 -show_entries
> stream=nb_read_frames -of default=nokey=1:noprint_wrappers=1 input.mkv
>
> I additionally like to suggest to add a short cut option for this
> operations (count frames + count packets). This would also "automatically"
> entail a item in the documentation, where people can find it without the
> need to repeat this question in the mailing list again and again.
>
> -Ulf
>
> _______________________________________________
> 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-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: Frame counting is too slow

Paul B Mahol
In reply to this post by Peter White
patch welcome

On Tue, Mar 9, 2021 at 4:27 PM Peter White <[hidden email]> wrote:

> Hi all,
>
> as a follow-up to this discussion:
> https://ffmpeg.org/pipermail/ffmpeg-user/2021-March/052358.html
>
> I would like to ask, if frame counting with ffprobe can be made faster.
> The way it done now is obviously by decoding every single frame and
> afterwards incrementing the counter. See how slow this example runs:
>
> time ffprobe -count_frames -select_streams v:0 -show_entries
> stream=nb_read_frames -of default=nokey=1:noprint_wrappers=1 input.mkv
> ffprobe version n4.3.1-221-gd08bcbffff Copyright (c) 2007-2021 the FFmpeg
> developers
>   built with AMD clang version 11.0.0 (CLANG: AOCC_2.3.0-Build#85
> 2020_11_10) (based on LLVM Mirror.Version.11.0.0)
>   configuration: --cc='ccache clang' --cxx='ccache clang++'
> --objcc='ccache clang' --dep-cc='ccache clang'
> --extra-cflags='-march=native' --extra-cxxflags='-march=native'
> --extra-objcflags='-march=native' --enable-hardcoded-tables --enable-shared
> --enable-gpl --enable-version3 --enable-nonfree --disable-runtime-cpudetect
> --enable-libx264 --enable-libx265 --enable-libvorbis --enable-gnutls
> --enable-opengl --enable-libopus --enable-libfreetype
> --enable-libfontconfig --enable-libfribidi --enable-libsoxr
> --enable-libzvbi --enable-libmp3lame --enable-ladspa --enable-lv2
> --enable-libbs2b --enable-libdrm --enable-libvpx --enable-libbluray
>   libavutil      56. 51.100 / 56. 51.100
>   libavcodec     58. 91.100 / 58. 91.100
>   libavformat    58. 45.100 / 58. 45.100
>   libavdevice    58. 10.100 / 58. 10.100
>   libavfilter     7. 85.100 /  7. 85.100
>   libswscale      5.  7.100 /  5.  7.100
>   libswresample   3.  7.100 /  3.  7.100
>   libpostproc    55.  7.100 / 55.  7.100
> Input #0, matroska,webm, from 'input.mkv':
>   Metadata:
>     creation_time   : 2021-02-16T19:59:37.000000Z
>     ENCODER         : Lavf58.45.100
>   Duration: 00:21:40.91, start: -0.007000, bitrate: 1319 kb/s
>     Chapter #0:0: start 0.000000, end 432.557000
>     Metadata:
>       title           : 00:00:00.000
>     Chapter #0:1: start 432.557000, end 866.824000
>     Metadata:
>       title           : 00:07:12.557
>     Chapter #0:2: start 866.824000, end 1267.475000
>     Metadata:
>       title           : 00:14:26.824
>     Chapter #0:3: start 1267.475000, end 1300.906000
>     Metadata:
>       title           : 00:21:07.475
>     Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt709), 768x432
> [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)
>     Metadata:
>       BPS-eng         : 1021384
>       DURATION-eng    : 00:21:40.716000000
>       NUMBER_OF_FRAMES-eng: 31186
>       NUMBER_OF_BYTES-eng: 166066371
>       _STATISTICS_WRITING_APP-eng: mkvmerge v45.0.0 ('Heaven in Pennies')
> 64-bit
>       _STATISTICS_WRITING_DATE_UTC-eng: 2021-02-16 19:59:37
>       _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
>     Stream #0:1(eng): Audio: opus, 48000 Hz, 5.1, fltp (default)
>     Metadata:
>       title           : English
>       ENCODER         : Lavc58.91.100 libopus
>       BPS-eng         : 230805
>       DURATION-eng    : 00:21:40.760000000
>       NUMBER_OF_FRAMES-eng: 65039
>       NUMBER_OF_BYTES-eng: 37527832
>       _STATISTICS_WRITING_APP-eng: mkvmerge v45.0.0 ('Heaven in Pennies')
> 64-bit
>       _STATISTICS_WRITING_DATE_UTC-eng: 2021-02-16 19:59:37
>       _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
>     Stream #0:2(eng): Audio: aac (HE-AAC), 48000 Hz, stereo, fltp
>     Metadata:
>       title           : English
>       BPS-eng         : 63925
>       DURATION-eng    : 00:21:40.906000000
>       NUMBER_OF_FRAMES-eng: 30490
>       NUMBER_OF_BYTES-eng: 10395117
>       _STATISTICS_WRITING_APP-eng: mkvmerge v45.0.0 ('Heaven in Pennies')
> 64-bit
>       _STATISTICS_WRITING_DATE_UTC-eng: 2021-02-16 19:59:37
>       _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
>     Stream #0:3(eng): Subtitle: subrip
>     Metadata:
>       title           : English
>       BPS-eng         : 72
>       DURATION-eng    : 00:21:36.169000000
>       NUMBER_OF_FRAMES-eng: 370
>       NUMBER_OF_BYTES-eng: 11676
>       _STATISTICS_WRITING_APP-eng: mkvmerge v45.0.0 ('Heaven in Pennies')
> 64-bit
>       _STATISTICS_WRITING_DATE_UTC-eng: 2021-02-16 19:59:37
>       _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
> 31186
> ffprobe -count_frames -select_streams v:0 -show_entries
> stream=nb_read_frames  55,01s user 0,10s system 99% cpu 55,182 total
>
> And apparently ffprobe only uses one CPU core by default as opposed to
> ffmpeg; see the 99% load. This machine has 8 threads, hence is capable
> of 800%, theoretically. But that is just an aside.
>
> But why do the frames need to be decoded for counting? That seems
> excessive for such a supposedly mundane task. In the mentioned
> discussion I inadvertently suggested counting packets instead by using
> ffmpeg's copy codec with the null device as a target and looking at the
> number of frames in the stats line. This way the operation finishes
> almost immediately. Then I learned, that the equivalent ffprobe command
> is this:
> ffprobe -count_packets -select_streams v:0 -show_entries
> stream=nb_read_packets -of default=nokey=1:noprint_wrappers=1 input.mkv
>
> It takes but a blink of an eye to finish. There is a catch, though,
> since packets are not frames, there might be some scenario in which the
> number of packets is greater than the number of frames.
>
> Isn't there a way to count frames by some kind of dummy decoder, which
> just increments a counter instead of decoding?
>
>
> 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-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: Frame counting is too slow

Peter White
On Tue, Mar 09, 2021 at 04:43:54PM +0100, Paul B Mahol wrote:
> patch welcome

After I have had a look at ffprobe.c I noticed, that there seems to be
nothing that can be done there other than basically cheating by actually
counting packets instead of frames, which would never get accepted, me
reckons.
Then I took a look at avcodec.h to get some initial bearings just to be
overwhelmed by its size. :)

Before I spend anymore time on this, can somebody please tell me, if
what I proposed is actually possible? I am starting to think that it
cannot be done.

Is this a correct, though simplified, definition of "frame" in avcodec.h
terms?:
A frame is what the decoder returns in avcodec_receive_frame().

If that is true, then I cannot see, how to work around that without
breaking something.

Or am I looking at it wrong?

> On Tue, Mar 9, 2021 at 4:27 PM Peter White <[hidden email]> wrote:
>
> > Hi all,
> >
> > as a follow-up to this discussion:
> > https://ffmpeg.org/pipermail/ffmpeg-user/2021-March/052358.html
> >
> > I would like to ask, if frame counting with ffprobe can be made faster.
> > The way it done now is obviously by decoding every single frame and
> > afterwards incrementing the counter. See how slow this example runs:
> >
> > time ffprobe -count_frames -select_streams v:0 -show_entries
> > stream=nb_read_frames -of default=nokey=1:noprint_wrappers=1 input.mkv
> > ffprobe version n4.3.1-221-gd08bcbffff Copyright (c) 2007-2021 the FFmpeg
> > developers
> >   built with AMD clang version 11.0.0 (CLANG: AOCC_2.3.0-Build#85
> > 2020_11_10) (based on LLVM Mirror.Version.11.0.0)
> >   configuration: --cc='ccache clang' --cxx='ccache clang++'
> > --objcc='ccache clang' --dep-cc='ccache clang'
> > --extra-cflags='-march=native' --extra-cxxflags='-march=native'
> > --extra-objcflags='-march=native' --enable-hardcoded-tables --enable-shared
> > --enable-gpl --enable-version3 --enable-nonfree --disable-runtime-cpudetect
> > --enable-libx264 --enable-libx265 --enable-libvorbis --enable-gnutls
> > --enable-opengl --enable-libopus --enable-libfreetype
> > --enable-libfontconfig --enable-libfribidi --enable-libsoxr
> > --enable-libzvbi --enable-libmp3lame --enable-ladspa --enable-lv2
> > --enable-libbs2b --enable-libdrm --enable-libvpx --enable-libbluray
> >   libavutil      56. 51.100 / 56. 51.100
> >   libavcodec     58. 91.100 / 58. 91.100
> >   libavformat    58. 45.100 / 58. 45.100
> >   libavdevice    58. 10.100 / 58. 10.100
> >   libavfilter     7. 85.100 /  7. 85.100
> >   libswscale      5.  7.100 /  5.  7.100
> >   libswresample   3.  7.100 /  3.  7.100
> >   libpostproc    55.  7.100 / 55.  7.100
> > Input #0, matroska,webm, from 'input.mkv':
> >   Metadata:
> >     creation_time   : 2021-02-16T19:59:37.000000Z
> >     ENCODER         : Lavf58.45.100
> >   Duration: 00:21:40.91, start: -0.007000, bitrate: 1319 kb/s
> >     Chapter #0:0: start 0.000000, end 432.557000
> >     Metadata:
> >       title           : 00:00:00.000
> >     Chapter #0:1: start 432.557000, end 866.824000
> >     Metadata:
> >       title           : 00:07:12.557
> >     Chapter #0:2: start 866.824000, end 1267.475000
> >     Metadata:
> >       title           : 00:14:26.824
> >     Chapter #0:3: start 1267.475000, end 1300.906000
> >     Metadata:
> >       title           : 00:21:07.475
> >     Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt709), 768x432
> > [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)
> >     Metadata:
> >       BPS-eng         : 1021384
> >       DURATION-eng    : 00:21:40.716000000
> >       NUMBER_OF_FRAMES-eng: 31186
> >       NUMBER_OF_BYTES-eng: 166066371
> >       _STATISTICS_WRITING_APP-eng: mkvmerge v45.0.0 ('Heaven in Pennies')
> > 64-bit
> >       _STATISTICS_WRITING_DATE_UTC-eng: 2021-02-16 19:59:37
> >       _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
> >     Stream #0:1(eng): Audio: opus, 48000 Hz, 5.1, fltp (default)
> >     Metadata:
> >       title           : English
> >       ENCODER         : Lavc58.91.100 libopus
> >       BPS-eng         : 230805
> >       DURATION-eng    : 00:21:40.760000000
> >       NUMBER_OF_FRAMES-eng: 65039
> >       NUMBER_OF_BYTES-eng: 37527832
> >       _STATISTICS_WRITING_APP-eng: mkvmerge v45.0.0 ('Heaven in Pennies')
> > 64-bit
> >       _STATISTICS_WRITING_DATE_UTC-eng: 2021-02-16 19:59:37
> >       _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
> >     Stream #0:2(eng): Audio: aac (HE-AAC), 48000 Hz, stereo, fltp
> >     Metadata:
> >       title           : English
> >       BPS-eng         : 63925
> >       DURATION-eng    : 00:21:40.906000000
> >       NUMBER_OF_FRAMES-eng: 30490
> >       NUMBER_OF_BYTES-eng: 10395117
> >       _STATISTICS_WRITING_APP-eng: mkvmerge v45.0.0 ('Heaven in Pennies')
> > 64-bit
> >       _STATISTICS_WRITING_DATE_UTC-eng: 2021-02-16 19:59:37
> >       _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
> >     Stream #0:3(eng): Subtitle: subrip
> >     Metadata:
> >       title           : English
> >       BPS-eng         : 72
> >       DURATION-eng    : 00:21:36.169000000
> >       NUMBER_OF_FRAMES-eng: 370
> >       NUMBER_OF_BYTES-eng: 11676
> >       _STATISTICS_WRITING_APP-eng: mkvmerge v45.0.0 ('Heaven in Pennies')
> > 64-bit
> >       _STATISTICS_WRITING_DATE_UTC-eng: 2021-02-16 19:59:37
> >       _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
> > 31186
> > ffprobe -count_frames -select_streams v:0 -show_entries
> > stream=nb_read_frames  55,01s user 0,10s system 99% cpu 55,182 total
> >
> > And apparently ffprobe only uses one CPU core by default as opposed to
> > ffmpeg; see the 99% load. This machine has 8 threads, hence is capable
> > of 800%, theoretically. But that is just an aside.
> >
> > But why do the frames need to be decoded for counting? That seems
> > excessive for such a supposedly mundane task. In the mentioned
> > discussion I inadvertently suggested counting packets instead by using
> > ffmpeg's copy codec with the null device as a target and looking at the
> > number of frames in the stats line. This way the operation finishes
> > almost immediately. Then I learned, that the equivalent ffprobe command
> > is this:
> > ffprobe -count_packets -select_streams v:0 -show_entries
> > stream=nb_read_packets -of default=nokey=1:noprint_wrappers=1 input.mkv
> >
> > It takes but a blink of an eye to finish. There is a catch, though,
> > since packets are not frames, there might be some scenario in which the
> > number of packets is greater than the number of frames.
> >
> > Isn't there a way to count frames by some kind of dummy decoder, which
> > just increments a counter instead of decoding?
> >
> >
> > 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-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-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: Frame counting is too slow

Peter White
In reply to this post by Peter White
On Tue, Mar 09, 2021 at 04:27:14PM +0100, Peter White wrote:

> Hi all,
>
> as a follow-up to this discussion:
> https://ffmpeg.org/pipermail/ffmpeg-user/2021-March/052358.html
>
> I would like to ask, if frame counting with ffprobe can be made faster.
> The way it done now is obviously by decoding every single frame and
> afterwards incrementing the counter. See how slow this example runs:
>
> time ffprobe -count_frames -select_streams v:0 -show_entries stream=nb_read_frames -of default=nokey=1:noprint_wrappers=1 input.mkv
> [...]
>       title           : English
>       BPS-eng         : 72
>       DURATION-eng    : 00:21:36.169000000
>       NUMBER_OF_FRAMES-eng: 370
>       NUMBER_OF_BYTES-eng: 11676
>       _STATISTICS_WRITING_APP-eng: mkvmerge v45.0.0 ('Heaven in Pennies') 64-bit
>       _STATISTICS_WRITING_DATE_UTC-eng: 2021-02-16 19:59:37
>       _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
> 31186
> ffprobe -count_frames -select_streams v:0 -show_entries stream=nb_read_frames  55,01s user 0,10s system 99% cpu 55,182 total
>
> And apparently ffprobe only uses one CPU core by default as opposed to
> ffmpeg; see the 99% load. This machine has 8 threads, hence is capable
> of 800%, theoretically. But that is just an aside.

FWIW, this last bit seems to be due to different defaults for ffprobe.
-threads 0 does show a load of 250% but the speedup is marginal, less
than 5 seconds.


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