The source tape is a VHS(x) copy from an unknown source. For all I know it could be from a HI8 analog source (upper field) or a copy from a DV source (lower field).
After I capture, the source is clearly interlaced, but Adobe Premiere 2018's field order scan thinks it's progressive.
The end result is going to be deinterlaced to progressive for youtube, but I'd like to know how I can identify what i'm working with here.
Lossless AVI has no field order. It's not set until you encode to a format (like MPEG) that does set it. However, the data itself is recorded either TFF or BFF.
Adobe Premiere is stupid when it comes to interlace settings, even when interlaced MPEG is the source. You must manually set it. It's always been that way.
Adobe does really lousy deinterlace. QTGMC in Avisyth, even on fastest setting, is better than anything Adobe will do.
HuffYUV from a capture card is top field first no matter what the source is.
I recently had a PAL VHS tape that was somehow BFF even with a Huffyuv capture. I still don't understand that. So odd stuff still happens. I had to re-encode the MPEG from it as BFF, and then it looked fine.
So how do I go about identifying which to manually set it at?
Quote:
Originally Posted by lordsmurf
Adobe does really lousy deinterlace. QTGMC in Avisyth, even on fastest setting, is better than anything Adobe will do.
Yeah the plan for most of the stuff is QTGMC but for a couple things I have to do some complex editing so it'll probably stay in premiere the whole time.
Difficult to believe the blind trust people have in overpriced apps like Premiere, but even more difficult to see people don't know that such a basic operation like field order analysis can be done with VirtualDub.
Open a huffyuv AVI in virtualdub. Mount VBDub's deintelace filter, use the yadif algorithm and set it for Top Field First (keep both fields). During motion, if you see back-and-forth movement in a frame by frame advance, the field order is not TFF, but BFF. If you pick BFF and motion is back-and-forth, then the video is TFF. In other words, if you set the correct field order, frame by frame motion will look correct when the frames are deinterlaced.
However, don't assume that all VHS movies are pure interlace. Hollywood films and old film-based TV shows are telecined, not interlaced. You can still use the deinterlace analysis, but recall that telecined movies are groups of combinations of progressive frames interspersed with "interlaced" frames. When progressive frames are deinterlaced, frame by frame movement will look like two duplicate images in a row (because both "fields" in a progressive frame contain the same image). The telecined frames act like interlaced frames, but one or two of those images will be repeated in each group -- this is the nature of telecine. Some foreign film might present you with blended frames that refuse to act interlaced and present the same double-image ghosting twice or even three times in a row. If you get one of these hybrid formats, submit a few seconds of motion for analysis.
even more difficult to see people don't know that such a basic operation like field order analysis can be done with VirtualDub.
Thanks for the steps! I just tried to do this test, and maybe you don't realize, for someone who doesn't use virtual dub every day, this stuff is far from basic. I've been doing hobby video for most of my life and it seems doing stuff correct ends with a week long rabbit hole every time
Quote:
Originally Posted by sanlyn
In other words, if you set the correct field order, frame by frame motion will look correct when the frames are deinterlaced..
There are four options when doing this method:
- discard bottom field
- discard top field
- double frame rate top
- double frame rate bottom
The first two I don't want (right?), and the second two seem to be duplicating the entire frame for both frames, aka having to advance two frames to see the picture change. Seeing as premiere also couldn't identify this (whether or not its garbage), i'm wondering if i've messed up the capture somehow, as yadif seems to not be able to deinterlace this.
- discard bottom field
- discard top field
- double frame rate top
- double frame rate bottom
You want either of the bottom two. One will play correctly, one won't. In this case I used TFF and the video played correctly. The video is pure TFF interlacing. Here's the yadif setup I used:
Quote:
Originally Posted by nicholasserra
yadif seems to not be able to deinterlace this.
Yadif is working, alright. You apparently aren't accustomed to using VDub's Input/output panels. The panels are set up correctly by default when VDub first runs. But in case the input/output panels have been changed somehow, this is the normal setup using the top menu's "View" drop-down menu:
Assuming the i/o panels are correctly set up, the image below shows how this rig works. The Input panel is on the left, output is on the right. The input panel shows the original, unaltered image. The output panel shows the effects of any filters that are applied. You can check the deinterlacing frame by frame by using the frame advance button shown on the lower left (pink downward arrow).
In this example we're using yadif to deinterlace and are retaining all the fields. Starting with frame 0, the interlaced image is in the input panel on the left. One of the deinterlaced fields will be visible in the output panel on the right.
- Advance forward with one click of the >> button. The input panel stays as-is; the next deinterlaced field, however, will appear in the right-hand output panel.
-Advance forward with another click of >>, and you have advanced to the next frame. The output panel shows the top field of that frame. Click the >> bottom again, and the input panel remains the same but the output panel now changes to show the bottom field of the current frame.
-Again, click >>. You move to the next frame. The input panel shows the current frame as-is, the output panel shows the top field. Click >> again: the input panel remains the same, the output panel now shows the bottom field.
Click >>. The input panel makes the next frame the current frame. Output on the right shows the top field.
Click >>. The input panel remains unchanged on the current frame. Output on the right shows the bottom field.
Click >>. The input panel makes the next frame the current frame. Output on the right shows the top field.
Click >>. The input panel remains unchanged on the current frame. Output on the right shows the bottom field.
Click >>. The input panel makes the next frame the current frame. Output on the right shows the top field.
Click >>. The input panel remains unchanged on the current frame. Output on the right shows the bottom field
And so on.
A few notes on your sample. Levels are fairly well controlled, although histograms and ColorYUV in Avisynth shows luma clipping in YUV and oversaturated red. An RGB histogram in VirtualDub also shows the same luma clipping near RGB 240 or so and Red climbs up the right-hand side of the histogram (VDub's RGB histogram isn't shown in the image below. But VDub does have one, trust us). In the image below, black borders and bottom head-switching noise have been removed to avoid affecting the graphs.
Man, there's a lot of scanline error noise in this video. Smeared chroma looks like a second generation copy of something, but at any rate someone's line tbc needs serious work. Look at the notched and "buzzing" and twittering vertical lines and edges, along with right-side sharpening artifacts (halos), excessive noise in the darker underexposed areas, some AGC luma pumping when the brighter lights enter the frame, smeared green, orangey looking reds, some color density loss. There is also some mosquito noise -- because mosquito noise is a lossy compression artifact and isn't caused by lossless huffyuv, it indicates that this video at one time went through some lossy compression, possibly DV. Note that Hi8 is analog and wouldn't have lossy compression noise of its own, although it's far from perfect.
It took some strong cleaning, but I used Avisynth to deinterlace with QTGMC and its denoiser settings, plus a few filters to clean up chroma noise, levels, general schmutz, and tried to calm the buzzing lines and edges. The attached mp4 below is the result, deinterlaced with QTGMC to double-frame-rate and resized to 640x480 with Spline36Resize to avoid blurring. Double frame rate works OK, although players like VLC have trouble with it even at 640x480 (I use Media Player Classic). You can't submit 720x480 to YouTube, but you can submit double-rate deinterlacing. If YouTube doesn't like it they'll delete alternate frames, but at least they won't use their own godawful deinterlacers. I guess some of the filters I used could be tweaked and a little of the original noise needs to be thrown back in so things will look more lifelike.
Last edited by sanlyn; 01-08-2018 at 03:30 AM.
The following users thank sanlyn for this useful post:
lordsmurf (02-03-2018),
nicholasserra (01-08-2018)
..And if you want to see what happens when you choose the wrong field order:
Set up your sample in VirtualDub as described above, but choose yadif's "double frame rate (bottom field first)" instead of TFF. This is the incorrect field order for your sample. When you advance frames, objects that should move right to left will stutter back and forth, left-right, right-left, left-right, right-left, and so on.
Say, this sample looks horizontally squished at 4:3 (640x480). You sure it's not supposed to be 16:9? If so, the square-pixel resize would be 856x480, not 640x480. If you wanted something smaller in a 640 width, the 16:9 resize would be 640x360, which is a valid mod-8 frame at 16:9.
Wow, thank you for taking the time to write this detailed post.
Quote:
Originally Posted by sanlyn
You apparently aren't accustomed to using VDub's Input/output panels.
Yup, that was it. For some reason I thought that second screen was some sort of tiling effect. After having this explained, I clearly see the difference between having the correct and incorrect field order selected with the deinterlace filter.
Quote:
Originally Posted by sanlyn
Man, there's a lot of scanline error noise in this video. Smeared chroma looks like a second generation copy of something, but at any rate someone's line tbc needs serious work.
Wouldn't surprise me if this was a high gen tape. There was also a TBC in the chain, a TBC1000 that I purchased from lordsmurf.
[quote=sanlyn;52102]
There is also some mosquito noise -- because mosquito noise is a lossy compression artifact and isn't caused by lossless huffyuv, it indicates that this video at one time went through some lossy compression, possibly DV. Note that Hi8 is analog and wouldn't have lossy compression noise of its own, although it's far from perfect.
[\QUOTE]
Given the year of the video (2002), I would expect this to have been shot on a dv cam of some kind.
Quote:
Originally Posted by sanlyn
It took some strong cleaning, but I used Avisynth to deinterlace with QTGMC and its denoiser settings, plus a few filters to clean up chroma noise, levels, general schmutz, and tried to calm the buzzing lines and edges.
Do you still have your avisynth script handy? I'm curious to see all the steps
Quote:
Originally Posted by sanlyn
You can't submit 720x480 to YouTube, but you can submit double-rate deinterlacing.
What do you mean by this? I've been uploading 720x480 to youtube for a long time, are you saying they resize it? And what was the reasoning for you resizing via avisynth?
Quote:
Originally Posted by sanlyn
Say, this sample looks horizontally squished at 4:3 (640x480). You sure it's not supposed to be 16:9? If so, the square-pixel resize would be 856x480, not 640x480. If you wanted something smaller in a 640 width, the 16:9 resize would be 640x360, which is a valid mod-8 frame at 16:9.
The output from the VCR appears to be 4:3 but I wouldn't rule out someone incorrectly doing this tape dub.
Just watched the new clip, wow does it look great O_O
You can't submit 720x480 to YouTube, but you can submit double-rate deinterlacing.
What do you mean by this? I've been uploading 720x480 to youtube for a long time, are you saying they resize it? And what was the reasoning for you resizing via avisynth?
Sure, you can nupload 720x480. But, yes, YouTube has been resizing them to square pixel. No anamorphic video on the net. Square-pixel only. YouTube's player can't handle anamorphic.
Quote:
Originally Posted by nicholasserra
Do you still have your avisynth script handy? I'm curious to see all the steps
I'd say the script needs some work, but likely I'd use the same filters. it depends on how the rest of the video looks. That buzzy edge twitter is the headache. I had two scripts, one for 4:3, one for 16x9. The latter looks more convincing, IMO. The two scripts are the same except for the resize statement near the end. below is the 16x9 script (it runs faster than it looks):
Code:
AviSource("path\to\field-order-sample.avi")
Levels(16,0.95,255,16,245,dither=true,coring=false)
Crop(4,0,-8,-8).AddBorders(6,4,6,4)
AssumeTFF()
SeparateFields()
FixVHSOversharp(20,16,12)
Weave()
ConvertToYV12(interlaced=true)
ContrastMask(enhance=2.0)
SmoothTweak(saturation=1.4)
QTGMC(preset="medium",EZDenoise=8,denoiser="dfttest",ChromaMotion=true,\
border=true,ChromaNoise=true,DenoiseMC=true,GrainRestore=0.3)
FixChromaBleeding()
DeHalo_Alpha()
## --- MDegrain 2 to calm buzzing edges, other noise ---
source=last
super = source.MSuper(pel=2, sharp=1)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, blksize=8, overlap=4, dct=0)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, blksize=8, overlap=4, dct=0)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, blksize=8, overlap=4, dct=0)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, blksize=8, overlap=4, dct=0)
MDegrain2(source,super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400)
TemporalSoften(4,4,8,15,2)
MergeChroma(awarpsharp2(depth=10))
LSFMod()
Spline36Resize(640,360)
AddGrainC(1.25,1.25)
## --- To RGB32 for two VirtualDub filters ---
ConvertToRGB32(interlaced=false,matrix="Rec601")
return last
### VirtualDub filters used on output:
### - CamCorderColorDenoise, set @ 32
### - Gradation curves to adjust bright red & green output at RGB 255
attached is a 640x360 square-pixel 16x9 version.
The following users thank sanlyn for this useful post:
nicholasserra (01-08-2018)
Beautiful, thank you. Does the Spline36Resize always do a resize to square pixels? Or where in that script is is explicitly saying "use square pixels"?
You mentioned 856x480 as a possible size for 16:9 video for this. Is that not ideal since the original video was 720? Or is that larger size only possible because of the square pixel conversion?
Regardless of the resizer in use, square-pixel refers to the ratio between the physical pixel shape and the displayed shape of the pixels. A 720x480 frame is neither square-pixel nor anamorphic, but phsyically a 720x480 frame has an aspect ratio of 3:2 on a square-pixel basis -- that is, the pixels are displayed at actual shape 1:1. However, the same 720x480 pixels can be displayed as 4:3 video or a DVD -- so the encoder is telling the player that the shape of the pixel is to be displayed as NTSC 0.9:1, meaning that the player considers the pixel to be a narrow rectangle. If the encoder encodes 720x480 for 16:9 display, the encoder is telling the player to consider the pixel shape to be 1.2:1, or a wide rectangle. Standard definition NTSC BluRay and AVCHD use the same 4:3 and/or 16:9 display aspect ratios requirements in 720x480 frames.
If you have a player or display system that plays only at 1:1 pixel ratios, the 720x480 frame displays as 720x480 (3:2), or wide rectangle) by default. Your lossless, unencoded 720x480 AVI has no display aspect ratio header data and is therefore displayed everywhere as square pixel 720x480 (3:2). 640x480 is a 4:3 aspect ratio physically and if displayed or encoded as 1:1 it makes a 4:3 image. 1920x1080 BluRay is physically 16x9 and encodes and displays as 1:1 pixel aspect ratios, so it is still 1920x1080 or 16x9 when played. Or, if you wish, you can encode your 1920x1080 video for a 2.4:1 display aspect ratio and the 1920x1080 image will be stretched horizontally by the player for that display ratio (but it will not be BuRay compliant! and it will appear as letterboxed on a 16:9 display).
If you are resizing for square-pixel media, the physical shape of the frame and the physical shape of the displayed image have a 1:1 ratio -- the physical frame and the physical image have the same shape or aspect ratio.
Hm I guess I always thought pixel aspect ratio was something that was embedded into the image data itself, not just a header.
So how does the 856x480 size come into play here? If the original frame is 720, does resizing to 856 mean It's being stretched?
If you want square-pixel 720x480 (3:2) to be 16:9, you have two ways of doing it:
1. Make it anamorphic by encoding the 720x480 video with a 16:9 display aspect ratio, as in DVD or SD BlueRay. A set top player or media player will then play the 3:2 frame stretched to 16:9.
2. Resize the square-pixel 720x480 3:2 video as square pixel 856x480 (16:9).
The ratio 16:9 is a ratio between width (16) and height (9). Mathematically 16 divided by 9 = 1.777778. Mathematically, 856 divided by 480 is 1.78333333, or as close as you can get to 1.77777778 using a legal mod-8 frame size. If you start with a 480 width, multiply that by 1.777778 and you get an exact frame width of 853.3333 pixels. Try that width in a player or encoder and you'll be in techy forums forever trying to figure out why you get distorted playback and/or error messages from your system. And you can't use odd-numbered frame sizes in legal video. Even numbers only. The nearest frame width that would be evenly divisible by 8 (mod-8) would be 856, not 853.3333. One reason you want mod-8 is that it's compatible with most playback systems and is a block size dimension expected by many filters. You could use mod-2 or mod-4 numbers, but many processing apps and players won't appreciate it at all, so save yourself some trouble and stick with the standard.
2. Resize the square-pixel 720x480 3:2 video as square pixel 856x480 (16:9).
This is what i'm not understanding. Where is the extra 136 pixels of image data coming from? Wouldn't this produce a distorted image, as it's being upscaled? Same as taking a small image and making it bigger than the original?
That's not much of a resize. The extra pixels are created by math that inrterpolates new pixels. The 480 height isn't even touched. If you think that's a resize to worry about, consider this: your 720x480 4:3 DVD's are resized to 1440x1080 (and almost 500 black pixels of pillarbox are added to the sides) by your HDTV, and your 720x480 16:9 DVDs are resized to 1920x1080 on the same TV. Your VHS is (approximately) 320x240 captured at 720x480. The new pixels are created on the fly by the geeks who engineer this stuff and understand the math and the pitfalls of a great many resize methods, using both hardware and software.
And by the way, VHS doesn't have pixels. VHS is analog. It uses waveforms, not pixels. All the pixels are created by your capture chain.
It's also accurate to say that some distortion or quality issues are involved in resizing, which is why it's usually not done unless necessary. This reminds me of users who think they'll capture VHS at big high definition frame sizes and have it look like "HD" (fat chance). There are also differences in filters and procedures that resize in different ways. For example, there are recommended methods in Avisynth for upscaling to HD sizes, but for downscaling HD to DVD sizes the methods are different.
The following users thank sanlyn for this useful post:
lordsmurf (02-04-2018)
That's not much of a resize. The extra pixels are created by math that inrterpolates new pixels. The 480 height isn't even touched. If you think that's a resize to worry about, consider this: your 720x480 4:3 DVD's are resized to 1440x1080 (and almost 500 black pixels of puillarbox are added to the sides) by your HDTV, and your 720x480 16:9 DVDs are resized to 1920x1080 on the same TV. Your VHS is (approximately) 320x240 captured at 720x480. The new pixels are created on the fly by the geeks who engineer this stuff and understand the math and the pitfalls of a great many resize methods, using both hardware and software.
And by the way, VHS doesn't have pixels. VHS is analog. It uses waveforms, not pixels. All the pixels are created by your capture chain.
You're blowing my mind again ha. Ok I think I got it. I'm gonna give this stuff a run and experiment with it a bit. Thank you so much for all this info!
And by the way, VHS doesn't have pixels. VHS is analog. It uses waveforms, not pixels. All the pixels are created by your capture chain.
Just to add some info for our OP...
VHS has a resolution equivalency.
VHS has 240 lines (||||||etc, not ----), with full vertical.
So about 240x486 in digital terms, at minimum; or 350x486 if you are a Kell purist. Either way, under 352x480.
Resolution is also affected by color. Even 4:2:2 is an equivalency, which is closest to VHS.
And a reason why DV 4:1:1 is terrible, as it's essentially reducing resolution/info from an already-marginal VHS quality.
