Customizing cropdetect?

[JeanMarc]

I am typically using the cropdetect filter, generally with ffmpeg or mplayer, to define the crop parameters of my TV recordings.

Some of those have two logos in the top right and left corners, generally above the useful area of the frame. As a result, when I crop the image, the logos are removed, but those logos prevent cropdetect from automatically finding the good crop parameters.

Is there a way to customize cropdetect and tell it to avoid looking at the logo areas, for example the top left and right corners?

For example, the correct cropping parameters are: [712, 360, 4, 58]. The two logos sit above the top line (Y = 58) in the two corners. When finding the top border (at Y = 58) , cropdetect should look only between X = 180 and X = 640.
This would be the only restrictions, as the left, right and bottom borders don't present any problem.

It would almost be possible (but not convenient) to obtain that result in two passes. One pass to find the right, left and bottom lines, and a second pass where the logos would be cropped so that cropdetect could find the top line (Y=58).

I am just wondering if cropdetect could be modified to be told not to look in a small area of the picture.

[Selur]

Is there a way to customize cropdetect and tell it to avoid looking at the logo areas, for example the top left and right corners?
not unless you modify it's source code: no

[JeanMarc]

Exactly, that was my question.

[Selur]

ah, sorry, I understood it the way that you wanted to know if there is an option to do this,.. :)

[JeanMarc]

Well, since I don't find the source code, and I doubt I have the knowledge to customize it, I think I found the workaround.
For whoever is interested, here it is:

First run a normal cropdetect command, for example:
ffmpeg -y -ss 1000 -i my_clip -vf cropdetect=30:8:0 -vframes 100 -f rawvideo -an null
This gives me [w0, h0, x0, y0]. For example: [712, 392, 4, 28], where w0 and x0 are correct while h0 and y0 are wrong because of the two logos.

I then run a second pass where I pipe the cropped clip into an ffmpeg process that runs cropdetect:
ffmpeg -y -ss 1000 -i my_clip -vf crop=460:480:180:0 -vframes 120 -an -f image2pipe \
-vcodec ppm - | ffmpeg -f image2pipe -vcodec ppm -i - -vf cropdetect=30:8:0 -y null.avi
This gives [w1, h1, x1, y1] = [456, 360, 2, 58] where h1 and y1 are correct.
The final cropping parameters are then [w0, h1, x0, y1] or [712, 360, 4, 58]
Not too difficult to do in a script after all.

[nm]

How about simply chaining the crop and cropdetect filters together for the vertical cropdetect pass. You also don't need to specify pixel dimensions if you use a fraction and in_w and in_h:

ffmpeg -y -ss 1000 -i my_clip -vf crop=1/3*in_w:in_h,cropdetect=30:8:0 -vframes 100 -f rawvideo -an null

[JeanMarc]

How about simply chaining the crop and cropdetect filters together for the vertical cropdetect pass. You also don't need to specify pixel dimensions if you use a fraction and in_w and in_h:

ffmpeg -y -ss 1000 -i my_clip -vf crop=1/3*in_w:in_h,cropdetect=30:8:0 -vframes 100 -f rawvideo -an null
Thanks for the interest, but sorry, that doesn't work here. I need two dimensions before cropping (w0 and x0) which I can't get after cropping. So I still think I need two passes. Although there might be a technique I don't know to combine the two passes.

[nm]

Thanks for the interest, but sorry, that doesn't work here. I need two dimensions before cropping (w0 and x0) which I can't get after cropping. So I still think I need two passes.

Yes, you probably need two passes. It would be possible to split the input to two filtering chains and run two cropdetects at the same time within a single ffmpeg process, but parsing the output would be harder.

My command suggestion was only intended to replace your second pass with a shorter and simpler variation. It determines top and bottom cropping amounts.

[JeanMarc]

My command suggestion was only intended to replace your second pass with a shorter and simpler variation. It determines top and bottom cropping amounts.
You are perfectly right. I didn't realize you were referring to the second command. It is much simpler, doesn't use the pipe (which I had a hard time setting up) and works perfectly.
Thanks a lot.