Proposal to no longer constrain detected crop results

In the past, I’ve been adamant that cropping video for transcoding is not about making the edges of the output look pretty. My rationale was that those “black” edges are not visible anyway when viewed full screen. For me, cropping was about improving performance, not aesthetics.

So, I designed the detect-crop tool and the --crop detect function of transcode-video to determine what I believed to be the “optimal” shape for a crop. The algorithm for this shape would only crop a minimum number of pixels, and always from either the top and bottom or from the left and right, never from both axes.

But I now believe it’s a much better practice to remove all the “black” edges around the video when transcoding. Of course, there are a few exceptions for irregularly cropped movies like “The Dark Knight (2008)” and “The Grand Budapest Hotel (2014).”

Why did I change my mind? After transcoding thousands of videos, I can identify more than just a few where leaving “black” edges causes annoying artifacts as x264 tries to encode the actual boundary of the content next to the remaining edge. This can be both noticeable and distracting, lowering the perceived quality of the output.

Currently, both the detect-crop tool and the --crop detect function of transcode-video can be configured to ignore the “optimal” shape algorithm. This is done via the --no-constrain and --no-constrain-crop options. So, I propose to make that the default behavior. However, I would still allow access to that “optimal” shape algorithm via new --constrain and --constrain-crop options.

The --help output of detect-crop would change to:

    --constrain     constrain crop to optimal shape

And the --help output of transcode-video would change to:

    --crop T:B:L:R  set video crop values (default: 0:0:0:0)
                      (use `--crop detect` for `detect-crop` behavior)
                      (use `--crop auto` for `HandBrakeCLI` behavior)
    --constrain-crop
                    constrain `--crop detect` to optimal shape

Of course, the old --no-constrain and --no-constrain-crop options would continue to be allowed, undocumented, until the next major revision. But they wouldn’t actually do anything since that would be the default behavior anyway.

So, I’m asking for feedback. Let me know what you think. Soon. Because I’m liable to implement this as early as next week since the change is trivial due to the way I’ve architected the code. Basically, it’s just flipping a boolean and changing the documentation. The hardest work will be re-writing the README document.

Thanks.