[FFmpeg-user] Frame counting is too slow
Paul B Mahol
onemda at gmail.com
Tue Mar 9 17:43:54 EET 2021
patch welcome
On Tue, Mar 9, 2021 at 4:27 PM Peter White <peter.white at posteo.net> 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
> ffmpeg-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".
More information about the ffmpeg-user
mailing list