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

[Matt Kim]

One thing I have noticed is that sometimes placing -ss before -i will not
work.  And so FFmpeg will not seek to the specified time and instead start
running from the beginning of the video file.

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

How would I set up the "select" filter in order to get this behavior?  Or
are you saying that FFmpeg should implement this into the select option?

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

It is not necessarily good to recommend the most commonly occurring
dimensions.  One use case where this is not viable is where the video
content contains alot of black within the content.  This would most likely
occur in black/white videos, space documentaries, horror films, etc.  In
this case the cropdetect filter wouldn't be able to give you a correct crop
dimension by grabbing the most consistent statistic.  Instead the "largest
suggested crop dimensions" would most likely be the most correct--given that
the limit option is set appropriately and given that crop detect has at
least analyzed one frame where black from the content does not bleed into
the black borders.

I am finding that I have to implement my own statistical inference
algorithms in order to pick and asses the integrity of the given
crop-dimensions.  Maybe this is necessarily complex as the possible
use-cases seem too complex to automate.

Thanks for your response to my questions.  I may try implementing something
where I place the -ss before the -i initially, and if i detect that the seek
was not successful. I may re-run the command with -ss after -i.


On Thu, Jul 28, 2011 at 5:47 PM, Dan Flett <dflett at bigpond.net.au> wrote:

>
>
> -----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
>
> "select='isnan(prev_selected_t)+gte(t-prev_selected_t,1)',cropdetect=24:2:0"
> -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
> line.
>
> Dan
>
> _______________________________________________
>
> 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.
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>



-- 
Matt Kim