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". |
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". |
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". |
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". |
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". |
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". |
Free forum by Nabble | Edit this page |