[FFmpeg-user] What is the fastest way to run cropdetect onspecificframes in the video?

Dan Flett dflett at bigpond.net.au
Fri Jul 29 02:47:29 CEST 2011


-----Original Message-----
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?

-----Original Message-----
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

Matt Kim

Hi Matt

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

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 mailing list