A little ffmpeg magic to remove those annoying black bars that studios insist on encoding into the media.

crop-black-bars.sh

#!/bin/bash

# a script that uses ffmpeg to detect the 'black bars' that are sometimes encoded into the video and then
# reencodes the video stream (only) to remove them and restore the content's original aspect ratio.
# if the original video codec used was MPEG2 or h264, it also re-encodes it to libx264.

input="${1}"
output="${input%.*}.crop.${input##*.}"

# scan 5 seconds of video, starting one minute in, to autodetect the cropping dimensions to use
crop=$( ffmpeg -nostats -i "${input}" -ss 60 -t 5 -vf "cropdetect=24:16:0" -f null - 2>&1 \
      | tail -3 \
      | sed -n -e 's/^.* \(crop=[0-9:]*\)$/\1/ p' )

echo "${crop}"

codec=$( ffprobe -v error -select_streams v:0 -show_entries stream=codec_name -of default=noprint_wrappers=1:nokey=1 "${input}" )

case ${codec} in
  mpeg2video)
    codec=libx264
    echo "converting mpeg2 to libx264"
    ;;
  h264)
    codec=libx264
    echo "converting h264 to libx264"
    ;;
  *)
    echo "original codec is ${codec}"
esac

ffmpeg -i "${input}" -map 0 -c copy -c:v ${codec} -crf 17 -filter:v "${crop}" "${output}"

Did you verify this crop detection? If I create a screen shot in vlc, I get eg an area of 1920x804 while the crop detection reports 1920x800.

ffmpeg version 3.4.12

Most video codecs require the frame resolution to be an even multiple - usually of either 8 or 16.

This script queries FFMPEG for the crop rectangle to use, and then passes it right back into FFMPEG to crop the video. There's no logic in this script that alters the crop rectangle produced by ffmpeg. It's being adjusted by ffmpeg encoder to meet the constraints of the destination codec.

The behavior is a result of design decisions made by the FFMPEG team. Should you want different behavior, feel free to modify the script. Enlarge the crop rectangle by rounding up to the next horizontal and vertical boundary, to get very thin black bars instead. Don't forget to subtract half the adjustment amount from the top-left of the crop rectangle, to keep the image centered between the thin black bars.

And yes, it's been tested... I use it frequently myself :)

Yes I read yesterday the man pages, should have done this earlier ;) With this cropdetect=24:2:0 I got the accurate values, but probably better indeed to stick to 16.

I also wondered why you did the re-encoding, I am trying to use something like this, but it does not seem to work with vlc 3

mkvpropedit test.mkv --edit track:v1 --set pixel-crop-top=138 --set pixel-crop-bottom=138

Did you decide to re encode because such things are not working? I also read something that cropping could be set with h264info tool, which should also not require re-enconding.

This could be interesting to alter in your script, I found this. I use the uniq -c quite often, and split the values into the bash array like this.
| grep -o crop=.* | sort | uniq -c | sort -n | tail -1 | grep -o "[0-9]*:[0-9]*:[0-9]*:[0-9]*"

I've found that few (no?) players honor the (advisory) mkv-specific crop parameters. At least none of the ones I care about. To avoid re-encoding the video stream, I'd have to write some fiendish code to remove black macroblocks at the edge of I-frames, and adjust co-ordinates of the B & P frames in a GOP. Honestly, there's a good reason no-one's done it already - it's both hard to get right and highly codec-specific. Modern encoders at pretty darn good if you're not too stingy with bitrates, so re-encoding does little harm. Just takes time.