Field repeats, tearing, wobbly lines?
 

In the Restored version of the second clip, one frame is repeated a couple of frames later as the player crosses the top of the key. Seems to occur as a still frame in the Original.

There's also tearing, although it only affects one field and seems to come and go at random. Not sure if that's just how tearing is, or not. I've had other tapes tear but it's been consistent enough that I picked it up earlier on in the process.

In the first clip, in the Restored version, the edges of the numbers are doing something weird. Not really sure what's going on there.

What's going on is that you have yet another godawful bad horrible ugly tape. Looks for all the world like a bad dupe. Whatever. Did the photog bother to get scenes in focus?

beginning in both of your samples has invalid levels. I didn't correct for that (you'd have to do it separately from other sections), I just worked with the second half. I don't know what you were trying to do with color on your restoral except replace a blue color cast with a brownish one. Likely it'll never look really great, the original chroma is a mess.

I love how you think these weren't shot by whoever they could find to volunteer for the job, usually a player from the squad who didn't make the team that week.

Where? I checked the restoration with ColorYUV and the luma values sit between 16 and 235 for all but a one-frame drop to 234.

I don't understand what you mean by this.

Yours still looks pretty blue (reference attached). Even in mine the lines and the court two backboards are quite visibly blue...no idea what's going on there. I picked out the black team's jerseys, the referee's white shirts, and a neutral mid (I don't recall what, offhand), and fiddled with the balance until they were all correct. Then grabbed someone's arm for a hue adjustment.

What's this doing? You appear to be completely getting rid of one field, rather than working on each field separately?

'Frame hops'?

I realize your guys aren't pros with a camera, but it's difficult to conceive how the original you posted came straight from an unaltered camera tape. If the sample is what the camera produced, it's indeed a darn sorry camera, putting you through some very hard and mostly unnecessary work.

The court action scene is much darker than the opening sequence. If you want a more natural contrast range for that second scene, then the opening shot would be too bright. You would have to adjust the contrast range in those two shots separately.

Your restoration is too red, especially compared to the off-color tones in your posted reference. That poor VHS "reference" color rendering should never be used as a reference, which is supposed to be a view of known values produced under precisely controlled conditions. Neither of us has such a reference. In any case, I figured that some of the posters along the wall would be white-ish, especially the two "Winfield Stadium" signs and some of the floor markings, and I supposed there was mostly green and blue in the court surface, plus some people in the audience appeared to be wearing white-ish shirts and some blackish or bluish-jeans trousers (but all of the darks look like chocolate). I don't see any of that in your restoration, so I'm assuming the sample you posted refers mostly to the noise and distortion problems and has nothing to do with color balance. Such a discussion about color is pretty academic anyway -- there's no way you can get any color accuracy out of the original sample.

'Your guys'? Tape is older than I am, and probably originated with the other team (which, yes, makes it likely that this is a copy).

I dug up duplicates of some of the other tapes in the archive recently as well, so one or both versions of those must be copies as well.

I actually do this job for a club in a smaller league now, which gives me access to the online portal with all the games across the league. One was yellow. I can only assume they white-balanced for a night game and left the settings the same for a day game and some natural light got in and ruined it, but it looks absolutely awful.

They're two clips from the middle of the game. They won't be the same shot, but it's just one camera being turned on and off based on whether the game is going on or not. The portion of that shot just before the move up to the scoreboard is lit almost identically to the second shot in my sample. So you'd have to fade/dissolve between two different brightness setups as the camera moves, or just blow out the scoreboard portion a bit. I'd favor the latter, given that 99% of the footage is of the game with only one or two moves up to the scoreboards.

Even then, mine is less blown out than yours; the world's most ironic no-smoking sign clips on your version.

'Off-color tones'?

Which makes what I've got better than nothing, at least. It's not even from the same year, but in the absence of alternatives it'll have to do. Certainly it's enough to indicate the court should be closer to green than blue.

If you want to critique the color balance, or anything else I don't mention, go ahead.

In terms of color, I think the biggest issue is actually the three-point line, rather than necessarily shooting for the most accuracy possible. In the original it's almost exactly the same color as the court, which I thought was just bizarre until I stumbled across that other footage and saw that the court was actually green. So I was shooting for the most contrast I could get between the three-point line and the court, within a range that made everything else look pretty much right.

I initially color-balanced the brights to the backboard against the wall, but that looked awful. I've found with some of these tapes that the lighting varies in such a way that it's often a waste of time to balance anything other than the players/referees and their uniforms, because that's where most of the footage is and everything else has some sort of cast.

I've attached a framegrab from Premiere of a zoom in on a couple of players, if that helps any.

EDIT: You missed my questions about 'frame hops' and the SelectOdd() lines.

No one's blaming you for the condition of the tapes. They're the owners' fault completely. I hope you've made aware of it. You're just doing the best you can with abused material.

The first thing I saw in the original was the obvious U/V imbalance. I elected to make an initial correction first in
YUV before going to RGB.

http://www.digitalfaq.com/forum/atta...1&d=1496940471

Initial YUV corection, before using RGB tweaks:

http://www.digitalfaq.com/forum/atta...1&d=1496940525

You can handle it any way you want, but I chose to correct in YUV first.

If you have a segment thast's crazy bright and the others are clearly, darker, you'll have to correct them separately to make levels match. In the correction business this is known as "color timing".

I did that for my own benefit, to take out at least 75% of the work of cleaning bad tracking fields. Almost all of the top tearing and backward-stepping fields are even fields. The even back-stepping fields indicate dropped fields. The result is 25fps progressive. If you like you can work through all original fields with all the bad frames at 50fps. But you can't use it for broadcast or disc authoring.

There are several instances of frame hop in the original -- actually, it's field hop, mostly even fields. Look at frame 208 in the original. Then play the restored version in VDub frame by frame and observe the vertical jitter (hopping).

Should UV necessarily be balanced, though? In this instance we know the court is somewhere between bluish green and green, and it takes up most of the picture, so wouldn't you expect the sort of thing shown in that first screengrab?

In that particular YUV histogram, the closer the channels and peaks get tighter around the center mark, the closer the picture will be to a grayed-out look or will look almost monocolor. No, it's not necessary to perfectly center everything, especially since a nature pic will have a lot of green or blue sky. I adjusted until I got something more workable and realistic IMO. Not that this sample will ever look so "right". It's been through too much. I hate it when that happens, you just do what you can. 10 people will come up with 10 versions of those frames.

How you'll get that court to look like your reference is a mystery to me. Maybe reflecting lights and ceiling affect it here.

Is there a 'them' missing after the 'you've'? If so, I'm not sure what you think that might achieve; everything's done digitally now (and as of a couple of years ago all games are televised, so no more amateur-hour garbage).

As I said previously, it's all from the one camera and the only cuts are when it's turned off for timeouts and between quarters; there are no 'shots' or whatever that clearly need different settings. I can only assume some sort of auto brightness on the camera affects things when it shifts from the court to the scoreboard.

I'm still not sure why yours blows out the no-smoking sign...or why there's a no-smoking sign in a stadium that is otherwise covered in Winfield signage.


You'd just pull out the old SeparateFields().SelectEvery(4,0,3).Weave, yeah?

I'm not sure what I'm seeing in frame 208...it definitely looks 'off', but beyond that?

I'm not quite sure what you're saying here.

I think the scoreboard looks better on yours, but the court itself looks closer on mine (not that either is quite right). Not really a fan of the color of the ball on mine either. On the other hand, I don't want to lose any more of the three-point line than is absolutely necessary.

Interesting you should mention reflections...there aren't really any. The reference clip makes it look quite glossy, whereas the tape I've got makes it look very matte. Almost like a tennis court surface. Which makes the game very painful to watch whenever someone gets knocked over or dives on a loose ball or anything like that.

I'm very much looking forward to a few years' time when I get to deal with TV broadcasts from stadiums with normal-colored wood floors.

I've played around a bit with ColorYUV but I can't come up with anything better than my first attempt. My first go was even more red, my second had green skintones and no contrast at all between the blue and black jerseys.

Is there anything to be done about the whitish line down the side of the ref's arm in the attached clip? I've tried FixVHSOversharp(), dehalo_alpha() and LGhost(), although I'm not sure if this is something they target.

You won't get rid of all of that ringing, which makes a mild bright ghost, especially since the sample vid has already gone hrough processing. I used the following:

Then I put the results in Virtualdub and used the exorcist anti-ghost filter:
http://www.digitalfaq.com/forum/atta...1&d=1497279122

Results:http://www.digitalfaq.com/forum/atta...7279155http://


Some fuzzy edges in that sample.

Where did you get RemoveDirtMC()? I've found a RemoveDirtMC_SE(), but it requires NLMeansCL2(), which I can't find? There's a KNLMeansCL, and an xNLMeansCL, but that's it.

The non-CLE version seen most often is by johnmeyer, from a very long post on videohelp and elsewhere. There's a link to that post in the attached .avs file, but the function is edited from the super-long script in the videohelp post. Some of the plugins used in that original long script will never be found again.

Hmm, wonder why the picture in my previous post doesn't show. Too busy to worry about it now.

It shows up if you click the attachment at the bottom anyway, so it doesn't really matter.

Any idea what's going on in this one? Going through frame-by-frame the scoreboard appears to 'wobble' horizontally, while the rest of the picture seems okay.

I think I've figured out the color balance: the mids have to stay blue. If you adjust the mids to neutral, everything else gets ruined. So I adjusted the brights and darks to the scope, then just did the mids by eye.

EDIT: Why the horizontal crop on the tearing script?

EDIT 2: And what's the quickest/easiest way to establish the correct numbers for cropping?

It's not just the scoreboard. The top 1/3 of the image wiggles horizontally, including the yellow frame braces. I see this in many captures, especially tape dubs. It's usually from the tape, either from deformation or from the tape wiggling across the heads. Sometimes it's recorded that way. You'd have to look at the original interlaced frames to see what's going on. You sample has been deinterlaced. Watch the original in Virtualdub and enable VDub's yadif to see what the fields are doing. I see similar effects in many restorations, especially on TCM and other movie channels. There's an infamous scene in Hitchcock's The 69 Steps in a room where people are talking and a bright table lamp in the background is shifting around while everything else stays still.

The color is a mess, alright. I'v encountered this many times. I just adjusted U and V offset until the channels were better aligned and the white markings looked white. Sometimes it's more complicated.

You mean post #2?
The top and/or bottom borders change thickness during the frame hops and tears. Also, Stab() moves the frame up and down and changes the borders as well. You'd have to crop enough to mask the border twitter. Sometimes the results are thicker borders than in other segments, but it's usually a very small difference that's undetected during play. Either that, or you'd have to live with twittery borders, which I think looks worse and is more obvious.

I guess everyone has their own way of doing it. I run a clip hrough VirtualDub with no other filters going (sometimes just a quickie basic script with no filters except maybe Stab() running by itself). Then I load VDub's BorderControl filter, scroll through some video, adjust borders visually, then use those numbers to crop in Avisynth. Some people just use BorderControl on the output, but it's difficult to get the frame centered that way or they use overly thick borders to make it look centered.

If you use something more drastic like VDub's DeShaker for a wildly wobbling video, you have to run the filter, save the file, and adjust borders with another script.

Sometimes it's less complicated: running a script in Virtualdub, I pause on a frame and adjust Crop numbers, then hit F2 and reload the frame to check for effect. Sometimes you don't notice something is off until after the script has run and you're reviewing the work. Pain in the neck.

Filters->deinterlace->'interpolate using Yadif'?

Does it matter which Field order I use?

You mean 39 Steps?

I have a copy of that, not sure if I've ever watched it.

I mean where you're going through and using ReplaceFramesMC to generate a piece to cover the tearing on bad frames. The vertical cropping is obviously to only replace the problem area, but I'm not sure why it's cropped four pixels from the left and six from the right.

My question about working out where to crop (in this case the amount to crop from the bottom) also related to this. I'm going through and there are a few standard dropouts, so I'm using the same script but they're obviously not in the same spot so I can't use your numbers and I'm not sure how to work out how far from the top/bottom of the screen to crop it so it covers the dropout without covering any more of the screen than necessary.


I don't have and have never heard of BorderControl. For that cropping I just open in VDub, apply a null transform, use VDub's cropping to adjust until I've obscured everything I want to be rid of, then add a 'resize' selecting 'crop/letterbox to size' by multiples of two.

Yeah, right, 39 steps not 69. My mind must have been elsewhere!. :eek:
The version I refer to is the Turner Classic Movies print, which looks to have been mastered from broadcast tape. I['d suspect something like a Criterion print to avoid that sort of thing. But maybe not.

Making and applying those little patches does depend on minimal motion. Unwanted motion like frame hopping is why I used Stab(). If I included running players and other objects it wouldn't have worked. I cut the edges short on the crop because I didn't include all of the side border area but you can if you want. I think one of those overlays had to be moved a pixel or so to one side, but it's hard to see during play. I write these coordinates down on a slip of paper while figuring it out and have to remember whether I'm cropping top, sides or bottom. It's kinda tricky and I make a lot of embarrassing (enfuriating) missteps. I tried the infamous median/averaging filter from lordsmurf but it did too much damage.

The border control plugin is here: http://www.hlinke.de/vdub-filter/brdcntrl235.zip. There are dozens (maybe hundreds) of little known and famous VDub filters here http://www.hlinke.de/tinc?key=U4rlLO...tualDub_Filter and here http://www.infognition.com/VirtualDubFilters/.

Why is that? Aren't you recreating the problem frames, rather than just pasting in a portion from a different frame?

How do you get the number in the first place, though? Just enter random numbers into the script until it works?

The code that creates the patch interpolats a new frame using ReplaceFramesMC, from the preceding and following frames. But I didn't want to use the entire new frame (it didn't work very well). You just want a small part of it. You crop that new frame so that it includes only the part of the image you want, and you overlay that new portion onto the existing bad frame.

Example: the first full patch creation and overlay code sequence from the posted script:

The first line creates a reference to the entire, original video and gives the reference the name of "source1":
The second line creates a work copy of the referenced video, for cropping and other work, and names it "b0" (the names of these working copies are arbitrary inventions, use whatever names you want):
"b0" is now saved for a later step. The next thing to do is to make a new reference copy of the video that uses ReplaceFramesMC to interpolate a new frame, in this case frame 168. Then crop off the portion of the new frames that you want to keep, and save this new reference copy as "b01":
The entire b01 reference video has all new frames that consist only of the smaller, cropped patches. We'll eliminate all those cropped-patch frames later, except for frame 168. For now, you want to overlay the original full-frame reference "b0" with all of those cropped patches from b01, and save these overlaid frames as new reference copy "b02". So this code overlays the full-frame b0 with cropped patches from b01 and uses x,y coordinates to place the patches where you want them, then saves the work as "b02":
Obviously the only new overlaid frame or frames you want to keep would be frame 168 in this case. So you want to refer back to the original source1 and overlay that video with the repaired frame 168 patch from the collection of overlaid frames in b02. Save the new version of the repaired video as Source2:
Because there are other frames to repair, I keep saving new copies of the original video as Source2, Source3, etc., because if you keep loading Source1 with every repair you'll just reload the old bad frames. Yes, you can keep saving new frames to the same Source1 name, but the last line of the code gets pretty complicated with each fix. I prefer to increment the names of the new repaired video.

The video ws first deinterlaced and Stab() was used to steady some frame hops, which usually happened on those torn frames. I repaired and evened the jittery borders created by Stab. Then I captured the frame in VirtualDub and pasted it as a new graphic in Photoshop. You can also use any graphics programs that lets you read coordinates as the mouse moves (Mspaint's status bar, for one, reads mouse coordinates).

You read the coordinates for left top, right top, left bottom, right bottom. Because you're building a rectangle which in this case has to be mod-2 for deinterlaced YUV, the left top and right top (x coordinates) will be different because of the width. The bottom (y-coordinates) will be the same because of the height.

Below, the original deinterlaced and Stab'd frame 168 with new borders and the top border rip marked with arrows:

http://www.digitalfaq.com/forum/atta...1&d=1497454674

The coordinates for cropping the section I wanted were in the Crop() function as (4,0,-6,-548). That function starts at x=4 at the left in the image, then removes 6 pixels from the right end. The height starts at pixel x=0 in the image, then removes 548 pixels from the original 576-pixel height. The result after cropping was a rectangle, 710 pixels wide by 28 pixels high. In this case I could just as easily have made the width a full 720 pixels, but I didn't need to repair the black top or side borders.

The repaired 710x28 cropped patch from frame 168:

http://www.digitalfaq.com/forum/atta...1&d=1497454731

The patch was overlaid onto the video in the top right position at x=4, y=0 from which it was taken.

You could also just use ReplaceFramesMC on the whole frame, but you'd have to live with a ton of bizarre motion artifacts especially with the fast moving players. This codde can also replace multiple bad spots in a frame with smaller patches, which I once used to repair some very bad comets that refused to go sway. The code below just uses Crop to "cannibalize" some small but good spot areas from a previous frame and overlay them onto the offending frame in a slightly different position:

I've had videos that used dozens and dozens of these overlay patches. Yes, indeed, one of those caps took a very long time and I really despised that horrible video.

Right, I understand what it's doing. But I'm not sure how it follows that you'll need minimal movement - as you say, you're using patches so you don't have to deal with the issues that come from replacing the whole frame.

...huh?

FixRips + After Effects seems like an easier solution to such cases...

I didn't like the fact that limbs were missing and/or mangled with the running players if I'd used ReplaceFramsMC on the whole frame. A disappearing or badly warped basketball didn't appeal to me any more than it would to you, if there was a cleaner way to do it.

I mean to say that the bottom of the patch was 28 pixels down from the top at both ends.

Not for defects like the one in the upper right corner:

http://www.digitalfaq.com/forum/atta...1&d=1497462659

FixRips is a last resort. There's a lot that it won't fix, and it can destroy objects at random. Besides, there were very few rips in that particular project, barely a handful of small ones fixed with RemoveSpotsMC. It had mostly defects like the one shown (and that was a commercially produced VHS tape!).

Well, I just stumbled across some BetacamSP masters of some of these tapes...unfortunately without the ability to play them, it's not much help.

In large cities in the U.S. there are shops that lease Betamax players (not free). Wouldn't know about your area.

Betamax and Betacam are entirely different things, aren't they? I imagine a consumer Beta player would be gettable on eBay or such, but I'm under the impression Betacam was the professional format. Strikes me as something that would be harder to obtain, not to mention use.

Oops. I meant BetaCam. Old habits, hard to break.

Even if I could obtain one, would it be as simple as plugging it into my current capture device via the same cables, popping the tape in, and pushing play?

I did find a place that might rent them - DigiBeta is the closest thing mentioned though - and had a look on eBay, and there seem to be a few on there that are cheaper than the rental price, oddly.

You should consider the cost of purchase/rental vs having a local post/transfer house convert however many BetaSP tapes you have. From the first page of Google results:

https://www.diskbank.com.au/transfer...cam-transfers/
http://www.procopy.com.au/video-tape-transfer-to-dvd/
http://www.ezdigital.com.au/video-to...mpeg2-mp4.html

Some Betacam players had S-Video outputs; I don't think any DigiBeta did. Otherwise, BNC composite and component. You would need BNC to RCA plugs, if you don't have them already, but they're cheap. My local electronics store charges $1.25 CAD and if you don't mind a long trip on the slow boat, eBay, AliExpress, etc. would be even cheaper.

More importantly, they only use XLR balanced audio, not RCA unbalanced. This is more of a complication.

Once you get it connected, it's just a VCR with some fancy settings and editing operations available. You'd want to ensure the proc amp is reset to defaults and then adjust if desired. Later, you could even try to see whether the TBC works as a passthrough with your other sources (unlikely, but it should be full-frame w/line, so it's possible).

Some DigiBeta players are backwards compatible with Betacam (& its SP upgrade).

I don't even know what BNC is. Some time on Google recommends avoiding S-Video.

I have no idea what any of that means.

EDIT: Created a new thread in the capturing section.

Okay so I've been going through with that ReplaceFrames script, and after 77 replacements it's apparently run out of memory?

Is that just it having to do too many things and I need to start clean? How do I work around it?

That's rather general information, but it sounds as if you're trying to run too many operations in a single script. Two ways around it. Either reduce the number of operations in that script and break it into two scripts to take some load off memory swapping, or stop and reboot to clear some RAM. I reboot a couple of times daily, or more. I've also used ReplaceFrames/FreezeFrame/BadFrames on more than 200 frames in a single script, and that was for just 1 to 5 minutes of video. I'd never try industrial-strength cleanup on an entire capture at one time.

Not sure what other information would help. It throws an error in VDub saying "AviSynth open failure: ReplaceFramesSimple: insufficient memory".

I tried deleting the last replacement, and it still doesn't load, despite that exact script having worked earlier.

I'd think that calls for a look at your script.
Or we could just guess.

Replacements 2-75 omitted because it's exactly the same code as the rest and merely takes up scrolling time and space.

44,400-plus frames? If I had heavy duty detail coding work on that many frames at once, I'd protect my sanity by moving on to a new project. In any case, your posted script snippet ran without a hitch, all the way to frame 44476. I did have to change "Source2" in your script to "Source75" in order to match up with Source75 in the next paragraph. And I had to make a special source file because yours is at least 4 times larger than the segments I usually work with, and mine are broken into even smaller individual shots. I had 47,000 frames and added another paragraph for frame 46,999. It worked.

There would appear to be much more happening in your original script, possibly some typo that's causing problems (and a "typo" could be a comma instead of a period, or that sort of thing). I seem to be a champ around here when it comes to embarrassing typos. There's too much missing here.

Not if it's attached to a post as an .avs file or .txt file, which is what I would suggest.

The whole thing is an hour and five.

Question is whether it's just running too many operations or something.

Well it worked, I added the last replacement, it stopped working, I removed the last replacement, it still wouldn't work.

The whole thing is one shot, so it doesn't really have natural break points or anything.

Thanks. I'll give it a run. First I have to convert my 47000-frame NTSC file to PAL dimensions.

OMG! I haven't worked that many frames at o0ne with heavy detail coding, just simple stuff. Disadvantage with running long files: one error means doing it all over again. Advantage with smaller sequences: catch errors early and don't repeat them with the whole video.

Going over your long script:

A sequence garbled here between 13 $ 14. It probably worked anyway.

The lines below are a waste of code and time:

It's replacing the entire frame (no crop, no patch made) and fills b01, b02 with full frames in memory. You can simplify and do the same thing this way:

I made a test file with 109,460 frames, 720x576 from a noisy VHS capture.

I ran your posted script and changed only the input file. It ran without errors.

I changed your script to eliminate unnecessary coding in the patch routines. It ran without errors on the same test file. I've attached the new script with embedded "####" comments. The code at the end replaces some long patch code with simpler and faster code.

The AssumeFPS() is so I can watch it through in slow-mo to figure out which frames need replacing/patching.

I don't understand what the 'change source #' comments mean/are for.

I figured.

This section of code appears in your original script:

This code starts with Source6 in the top paragraph and creates Source7. The next paragrpah of four lines starts with Source7 and creates Source8. The next paragraph starts with Source8 and creates Source9. Then the next paragrpah starts with Source9 and creates Source10. The last paragraph starts with Source10 and creates Source11.

What do you suppose would happen if the middle three paragraphs were commented-out or deleted, and later replaced by simpler code. After all, those three middle paragraphs don't create a small patch, they just overlay an entire frame. So let's just comment-out those three paragraphs:

AVisynth will ignore the commented paragraphs. Avisynth doesn't know what's in thosse commented lines and doesn't care. So, after the lines are commented-out, Avisynth sees only this:

The ReplaceFramesMC statements in those deleted lines will be replaced later at the end of the script. As you can see, the first paragraph in the above code starts with Source6 and creates Source7. The next paragraph starts with Source10, and....Wait a minute. What is Source10? Avisynth doesn't know what Source10 is because the lines that created Source10 aren't there. So you get an AVisynth error: "I don't know what Source10 is". And it really doesn't know, not at all.

Enter the following comment:
# ########## Change Source # in the above line to match later routine ###########

The comment means that the last line in the earlier code must be changed, and I changed it to skip Source7 and to create Source10, as shown below:

Now in the first paragraph Source7 is skipped, Source10 is created, and the next paragraph starts with Source10 as it did originally, no problem. Meanwhile, you won't need Source7, 8, or 9. The operation that those lines performed on frames 13778, 14388, and 16060 are replaced by one-line statements applied to Source76 at the end of the script, as shown below:

The memory issue does seem to be number-of-replacements related; it always starts hitting at about 90 per file regardless of the length of the clip to that point - I've had breaks of 45 minutes with no issues, or several seconds of replacing every second frame.

So I've had to just cut it up into a different AVS file every time the memory issue started happening too often, which means I've got several of them. Is there an easy way to combine them back into one file, or do I have to manually save them as AVI files and then create another AVS file with all the splices typed out manually?