480x480 Interlaced: to Resize or Not?

[dscar]

So I've got some old captures I found in mpeg2 format. I'd like to preserve as much quality as possible, but wanted to crop/mask the overscan area and add to my Plex library. So... since I'm having to process them, I figured I'd deinterlace and resize via virtualdub and then transcode using vidcoder.

Source:
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : M=3, N=30
Format settings, picture structure : Frame
Duration : 19mn 52s
Bit rate mode : Variable
Bit rate : 2 179 Kbps
Width : 480 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Frame rate : 29.970 (30000/1001) fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.315
etc.


Question time: When resizing, would you change the 480x480 video to a resolution more readily acceptable for viewing on a pc? Or should I just leave it alone, and continue to scale in media player(s)?

[DB83]

If you are talking about VHS head-noise then overscan should hide that regardless. And it never bothers me when I see it.

You want to retain as much quality as possible. De-interlace and you immediately lose 50%.

If your Plex can play the 480*480 at the correct 4:3 AR then why try to fix something that is not broken.

[dscar]

These are some old wood working shows that were pulled off of a DirecTivo unit long ago. Original files would have been TY, passed through GopEditor (I think) to trim and saved out as .vob's. I'm guessing that the DVR recorded the broadcast source at 480x480.

I've got no problem leaving interlaced. I did several tests for quality, and figure maybe the best thing will be to just mask the mpeg2 file and encode in VirtualDub, remux with original audio.

I'm trying to move as much to x264 as possible. Otherwise Plex served from my NAS just can't handle mpeg2 or non-x264 media (apparently). That could be another issue. Still, the Samsung TV Plex app plays the 480x480 files with the correct aspect ratio, but all other devices (android, iOS, PC web player) display a square image as you might expect. I guess the TV somehow recognizes or reads the aspect ratio in a different way?

So, a.) leaving interlaced, b.) masking the overscan noise, c.) converting to x264, what might you suggest regarding size?
I'll keep the HDD with the unmolested video files in a static bag next to my mountain of DVDs. Just trying to make the content consumable in today's world.

[jagabo]

If you have players that don't respond to PAR/DAR flags you have no choice but to resize to square pixels. Assuming an ITU capture, I would use AviSynth's QTGMC to bob deinterlace, resize to 654x480, crop away the black borders and head switching noise leaving mod 4 frame dimensions, then encode.

[DB83]

And if you are thinking of cropping off that 'noise' then with mpeg2 you really have no choice but to de-interlace BEFORE you crop just as jagabo shows in his work flow.

Yet I do find it odd that certain players can not handle mpeg2 with DAR at 4:3 whatever the dimensions of the recording. It was not uncommon that older broadcasts used such ratios as it cut down on bandwidth and limited satellite etc. capacity.

[jagabo]

And if you are thinking of cropping off that 'noise' then with mpeg2 you really have no choice but to de-interlace BEFORE you crop just as jagabo shows in his work flow.

You can crop without deinterlacing as long as what you crop is mod4 vertically (eg, you can crop 4 lines off the top of the frame and 8 lines off the bottom of the frame) and mod 2 horizontally (eg, 6 columns on the left, 10 columns on the right).

Yet I do find it odd that certain players can not handle mpeg2 with DAR at 4:3 whatever the dimensions of the recording. It was not uncommon that older broadcasts used such ratios as it cut down on bandwidth and limited satellite etc. capacity.

Not to mention that all DVDs use MPEG 2 and none of them are square pixel.

[dscar]

Yet I do find it odd that certain players can not handle mpeg2 with DAR at 4:3 whatever the dimensions of the recording. It was not uncommon that older broadcasts used such ratios as it cut down on bandwidth and limited satellite etc. capacity.

Not to mention that all DVDs use MPEG 2 and none of them are square pixel.

My mistake here. Mpeg2 file played back properly, but my processed x264 file did not. I was using the VirtualDub->Resize/Crop method described over at digitalfaq. I think this is where I lost my 4:3 flag. So I've got to figure out how to account for the aspect ratio using that method.

I'm cropping 2 pixels from the top, 6 from the left, and 4 from the right; which produced a centered video without the overscan data. That portion seems to work fine interlaced.

Still no idea why my Samsung TV app plays the transcoded (x264) version correctly while all others balk (though, it's also is the only device I have that will direct stream mpeg2 and xvid files from my NAS). I suspect that has to do with Plex' video player development, or lackthereof on that platform.

Attached source clip for reference.

[DB83]

Essentially it is my understanding that some codecs to not recognise the DAR flag which is why you then have to resize to an actual 4:3 ratio.

But I am at a loss as to what you have done to that video. It is not the same as the first one you referred to which was reported at mpeg2. This one is reported at mpeg1. And mpeg1 or 2 is pretty odd in a avi container. And that itself could be one reason for certain players baulking.

Better to use another editor such as avidemux and create an mp4 or if you must use vdub either a variant that has the appropriate x264 filters or virtualdubfiltermod aince the basic one only exports to avi.

[dscar]

Essentially it is my understanding that some codecs to not recognise the DAR flag which is why you then have to resize to an actual 4:3 ratio.

But I am at a loss as to what you have done to that video. It is not the same as the first one you referred to which was reported at mpeg2. This one is reported at mpeg1. And mpeg1 or 2 is pretty odd in a avi container. And that itself could be one reason for certain players baulking.

Better to use another editor such as avidemux and create an mp4 or if you must use vdub either a variant that has the appropriate x264 filters or virtualdubfiltermod aince the basic one only exports to avi.

That was the wrong sample file (I had used avidemux to trim a short segment originally). I can't seem to figure out how to replace or remove that file. Let me try this again:

I'm actually using VirtualDub I got here with the x264vfw codec, but VirtualDub_FilterMod would probably work just the same. My understanding of the following "resize/crop" method is that no real destructive resizing is occuring when Framing options are equal to source Size (see below)
Import my clip in vdub -> Add "Resize" Filter ->

[Attachment 42913 - Click to enlarge]
"Cropping" button ->

[Attachment 42914 - Click to enlarge]
Video Compression (x264vfw, CRF = 17) -> No Audio -> Save as AVI

Drop both the New x264.AVI file and original .mpg into MKVToolNix, muxing only the mp4 video and original mpg audio
So is born my new x264.MKV

Lets see if I can attach the proper file this time.

[sneaker]

My understanding of the following "resize/crop" method is that no real destructive resizing is occuring when Framing options are equal to source

There's the "null transform" filter for that. Then you can be sure you don't accidentally do any processing (except the cropping).

(With interlaced YV12 make sure you crop/resize only to mod2 width and mod4 height. http://avisynth.nl/index.php/Crop#Crop_restrictions)

[jagabo]

1) VirtualDub is unaware of aspect ratios. If you want to retain aspect ratio information you must do so yourself at the codec level. x264vfw allows you to set the SAR (sampling aspect ratio). For a 4:3 DAR video encoded in a 480x480 frame the correct SAR is 4:3. Players may or may not pay any attention to the codec's AR flags. Not all codecs support AR flags.

2) The AVI container can flag aspect ratios via the ODML 2 extensions. But few editors set those values. And few players pay any attention to them if they are there.

3) Many hardware players pay no attention to aspect ratio flags at the codec or container level. Especially with AVI file. AR support is a little better for MP4 and MKV files.

4) You can crop interlaced video by mod 2 vertically (eg, 2 lines off the top) without disturbing the field order of the luma component. But with YV12 chroma subsampling colors will be slightly blurred. That's why it's better to crop mod 4 vertically.

5) The MKV video in post #9 has no SAR or DAR information. So most media players play it as square pixel. You should set the SAR in x264vfw and the DAR at the container level. Some players will pay attention to one at least one of those.

Attached is your 480x480 MKV with SAR (codec level, changed with h264 ar changer) and DAR (container level, changed with mvktoolnix) flags set. It may play proper on some devices.

[dscar]

Thanks all. I think I'm getting it.

So to summarize, keep my videos interlaced where possible. Cropping this source requires mod4 for height, mod2 is ok for width. Finally, make sure I encode with SAR=4:3 (codec), and DAR=4:3 when muxing.

If I wish to revisit deinterlacing, I should probably learn to use Avisynth - QTGMC.