[FFmpeg-user] What is the fastest way to run cropdetect onspecificframes in the video?
dflett at bigpond.net.au
Fri Jul 29 02:47:29 CEST 2011
Of Dan Flett
Sent: Thursday, 28 July 2011 21:42
Subject: Re: [FFmpeg-user] What is the fastest way to run cropdetect
onspecificframes in the video?
On Behalf Of Matt Kim
Sent: Monday, 4 July 2011 04:40
Subject: [FFmpeg-user] What is the fastest way to run cropdetect on
specificframes in the video?
I am trying to run the cropdetect function from the libavfilter library in
the fastest way possible.
And so I am trying to only take a collection of video frames throughout the
video and run it through the cropdetect filter.
So far I have tried two methods:
1. Run FFmpeg 4 different times in parallel at 4 different seektimes using
the -ss option.
- Unfortunately for me--the -ss option does not seem to work quickly,
and so attempts to run through every frame before reaching the correct time.
This causes the -ss option to be the bottleneck. This maybe be an issue
with file itself and not FFmpeg.
2. Apply the "select" filter before "cropdetect".
- This method is even slower than the previous one. I'm assuming that
applying the select filter on each frame takes much time.
*I have heard that moving the -ss option around may speed up the
process--but unfortunately on all of the encoded files I am dealing
with--this method does not seem to help.
Does anyone have any advice on how I may be able to run cropdetect faster?
Right now my analysis (using the parallel method) takes about 1 sec per 1
minute. This can cause problems though--as a 3hour long video will take
about 3 minutes to analyze.
Here is an example of how I am running my cropdetect filter:
ffmpeg -i [input video] -vf
-ss 600 -t 100 -an -y null.mp4
The only suggestion I have is putting -ss and -t before -i in your command
Replying to myself, and to Matt:
I've been playing with cropdetect a bit more. Putting -ss and -t before -i
definitely speeds up seek times. But perhaps ffmpeg doesn't allow this with
certain file types.
I notice that if you use the "select" filter, or if you put -ss after -i,
ffmpeg seems to seek linearly through the file from the beginning to the
seek point - which is slow. If you put -ss before -i, it instantly jumps to
the seek point. To do this you need to run a separate instance of ffmpeg
for every seek you do.
Two improvements could be made to the code :) :
Set up the "select" filter so each time it seeks to a new part of the file,
it behaves as if -ss was specified before -i. I.e. instant jumping to the
The cropdetect filter could keep tabs on the most commonly occurring crop
recommendations for the file it is analysing. Currently, if you run
cropdetect you get a crop recommendation for each frame it analyses. It
would be good if cropdetect could then do a simple statistical analysis and
tell you the best overall crop recommendation.
More information about the ffmpeg-user