digitalFAQ.com Forum

digitalFAQ.com Forum (https://www.digitalfaq.com/forum/)
-   Edit Video, Audio (https://www.digitalfaq.com/forum/video-editing/)
-   -   Order of operations for Crop/Mask overscan before encoding to final MPEG? (https://www.digitalfaq.com/forum/video-editing/12210-order-operations-crop.html)

rprilenski 09-30-2021 11:23 AM

Order of operations for Crop/Mask overscan before encoding to final MPEG?
 
When our captured format is 720x480 NTSC, it has been mentioned that we crop from 720 to 704 and then resize 704 to 640. There are three scenarios that come to my mind.. The videos are and will be interlaced and will not be streamed online..Please educate me..

1: Is the crop, mask & resize all done within the resize filter in VirtualDub to mask vertical and horizontal overscan/head switching noise? Thus cropping the format from 720x480 to 704x480 then resize to 640x480. Then encode to MPEG keeping the same 640x480 format? My understanding of this scenario is that removing horizontal pixels is fine but if I remove vertical pixels and resize, this would mess up the interlace thus making this scenario null. The only way to accomplish this scenario is to deinterlace before attempting but decreases quality.

2: Or do we crop (even number of pixels) and mask vertical and horizontal overscan/head switching noise with a matte border in VirtualDub keeping the source 720x480 the same. Then resize when we encode to MPEG using one of the encoding softwares and set it to 640x480?

3: Or do we crop (even number of pixels) and mask vertical and horizontal overscan/head switching noise with a matte border in VirtualDub keeping the source 720x480 the same. Then encode using the same 720x480 MPEG format for viewing on TV/computer which then displays it as 4:3 AR despite the TV/Computer with 16:9AR?

latreche34 09-30-2021 02:04 PM

What ever you do do not delete your captured master files.

You don't really need to resize to 640, 704x480 is a legal resolution once encoded to a final playback codec it can be displayed correctly by any modern device, and when I say any modern device I tried several of them, iPhones, Androids, tablets, smart TV's media players ...etc. 640x480 is the 8bit era of computing and thank God it's gone. So don't get scared of non square pixel format, it is part of video codecs and it will be played back just fine.

As to mask or not to mask, that's your personal preference, I personally never mask the head switch, as noisy as it is it's still contains usefull video lines. Except for online uploading I crop everything out since the audience usually don't understand analog video and the noises assiciated with it.

I wrote a post about this subject before, Another thread about cropping.

And here is a nice post from a member of Videohelp talking about the 640 era:

Quote:

Originally Posted by edDV (Post 2068037)
Sorry for the mocking tone toward computer nerds but the worlds of Rec-601 non-square pixels and computer oriented square pixels evolved separately. Other video parameters differ as well

Rec-601 SD video uses Y,Cb,Cr color space, is mostly interlace and is optimized for analog to digital conversion plus efficient use of transmission bandwidth. A key issue is support of both 704x480i 29.97 fps ("NTSC") and 704x576i 25 fps ("PAL") using the same 13.5 MHz sample rate. Rec-601 supports 4:3 or 16:9 aspect ratios by altering pixel aspect ratio. This means all world standards can be handled in a single transmission channel at the same bit rate. Formats derived from Rec-601 include DV, DVD, DVB, ATSC, AVC and VC-1.

Computer square pixel video is generally RGB, progressive, has a more linear gamma and is based on a 4:3 aspect ratio, 640x480 frame at nominal 60Hz display rate. Computer display cards include "full screen" scaling.

The two worlds are bridged by capture hardware, display cards with video overlay buffers and specialized software players. Essentially, analog or digital video must be converted to square pixel, RGB for computer display.

Divx and Xvid commonly use square pixels and have limited support for Rec-601 resolution. In the PAL case, 704x576 is usually deinterlaced, then converted to 704x528 or other multiple of 16 on both axies. Other aspect ratios are accommodated with square pixels such as 2.35 to 1 movies to 720x306 again sized to 16x16 pixel blocks. Often slight side crops or aspect ratio distortions are needed to fit the 16 rule.

These aspect ratios are not strictly legal for DVD without conversion back to 704x576 or 720x576. Divx the company scored a major coup by convincing some DVD player manufacturers to include square pixel divx/xvid codec support with auto scaling into a 720x576 frame. This feature has also been included in many digital TV sets.

So, one can stay in strict Rec-601 resolution and MPeg2 for DVD authoring, or can go rouge with square pixel divx/xvid codecs. All DVD players must play a formal DVD. Results using divx/xvid codecs may vary since this is outside the DVD standard. Screen scaling, levels and gamma may be off when divx/xvid is used. The main quality killers can be artifacts from deinterlace or from over-compression.

And then he goes on to say:

Quote:

Originally Posted by lordsmurf (Post 2068167)
Quote:

Originally Posted by edDV (Post 2068007)
5. Unfortunately, your choice of the Xvid codec is both DVD and interlace unfriendly. Xvid is more a hacker computer nerd format. Computer nerds are interlace phobic and don't even begin to comprehend rectangular pixels. Their reaction to 720x576i capture files is like a little girl seeing a mouse. They cry Eeekkkh! Then they insist on destructive deinterlace, then squish the hulk into square pixels. Some like 720x540 for 4:3 aspect ratio, some like 720x405 for 16:9. But digital video fights back unless resize divides into 16x16 blocks. Fellow geeks laugh at newbies for choosing 720x540 or 720x405.

I'll stop for questions..

Nice. :p



All times are GMT -5. The time now is 01:06 PM

Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.