Thank you so much for providing a sample file. We never would have solved this without it.
TL;DR: Shotcut is working as expected. The problem is that these MXF files are not the direct output of a broadcast program. Somebody has first transcoded them with Vizrt and used some unconventional settings. (Vizrt is in the metadata.) Here are the problems:
-
The video has PAL dimensions, but is using BT.709 colorspace which didn’t come into practice until HD resolutions. This is the first glaring clue we aren’t dealing with the original broadcast file. It should be in BT.601.
-
The interlacing field order in the MXF is top field first. Again, this is an HD thing. SD PAL should be bottom field first.
-
The top 32 lines of the MXF file are pure black, meaning RGB 0,0,0 (or Y 16). This level of color purity is unlikely in an analog signal. This was clearly black padding added by Vizrt. This begs the obvious question… if Vizrt is smart enough to recognize when carrier timing is in the vertical blanking interval (VBI) and pad that time with a pure black bar, why wasn’t Vizrt configured to eliminate the VBI completely? There is zero image data in the VBI to begin with, so why was this archaic timing preserved when nothing else archaic like BT.601 and interlacing field order was preserved?
-
The black bars on the left and right sides of the video are actually part of the video itself. Using the Video Zoom scope in Shotcut, we can see the color values of pixels in the left and right black bars, and we see actual low-intensity noise in those bars from an analog signal, meaning it is not digital padding added by Shotcut. Digital padding is pure RGB 0,0,0 (or Y 16 if you prefer).
-
Here’s the biggest problem… the pixel aspect ratio embedded in the MXF file is 608:405. Shotcut correctly interprets this information, but doesn’t show this ratio to the user. It takes
ffprobeor something similar to dig it out of the file. Unfortunately, PAL widescreen format is supposed to have a pixel aspect ratio of 64:45. This mismatch is why we get a squished image when trying to crop or resize. Whoever transcoded the file built the pixel aspect ratio on the incorrect 608 height instead of proper PAL specifications.
So here’s how we go about fixing it:
-
Create a new project using the DVD Widescreen PAL video mode preset (Settings menu > Video Mode > Non-Broadcast > DVD Widescreen PAL).
-
Bring in the video clip. Add the Crop: Source filter to remove 32 pixels from the top as before, but then also remove 8 pixels from the left and right sides to get rid of the black bars embedded in the video file. I used the Video Zoom scope to determine the side bars were 8 pixels wide.
-
At this point, we have isolated the active image area of the video, which is good. But it is squished and not filing the entire screen because the embedded pixel aspect ratio is not correct. We have to compensate for this with the Size, Position, and Rotate filter. Basically, we stretch the active image out to the full 720x576 canvas using distort mode, which allows a non-uniform stretch to overcome the wrong PAR embedded in the file.
-
Export with H.264 as you did before. Voila, done.
@Namna’s method works equally well. I went a different route because if the black bars that are baked into the MXF file happen to change size from video to video, then using Crop: Source with the Video Zoom scope is much easier to recalibrate the crop values. Plus, the crop values are all in one filter, rather than sharing half the crop work (for the left/right bars) with the SPR filter. Here, the SPR filter is always the same regardless of the size of the black bars in the source.
Screenshots of the filters I used are below, along with a Video Zoom scope showing noise (actual signal, not padding) in the black bar on the left edge. The scope can be found on the View menu > Scopes > Video Zoom.
Note below how RGB is not zero, and Y is not 16, meaning actual signal is in the left-side bar, meaning this is not padding added by Shotcut:
