Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Implement auto cropping via cropdetect #81

Closed
HannesJo0139 opened this issue Oct 15, 2020 · 9 comments
Closed

[Feature Request] Implement auto cropping via cropdetect #81

HannesJo0139 opened this issue Oct 15, 2020 · 9 comments
Labels
feature request New idea for project

Comments

@HannesJo0139
Copy link

Hi! First of all: Thank U so much again for your great work! I just updated from v2.4 to v3 and I am really really happy. Its gettin a really awesome piece of software.

Another great feature would be an auto cropping detection. In the moment I'm doing it by hand with the command
ffplay -ss 600 -i movie.mkv -t 10 -vf cropdetect
What do U think about it?

@cdgriffith
Copy link
Owner

Honestly didn't know FFmpeg had that feature, will look into it!

@cdgriffith cdgriffith added the feature request New idea for project label Oct 15, 2020
@loungebob
Copy link

lol I load the video in handbrake, read the cropping stats and manually add them to fastflix. not very convenient but totally doable.

cdgriffith added a commit that referenced this issue Oct 21, 2020
* Fixing AVC always copied chapters
(Current bug with thumbnails not being created properly)
@cdgriffith
Copy link
Owner

I am working on adding this now, and initial version in develop branch.
autocrop

I don't have it run on start as I am running it on a point-in-time based off what the user has entered for start time (or 10% in if start time is 0). But could be a configurable options in settings to always autocrop on load, would that be useful?

One bug I have right now is if you crop and scale the video (say from 4K to 1080p) will be stretched, so need to calculate scale properly when crop is enabled. But seems fine if not chaging the resolution.

cdgriffith added a commit that referenced this issue Oct 23, 2020
* Adding #75 burn-in subtitle support (thanks to Trevbams)
* Adding #81 auto crop feature (thanks to HannesJo0139)
* Adding #84 pause / resume functionality (thanks to loungebob)
* Adding hover info for Audio and Subtitle tracks
* Adding confirm overwrite dialog if file already exists and is not empty
* Adding linking to issues in changelog file
* Changing to explicitly set no-slow-firstpass for x265 bitrate runs
* Changing FFmpeg to download latest available
* Fixing AVC always copied chapters
* Fixing how aspect ratio interacted with crop
* Fixing HEVC would copy HDR10 details on 8-bit videos
@cdgriffith
Copy link
Owner

Added in 3.2.0

@loungebob
Copy link

Tried on 2 files and seems to work fine. Detected the proper crop. Although it did say -1 in vertical resolution, the file produced was showing the correct resolution.

@cdgriffith
Copy link
Owner

Glad it's working!

-1 just means "base the height off the width", aka "keep the aspect ratio", and it's only actually passed to ffmpeg if the width is changed. Need to document / make that clearer. Maybe change it to display "Auto"

@HannesJo0139
Copy link
Author

I don't have it run on start as I am running it on a point-in-time based off what the user has entered for start time (or 10% in if start time is 0). But could be a configurable options in settings to always autocrop on load, would that be useful?

Its really awesome how fast you have implemented it! I think that 10% or start time thing fits most needs out there. In very rare cases there are movies having sequences with different crop. May be possible to extend the analysis to match these cases too. But yeah, maybe it would be more of a gimmick that hardly anyone needs.

@HannesJo0139
Copy link
Author

So I have tested it several times now and sometimes I get invalid values. Eg on Star Wars Episode 1 it detects "crop=3840:1312:0:546". I have no idea how cropdetect exactly works but it seems to have problems on very dark scenes. If I change the start time to let's say 1h, it correctly detects crop=3840:1600:0:280.

Setting a very early start time larger 0, when image is still dark, croptdetect fails and throws an error due to detected image width <1.

So maybe a little more optimization, sth like collecting multiple crop values and a basic plausibility check would be a good idea.

@cdgriffith
Copy link
Owner

Good to know there are still some issues. I have it currently detecting across 10 frames, but could probably expand that to a few seconds worth for safety.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New idea for project
Projects
None yet
Development

No branches or pull requests

3 participants