Hauppauge WinTV-HVR-1975 - Letterboxed 4:3 Capturing Issue

[jagabo]

AVS won't show up as an option. Just add .AVS to the filename before saving. But it needs to be saved as a text document, not an RTF document. I only have "Text Document (.txt)" in that pulldown, whereas you only have .TS:


[Attachment 53185 - Click to enlarge]

Is that not the built in Notepad in Windows 10? The title bar is different on my Win10 computer. Before saving it shows "*Untitled - Notepad".

Are you using AviSynth or AviSynth+? The latter has a shell extension that adds "AviSynth+ Script" to Explorer's menu's New option:


[Attachment 53187 - Click to enlarge]

That's on the Desktop but it works in an Explorer window too.

[jagabo]

This is what I get when attempting to drag and drop the script I made in AVSEdit Plus, or use 'File -> Open Video File' in Virtualdub.

Is your VirtualDub the same bitness as AviSynth? You need 64 bit VirtualDub to use 64 but AviSynth, 32 bit VirtualDub for 32 bit AviSynth. I use VirtualDub2 rather than the older VirtualDub.

[DPage]

Eureka!

Yes, I had the 32 bit ver of AviSynth, uninstalled and now have AviSynth Plus 64 bit ver.


Works great, thank you so much. Here's a comparison of the result in Virtualdub, and the frame as displayed in a media player.


Is there a way to alter the top grey boxes in Virtualdub to black, so that when the blocks appear, the blocks look white and the surrounding areas are black, so they stand out even more?

Also, do you know if the purple blocks need to be as prominent and stark as the example here for this method to be able to detect them? The reason I ask is that I have in the past spotted an instance when there was a single purple block at the top of the picture, but it was not anywhere near as bright as in this example. Would significantly dimmer purple blocks not get detected?

[DPage]

Found a PAL/25 Frames > Minutes and Seconds Converter. This will come in handy.

[DPage]

It works.

I captured a 50 minute programme, left it without monitoring it, came back just before it was due to finish and stopped the capture. Checked the badframes.txt file. It found one bad frame. Checked the video at the point it gave me. Yep, a single purple pixellation at top of picture.

I'll set it going again with the same programme, then check the badframes.txt and see if I can capture without it detecting a problem. This method should save me having to monitor the same material several times.

[DB83]

Jagabo will, no doubt, expand on this.


But I fear you are over-estimating the properties of avisynth and vdub. The former serves frames to the latter. And the latter ENCODES those frames. Whether a script can be so written to not encode those frames that do not require editing I know not but typically all frames are encoded. It's even more subtle than that since not all your frames will be complete ie I-frames and attempting to just encode the frames that require editing could result in even greater problems.

[DPage]

Are you saying that by getting these two programs to provide me with a readout of bad frame(s), the video file gets altered in some way? If so, I will copy and paste the newly-captured video file to my external drive, then check the original video file for any errors. If it is all clear, I just delete this file and I am still left with my pasted copy on another drive, untouched by any software.

[DB83]

No. The two programs just report the instance of the bad frames. But you also asked if the programs can alter the bad frames.


But you appear to suggest that you will capture and recapture until you get no bad frames. It may be more useful to use the programs to see if there is a regular pattern. If their ocurrance is random then you, IMHO, achieve nothing unless you get lucky.

[DPage]

I don't know where in my past comments you thought that I wanted bad frames altered but no, that's not what I want.

I simply wanted an automated means of detecting any instances of purple pixellation in the region of the upper black area of letterboxed material, so I can capture the material without it happening, in a way that does not mean it is necessary to monitor the same material several times.

Up to now, I have rarely needed to capture the same material more than twice or three times before capturing without a pixellation issue.

[DB83]

Reply #33


"Is there a way to alter the top grey boxes in Virtualdub to black, so that when the blocks appear, the blocks look white and the surrounding areas are black, so they stand out even more?"

[DPage]

Let me clarify. Look at this image I've mocked up in Photohop, to give you an idea of what I meant.

It's fine, have a readout of any bad frames in the badframes.txt file, it was just to make the blocks as easy to spot as possible, if scrubbing through in Virtualdub.

[jagabo]

Is there a way to alter the top grey boxes in Virtualdub to black, so that when the blocks appear, the blocks look white and the surrounding areas are black, so they stand out even more?

Also, do you know if the purple blocks need to be as prominent and stark as the example here for this method to be able to detect them? The reason I ask is that I have in the past spotted an instance when there was a single purple block at the top of the picture, but it was not anywhere near as bright as in this example. Would significantly dimmer purple blocks not get detected?

Perfect black borders would have U values of 128. But noise in the video will cause them to vary from that a bit. In the source video you provided the purple blocks had U values from a little below 200 to 255. The "180" in the script I gave set the threshold at 180. Here's a modification where you can set the threshold value and the filename at the top of the script.

It occurred to me that it would be useful to see the actual video along with the bad blocks. So I stacked the bad blocks over the original video. I also adjusted the blocks so the values below the threshold are black, anything over the threshold is white.

global filename = "Analog.ts"
global threshold = 140

LWLibavVideoSource(filename) 
src = last

Crop(0,0,-0,32) # examine only the top 32 scan lines
UtoY() # look only at the U channel (of YUV), V channel has the same problem
WriteFileIf(last, "badframes.txt", "(YPlaneMax(last) > threshold)", "current_frame", append = false)

# adjust the brightness of the blocks and stack them over the original image
ColorYUV(off_y=-threshold).ColorYUV(gain_y=60000)
PointResize(width*2, height*2)
StackVertical(last, src)

So change the filename and set the threshold you want at the top of the script. Then open the script in VirtualDub and run the video analysis pass. Open the badframes.txt file to see the list of bad frames. Back in virtualDub scrub to the frame(s) in question and check them visually. Of course, all this extra processing slows the script down. What used to take about 1 second now takes about 3 seconds.

The threshold of 140 above gave one false positive at frame 1010, along with the true positive at 3802. Raising the threshold to 141 eliminated that false positive. So you'll probably want to set the threshold to something a little higher than 140.

True positive:

[Attachment 53194 - Click to enlarge]

False positive:

[Attachment 53196 - Click to enlarge]

[DPage]

Thanks jagabo.

I just wanted to report that I set a capture going, for a second attempt of a 50 minute programme that, on the first attempt, the badframes.txt reported that there was one bad frame, which I verified and saw was the case. I left this second attempt going, came back and stopped the capture at the end. Checked it and badframes.txt reported no errors.

I've just finished carefully monitoring the capture from start to finish. It was fine all the way through, except, at about a minute from the end, I spotted a single dim purple block that the method 'let through the net'. I will upload a grab of the occurrence tomorrow so you can see what it could not detect.

So, the way I see it, this method you have kindly devised for me is going to be very useful indeed, at detecting the majority of instances of the purple pixellation. As I have just discovered, it is not perfect. I hope to be able to use the new script you have provided in your latest post and tailor the 'global threshold' value, so it can detect dimmer purple blocks than it is currently able to detect. As I say, I will show you the grab tomorrow.

I wonder if you could use a colorpicker tool, or something similar, on the grab containing the dim purple block (when I upload it tomorrow), to ascertain the approximate value I would need for the new script to be able to detect the block it failed to detect with your original script? The video file would be a big problem to upload, it is 49 minutes long and, with a datarate of close to 10 Mbps, the file size will be very large.

[jagabo]

I've just finished carefully monitoring the capture from start to finish. It was fine all the way through, except, at about a minute from the end, I spotted a single dim purple block that the method 'let through the net'.

Did you try lowering the threshold?

[DPage]

I can't now until tomorrow. The PC and all my video gear resides in the top room / loft-conversion. Mother has gone to bed. Would need to go into her room to get upstairs to the top room. So, can't now until the morning.

I don't know where your location is but it's bedtime here in London.

Will continue tomorrow. Thanks for your help!

[DB83]

Even with these, obviously important to you, ways to confirm picture disturbance, I would still explore methods - subtle changes in your workflow to see if they can be eliminated.


1. Ok. You stated you do not wish to use CBR but have you tried it ?. Pretty sure that the USB-Live2 only allows for CBR, and only up to 6500 kbps (more than adequate) and you have no picture issues with that.
2. How about a slight reduction in the bitrate with your preferred VBR?. Going to the max could cause a spike with the encoder having nowhere to go. The avg bitrate goes nowhere near the max but the max could still be hit.


There's another thing that puzzles me about your sample. Letterbox 4:3 usually means, at the very least, a 16:9 active frame. To crop away the bars means removing 72 lines top and 72 lines bottom. However you appear to have no more than 36 lines top and bottom. You stated that the source is VHS. Are these straight captures from a VCR or are you using pass-through or a TBC as well ? Of course a tv broadcast could have 'zoomed' the active image which was not 16:9 in the first place. But are all you letterbox recordings like this ? I ask this since if the disturbance is actually recorded due to the somewhat odd, in my eyes, display, even though it not always appears, it really should be a trial and error to see if it can be eliminated.


BTW What is this 'Haupauge software' ? I have had several cards from the PCI slot days and all came with WinTV software.

[DPage]

Did you try lowering the threshold?

I haven't used your updated script yet, jagabo. I lowered the threshold on your original script down from 180 to 141, and checked that capture which had a dim block near the end and which the threshold of 180 failed to detect. With a threshold of 141, it detected that lone dim block - and no other errors, just how one would wish it to work. Brilliant.

I will set another capture going now, of the same 50 minutes programme, and leave the room. Once it's nearly finished I'll return so I'm ready to stop the capture at the end. I'll then check, using 141 as my theshold and see what results I get.

See the dim block in the attachments. You need to view in a dark room to see it. The bottom pic shows it with the affected area of the screen enlarged, to aid its visibility.

[DPage]

Even with these, obviously important to you, ways to confirm picture disturbance, I would still explore methods - subtle changes in your workflow to see if they can be eliminated.


1. Ok. You stated you do not wish to use CBR but have you tried it ?. Pretty sure that the USB-Live2 only allows for CBR, and only up to 6500 kbps (more than adequate) and you have no picture issues with that.
2. How about a slight reduction in the bitrate with your preferred VBR?. Going to the max could cause a spike with the encoder having nowhere to go. The avg bitrate goes nowhere near the max but the max could still be hit.


There's another thing that puzzles me about your sample. Letterbox 4:3 usually means, at the very least, a 16:9 active frame. To crop away the bars means removing 72 lines top and 72 lines bottom. However you appear to have no more than 36 lines top and bottom. You stated that the source is VHS. Are these straight captures from a VCR or are you using pass-through or a TBC as well ? Of course a tv broadcast could have 'zoomed' the active image which was not 16:9 in the first place. But are all you letterbox recordings like this ? I ask this since if the disturbance is actually recorded due to the somewhat odd, in my eyes, display, even though it not always appears, it really should be a trial and error to see if it can be eliminated.


BTW What is this 'Haupauge software' ? I have had several cards from the PCI slot days and all came with WinTV software.

WinTV is designed for use with Hauppauge capture devices that have on-board TV tuners, though it can also be used with Hauppauge devices that have AV inputs only. Hauppauge Capture is for AV inputs only (S-VHS or Composite).

In this thread, my device I am using is the Hauppauge WinTV-HVR-1975 (not the USB-Live2, you may be getting confused with my other thread).

Both VBR and CBR can be used, and video quality can be set to a maximum of 10 Mbps in Hauppuage Capture.

I have both S-VHS and VHS material in which to transfer. I have a couple of JVC HR-S9600 S-VHS decks and a Panasonic NV-HS1000 S-VHS deck. All decks have on-board line-based TBCs, which I set to On, unless it causes persistent 'frame hops', which it can on a rare occasion with my tapes. I feed the S-Video signal out and into a Datavideo TBC-1000 full frame timebase corrector, then out into the Hauppuage device. The audio is fed directly from the deck in use to the Hauppauge device.

I have checked that the TBC-1000 is not causing the issue by feeding the S-Video signal directly into the Hauppuage device (i.e. the TBC-1000 not used in my set up) and the purple blocks occur just the same.

[DB83]

Ok. But I am not confusing this with the other thread since you mentioned in your OP that you had used the USB-Live with these tapes so it is relevant discussion.


No one forces you to experiment but until you try something you do not know if it will work.

[DPage]

I have transferred at least half of my entire archive of material, that's somewhere in the region of sixty 3 hour tapes. Maybe more. I have used VBR, and set video quality to 10 Mbps from the very outset. I don't really want to go down the route of suddenly using CBR, and dropping the bitrate. I want all the captured video files to be consistent in their tehnical details.

Now, that may appear slightly irrational to some. I do have Obsessive Compulsive Disorder, this could well be playing a part here, I don't know. But I want to keep things consistent. That's not to say I don't appreciate your input. You have given me useful suggestions which I am grateful for.

I'd like to continue to pursue jagabo's method. It is working well for me. Sorry if this causes any resentment. I'm sure it doesn't.

[DB83]

No offence taken. At least you have taken the time and trouble to read and respond. That is not always the case around here.

[DPage]