Can't Crop Away Burned-In Pillarbox Black Bars

[Alwyn]

I have come across a problem I can't work out. I have quite a few music videos that I recorded from FTA (Aussie ABC's "Rage" program), which were transmitted in 16:9. Most of the videos, though, are 4:3 from the old days, so they have burned-in black pillarboxing. This is causing issues with one of my Android video players so I thought I'd just crop the side bars away to make the file a true 4:3 shape.

The problem is that VideoRedo, Virtual Dub 2 and AVIDemux all seem to ignore the burned-in black and I can't actually crop away anything, so when I export the new file, it's either distorted or still has the black side bars. Interestingly, my Magix NLE knows they are there and I can crop them away with no issues. It just takes a long time to export.

For example, in VDub, the black sides are visible on opening but as soon as I go to the crop filter, the black sides are ignored, only the actual image is displayed and if I drag the crop sides slightly, the crop setting jumps to approx -100 pixels immediately.

I've attached a sample 16:9 file with the pillarboxing.

If anybody could shed some light on how to get, preferably VDub, to allow me to crop the size bars away or at least what's happening here I would be grateful.

[Sharc]

Maybe I misunderstand the issue, but I don't get a problem with Vdub and cropping. Did you have some auto-crop enabled?
Crop left and right 100 pixels each side (or whatever you like, mod4), and reencode with SAR 16:11 (= the same as the original SAR).
Just don't resize the interlaced video vertically, or deinterlace it before resizing.

(Added: The clip suffers from other issues, probably from a frame rate conversion. But this was not the question...... )

[dellsam34]

For example, in VDub, the black sides are visible on opening but as soon as I go to the crop filter, the black sides are ignored, only the actual image is displayed and if I drag the crop sides slightly, the crop setting jumps to approx -100 pixels immediately.

Maybe because your file doesn't contain burned-in black bars at all, The resolution is 720x576 SD standard, So it could be that your recorder is adding a flag to display 704x576 (704 active video, 16 padded black bars) in 4:3 and adding more black pixels to the original 16 to fill the 16:9 frame.

I'm not a coding expert here but members like Jagabo can chime in and give you more clues, Maybe remove the AR flag, crop 720 to 704 and re assign a new SAR to the video so you will get a new clean frame, Or resize to a square pixel format.

[ProWo]

Use clever FFmpeg-GUI.
Load your mpeg, click main, click encode video stream, click crop detect, control with preview, click ok,done.
In the next screen set all like in the picture, click encode.


[Attachment 69780 - Click to enlarge]

Then click multiplex, set the new created green videostream and the audiostream, click multiplex.
Done

[dellsam34]

Examining the original posted file further it does seem like it has burned in black pillars, but the strange thing is the entire frame including the black pillars is encoded in 720x576 anamorphic 16:9, I have never come across an SD file encoded like this, Maybe you had the wrong setting in the DVR to output 16:9, If you try to change that to 4:3 maybe it will produce an original 4:3 frame, Having black bars within the 720 pixels reduces the horizontal resolution of the active video lines to 512 pixels (according to ProWo screenshot) instead of 704.

[davexnet]

We're all seeing some thing different it seems. According to mediainfo, the file is AVC in mp4. Resolution is 520/576, display A/R is 1.284,
giving a display size of approx 740/576
I don't see any bars except may 3 or 4 pixels on the left

[ProWo]

We're all seeing some thing different it seems. According to mediainfo, the file is AVC in mp4. Resolution is 520/576, display A/R is 1.284,
giving a display size of approx 740/576
I don't see any bars except may 3 or 4 pixels on the left

The file from post #1


[Attachment 69798 - Click to enlarge]

[Sharc]

From the blended fields I would conclude that the original was NTSC 704x480 SAR 10:11 (DAR 4:3)
This has been converted to PAL 704x576 SAR 12:11 (DAR 4:3)
Then it was converted/authored to 16:9 PAL format which requires SAR 16:11 for standards compliance => keeping the vertical at 576 means the horizontal (active picture) had to be squashed to 528 and padded to 720.
Hence it has the black pillars and is reported as 720x576.

[DB83]

Since I am a little bored right now, I took the video as I found it and threw it into avidemux.

Assuming 720*576 16:9 non-square, that would equate to 1024*576 square


A 'perfect' crop to 4:3 square would be 768*576. However that does leave a small border as seen in the resulting video now outputed as 720*576 non-square

[davexnet]

We're all seeing some thing different it seems. According to mediainfo, the file is AVC in mp4. Resolution is 520/576, display A/R is 1.284,
giving a display size of approx 740/576
I don't see any bars except may 3 or 4 pixels on the left

The file from post #1


[Attachment 69798 - Click to enlarge]

Oops - looks like I downloaded sharc's file from post#2 - sorry about that

[Alwyn]

Thanks all, in the end it was multiple finger trouble. For VDub, I hadn't expanded the cropping window enough to see the side bars, and in AVIDemux I don't know what I did initially but I have it working now.

the strange thing is the entire frame including the black pillars is encoded in 720x576 anamorphic 16:9, I have never come across an SD file encoded like this, Maybe you had the wrong setting in the DVR to output 16:9

I don't think so. That MPEG came straight from WinTV (being the Hauppauge TV recording program). The broadcast was in 16:9, which is reflected correctly in the file.

DB83, I'm pleased I unbored you for a bit!

[netmask56]

All Australian digital TV is 16:9 regardless of aspect ratio of content so it is normal to have black bars left and right for 4:3 material and top and bottom for Scope. In the case of RAGE, some material in assemblage would have blurred side windows for 4:3 material whilst some might be black, blue or grey side bars, whatever! So you should be able to crop to 4:3.

[dellsam34]

Here is what I see on my end, Anyone seeing otherwise?

[_Al_]

We can see sort of all the same, op mentioned he made a mistake.

[Alwyn]

@Dellsham, yes, I mistook VirutalDub's display for some sort of autocrop feature. For some reason, every time I opened the VDub Crop screen, it would not display the black sides. I thought, initially, that this was by-design, but eventually found I could drag the crop window "larger" and sure enough, there were the black bars to be cropped off, as you show. Lesson learnt.

[DB83]

^^ You might have been thinking of handbrake which does have autocrop on by default.

One little thing (which may not trouble you). If you do crop away all the bars and then resize back to 4:3, your image will be slightly stretched as I pointed out in my earlier reply. Mind you, cropping, resizing to 4:3 and display full-screen wider than 4:3 brings back the bars

[Alwyn]

You might have been thinking of handbrake which does have autocrop on by default.

No, I wasn't.

One little thing (which may not trouble you).

It would, but I decided to go cropping with my NLE that draws out a neat 4:3 crop box. You'll note that I have chopped off more of the top and bottom, which compensates for the effect you mentioned.


[Attachment 69846 - Click to enlarge]

You did pique my interest in how to do this is VDub and I decided to resize the whole thing to 1024x576, then crop as necessary (including a bit off the top and bottom) to achieve a 4:3 ratio by multiplying the cropped vertical size x 1.333 to come up with the total amount of side cropping required. The Cropping preview screen is distorted but that doesn't affect the actions. So thanks for that.

I now have to work out whether to crop all bars away and lose some top and bottom image or leave the small black side bars in. I wonder if my heretic's hat will win??

[DB83]

Well that's all fair enough.

But the only proper reason for cropping the vertical is to remove head-switching noise apparent on a VHS capture. But since your source is already digital and DV , at that, there seems to be no real benefit to that.


One could do the cropping one stage further - but it gets more complex when one compares 720 width to 704 width with non-square source ie it is not so simple to crop the 8 pixels left and right and DV always AFAIK uses the full width.


Of course, others will have a different opinion to mine - that is the 'beauty' of a forum such as ours - but my personal choice would be to, at least, start with a pure 576 vertical resolution and work it from there.

[Sharc]

@Alwyn: Why make life so complicated? Why bother with some "exact" 4:3 frame? Crop as you like (mod4) and encode with x264 at SAR 16:11, and let the player do the rest as has been discussed in the other thread with your Lotto Draw, SAAA clip etc. where you confirmed that it played correctly (means geometrically undistorted objects) on all your tested devices.
Easy in Vdub2 (attachment) or Avisynth, no need for intermediate steps using an NLE.
Anyway, to each his own of course. You certainly have your reasons.

[Alwyn]

@Sharc, OP:

This is causing issues with one of my Android video players so I thought I'd just crop the side bars away to make the file a true 4:3 shape.

Point taken, your 12:11 file works well. Square pixels are easier for me to comprehend.

but it gets more complex when one compares 720 width to 704 width with non-square source ie it is not so simple to crop the 8 pixels left and right and DV always AFAIK uses the full width.

I wonder if the publishers of these 4:3 videos+black side bars considered the 704 issue?

[Sharc]

Point taken, your 12:11 file works well. Square pixels are easier for me to comprehend.

16:11 in this case. not 12:11. Here again the SAR catalogue for common formats:

PAL 4:3 SAR=12:11
PAL 16:9 SAR=16:11
NTSC 4:3 SAR=10:11
NTSC 16:9 SAR=40:33

I wonder if the publishers of these 4:3 videos+black side bars considered the 704 issue?

702, 704, 720 you will never know unless the video contains a straight circle or perfect square with which you can do the "circle test".
(Above SAR values assume the "704 case" btw.)

Edit:
If you watch your clip carefully you may see that the wide black pads actually consist of small greyisch left and right pillars which are then padded (complemented) to the full width with true black bars. This is an indication at least (but no proof) that the original active picture was ~704 i.e. Rec.601 compliant. Best guess only, as there is no circle or square in the clip to perform the test. Anyway, if done incorrectly, the AR error will be the notorious ~2% only.

[Alwyn]

16:11 in this case. not 12:11. Here again the SAR catalogue for common formats:
PAL 4:3 SAR=12:11
PAL 16:9 SAR=16:11
NTSC 4:3 SAR=10:11
NTSC 16:9 SAR=40:33

This is a 4:3 video.

Also, here you say 16:15 is the go. Is that only for MPEG 2?

[Sharc]

16:11 in this case. not 12:11. Here again the SAR catalogue for common formats:
PAL 4:3 SAR=12:11
PAL 16:9 SAR=16:11
NTSC 4:3 SAR=10:11
NTSC 16:9 SAR=40:33

This is a 4:3 video.

Also, here you say 16:15 is the go. Is that only for MPEG 2?

Your .mpg file has been converted for DAR 16:9. It doesn't matter that the original was 4:3. The resizing changed the SAR from 12:11 -> 16:11.

(See also post#8 where I speculated about the history of that file. It's just for explaining. You don't have the true 4:3 original. You only have the converted 16:9 variant with the large pillars).

[Alwyn]

I'm not with you. The video in this thread (B52s) is now 4:3. We removed the side bits that made it 16:9, so now it's 720 (or 768) wide. How can the SAR be 16:11?

In the other thread, why did you say 16:15 for 4:3 whereas here you say 12:11 (for 4:3)?

[Sharc]

In the other thread, why did you say 16:15 for 4:3 whereas here you say 12:11 (for 4:3)?

16:15 = 1.067 is the SAR for 720 active pixels in the 720 frame; used for example in digital native DVD's
12:11 = 1.091 is the SAR for 704 active pixels in the 720 frame; a very tight approximation of Rec.601 analog transfers and - in our case - for VHS captures.

The difference is the notorious 1.091/1.067= 2.2%, or the discrepancy between 1.333... and 1.363 DAR for "4:3".

[Sharc]

I'm not with you. The video in this thread (B52s) is now 4:3. We removed the side bits that made it 16:9, so now it's 720 (or 768) wide. How can the SAR be 16:11?

Again: Your .mpg source with the pillars was DAR=16:9, SAR 16:11.
You can crop or pad it however you want. This does not change the SAR, it changes the DAR. So after cropping, encode it with the same SAR 16:11 to preserve the geometric shape of the objects. What will change - depending on your cropping - is the DAR of the picture which needs no longer be 4:3.
See the explanations in the other thread with your SAAA clip, car wheel clip, circle samples, explanations about cropping and resizing etc.

If you feel more comfortable with resizing to square pixels (or what you believe are square pixels) by upscaling, drawing 4:3 frames, cropping, slight resizing and whatever, so be it.

[Alwyn]

OK thanks.