[ZwartePiet]

Some DVDs are encoded with black bars on all four sides to accommodate CRT overscan. It's not that obnoxious, but it would be nice to crop out the bars without re-encoding the video. This appears to be possible with third party video players (e.g. VLC) that respect crop flags found in the .mkv container. The movie file isn't changed, it's just presented differently.

My goal is to turn this:



into this:



I'm pretty sure the Pi's VPU doesn't support this feature (few, if any hardware players do), but the Pi 2 is powerful enough to software render SD content.

[noggin]

For info - the black bars aren't necessarily there to compensate for overscan per se. They are just there.

Technically lots of SD video can have black bars on the left and right if they have been mastered strictly in accordance to video standards. This is because 720x576 and 720x480 are technically wider than 4:3 or 16:9 aspect ratio video (a result of the 13.5MHz sampling rate that they, and ITU/Rec/CCIR 601 sampled SD video is based on).

Technically SD 576/50i video has an active picture width of 702x576 (not 720x576). The standard allows for video content in the extra 9 samples each side - but they are definitely not required to contain video, and if you are fully compliant, when you down convert 1280x720 or 1920x1080 video to 576i you should scale the 1280x720/1920x1080 to 702x576 (NOT 720x576). Incidentally this is why many DVB SD services encode in 704x576 not 720x576 (704 is the nearest MPEG multiple to 702)

Lots of PC media replay solutions ignore this of course, and when DVD and other SD content is upscaled the 720x576 content is scaled to 1920x1080/1280x720 rather than the 16:9 active area of 702x576 which is what should happen with a compliant solution.

Suspect that black bars top and bottom are there because of a telecine scanning choice to cope with an aspect ratio that isn't quite 16:9. You may also have what are known as 'blanking' errors - which is where there has been a slight timing issue somewhere in the chain - but it's less likely to be around in a digital set-up than an analogue one.

None of this helps with the MKV crop parameters being respected - but AIUI it isn't overscan compensation taking place.

[popcornmix]

If cropping information is encoded in the bitstream (e.g. SPS for h.264) then I believe the HW decoder on Pi will discard pixels outside of the crop rectangle and a smaller resolution video will be reported. In theory you can alter the SPS without reencoding the video but I'm not sure which tools support this.

As far as crop regions from the container, then I'm not sure if ffmpeg/kodi parses these. Does this work on any kodi platform?
However if this were parsed and passed through then Pi would support it (we already handle arbitrary source and dest rectangles in the renderer).

[ZwartePiet]

Very interesting. Thanks for the detailed reply. The more I dig, the more I learn. Getting a little scared how far the rabbit hole goes..

Is there a better way to deal with this problem? I used handbrake's preview window to determine the cropping values, then edited the MKV header using MKVToolNix. VLC respects the top and bottom crop value perfectly. The left and right crop values work, but a green vertical line shows on the right side of the video. When I encode the movie in Handbrake with the same cropping values, it plays in VLC perfectly (i.e. no green line).

[ZwartePiet]

If cropping information is encoded in the bitstream (e.g. SPS for h.264) then I believe the HW decoder on Pi will discard pixels outside of the crop rectangle and a smaller resolution video will be reported. In theory you can alter the SPS without reencoding the video but I'm not sure which tools support this.

These are MPEG-2 DVD rips. My basic understanding is that h.264 added the cropping feature.

As far as crop regions from the container, then I'm not sure if ffmpeg/kodi parses these. Does this work on any kodi platform?
However if this were parsed and passed through then Pi would support it (we already handle arbitrary source and dest rectangles in the renderer).

I've only seen it (partially) work in VLC. So this is a feature suggestion that needs to be directed to Kodi in general?

Would the Pi 2 need to fall back to software decoding if Kodi added this feature? Can the Pi handle this for SD content? Will it choke the OSD GUI frame-rate doing so?

[popcornmix]

Would the Pi 2 need to fall back to software decoding if Kodi added this feature? Can the Pi handle this for SD content? Will it choke the OSD GUI frame-rate doing so?

No need. This is purely a rendering feature which is supported in MMAL renderer for hardware or software decode.
However Kodi needs to parse this info, and it may not (can you test on kodi on windows for example?)
Assuming it doesn't then a post in the feature requests forum is best. If this gets support in Kodi, I'll make sure the Pi builds support it.

[ZwartePiet]

It didn't work in Kodi on OS X. I'll check on Windows as soon as I can, but I assume it'll be the same.

Thanks for the help (and good news). I'll post this in the feature requests forum and put on my best puppy dog eyes.

[popcornmix]

Include a link to a sample file with cropping information and describe what the desired behaviour should be (e.g. should behave like VLC, or whatever player does support this).

[ZwartePiet]

Good idea. Here's a link to my feature request thread if you have any other suggestions. I'll add a sample file there as soon as I can get one edited and uploaded.

A potential problem is that VLC respects the cropping tags, but doesn't play the file perfectly. I'm not sure why it's adding a green bar to the right of the image. The cropped version I encoded through handbrake uses the same video dimensions/aspect ratio and plays fine.