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

[DPage]

Just over a year ago, I purchased the Hauppauge WinTV-HVR-1975, for capturing from S-VHS and VHS tapes to the PC in MPEG2. It has a hardware MPEG2 encoder and it has proved very good. I have been happy with the results.

I have used it with Hauppauge Capture, not the WinTV software (which I hate). Although Hauppauge Capture does not *officially* support the WinTV-HVR-1975, it works fine and I can set the video quality up to a maximum of 10Mbps.

However, I have discovered that if I try to capture letterboxed 4:3 material (such as 14:9 or 16:9 letterboxed 4:3 etc), I get an occasional instance of purple pixellation at the top of the screen, it's always located somewhere within the black area at the top. Full 4:3 material is fine, only letterboxed 4:3 content does the 1975 have a problem with. I verified that it is exactly the same when using the WinTV software (i.e. its offically-supported software). Hauppauge support UK said they think my 1975 is faulty. So, I tried to hunt down another 1975, as it had recently been discontinued, I found one remaining unit available on Haupauge's Germany site and purchased it immediately, just a few weeks ago. Low and behold, it is exactly the same! So, I sent it straight back for a refund.

So, the WinTV-HVR-1975 seems to have an inherent problem with letterboxed 4:3 content. The purple pixellation occurs far too frequently to tolerate.

I very recently purchased the Hauppauge USB-Live2 and am using it for transferring my letterboxed 4:3 content - it has no such pixellation problem. I continue to use the WinTV-HVR-1975 for transferring 4:3 'unletterboxed' content, as the USB-Live2's audio displays a slight whistling in the background, whereas the 1975 is nice and silent.

In an ideal world, I'd love to be able to sort out the WinTV-HVR-1975 purple pixellation issue and use it for all my transferring.

Any thoughts, guys?

[DB83]

The standard procedure is to upload a short sample, original, video that shows the issue.


Dare I add though that if the disturbance is in the non-active part of the screen it can be easily masked or fully cropped to leave a 16:9 image. It would involve a re-encode of your capture which, I guess, you are reluctant to do since there will be a loss of quality. But if mpeg2 is not your final format (and 10mbps is too high for dvd) then a re-encode is always an option.

[DPage]

I'll see about uploading an example tomorrow.

[DB83]

Fairy nuff.


BTW There is no need to do a brand new capture. If you have an existing one with the issue feed that in to avidemux, use A/B markers to select and 'copy' for video/audio streams and save as mpeg-ps

[manono]

Yeah, I don't really see the problem as it's a simple matter to cover the letterboxing with fresh black, or to remove the letterboxing entirely. I'm fairly certain a reencode is intended anyway.

[DPage]

I thought I may have got to the bottom of it, after setting the record path to my internal D drive instead of my external drive. It behaved itself for two and a half hours, until, alas, another instance of the purple pixellation at top of black area (see screenshot).

I've tried to upload the video file but it is proving difficult for some reason. Will try again tomorrow. In the meantime, please see the screenshot.

[DPage]

This one's a howler

[DB83]

I trust you are not attempting to capture at the size of these caps.

[DPage]

No, capturing to 720x576i, as per source.

[DB83]

Remember that the upload MUST complete (attachment) before you finish the reply.


Still have problems then just use a storage site. If you have a Google Account then you also have Google Drive and that will work.

[DPage]

Please see this attached video capture, at 6m56s in, for an example of the purple pixellation at the upper area of the screen.

edit: apologies, that should be 2m 32s in.

[DB83]

I must assume that the 6m56s is a typo


on my playback this clip is only 2+ mins and no disturbance. If you see it then it is your system that is at issue and not the capture.

[DPage]

Apologies for the mistake re the point at which it happens. I have so many files without proper names, I got a little muddled.

The pixellation is at 2m 32s. Please look again here. The attached screenshot is what you should see, at this point in the capture. You really cannot miss it.

"...If you see it then it is your system that is at issue and not the capture."

You you saying you have played it right through, and have not spotted this glaring pixellation problem at 2m 32s ? I have played it in both VLC media player and Potplayer, and both players display the issue, exactly the same as per how Hauppauge Capture displayed it while the capture was in progress.

[jagabo]

ffmpeg reports an error in the MPEG 2 stream around that point.

[DPage]

Thanks. Does this help to solve the mystery as to why it's doing it?

I am regularly defragging the D drive (the drive I have set to write my captures to). Would it help to see if I can find a third-party defragmenter that will do a deeper defrag than the standard disk optimizer in Windows 10 ?

[jagabo]

Is your D drive internal or external USB? If USB capture to an internal drive instead.

But if this problem only happens with letterboxed sources (especially since it's only happening at the top of the frame) the problem may be internal to the HVR-1975. Have you tried going back to non-letterboxed source to verify the device is working otherwise?

[DPage]

My D drive is internal.

Non-letterboxed material is and always has been free from this issue.

I was told by Hauppauge Support UK that, as this issue was occurring when capturing non-letterboxed material in both WinTVv.10 and Hauppauge Capture, they felt that it was likely to be a faulty unit. I purchased it too long ago to get a free repair. This model has just very recently become discontinued, I spotted it still available on Hauppauge Germany's webstore, I purchased it. It behaved exactly the same, so I returned it for a full refund.

[DB83]

To be frank and honest, without being told at the precise point where this happens I did not notice it.


Of course when someone knows an issue exists one looks for it rather than focus on the live video.


If it were to happen consistently, one's subconscience takes over and focuses on the potential error - the negative - rather than the positive..

[jagabo]

Be sure the device isn't overheating. Don't set it on top of a hot cable box or other device.

[DPage]

In the absense of getting to the bottom of the cause of the issue, I think I have thought of a way of minimising the extra hassle from now on, while continuing to use the device for letterboxed material, but I need some help please.

jagabo mentioned he used ffmpeg to check for errors and it alerted him to an error at around the point in the capture where the pixellation occurs.

This is what I propose to do. I set a capture going, I leave the PC to get on with it, without monitoring at all, then come back to the PC just before the material is due to finish, I stop the capture at the end, then immediately open ffmpeg to check for errors in the video file that was just created. If ffmpeg detects errors, I go to the point(s) in the video file where it says there are errors and do a visual check of the material at that point. If the pixellation is there, I delete the file and recapture the material once again and repeat the process. If ffmpeg seems to indicate the video file is free of these errors, then I monitor the video file right through from start to finish and verify all is ok. This way, I don't need to monitor the same material again and again, diminishing my sanity in the process.

Can somebody please show me how I go about using ffmpeg to check for errors with a completed video file.

I have just installed ffmpeg, and I used a youtube tutorial to get it to work, via command prompt.

[jagabo]

Can somebody please show me how I go about using ffmpeg to check for errors with a completed video file.

It looks like ffmpeg isn't detecting an error at the glitch, but somewhere after it. To detect errors I used this command line in a batch file:

ffmpeg -v error -i %1 -an -c:v rawvideo -f null -
pause

That generated the output:

D:\test>ffmpeg -v error -i D:\test\Analog.ts -an -c:v rawvideo -f null -
[mpeg2video @ 00000135c7e100c0] invalid cbp -1 at 17 21
[mpeg2video @ 00000135c7e100c0] Warning MVs not available

D:\test>pause
Press any key to continue . . .

I then remuxed the first 2:32 seconds to a new file with:

ffmpeg -i analog.ts -c copy -t 2:32 output.ts

That new clip didn't show the error with ffmpeg or when viewing. So I thought the error report of the original video coincided with the visual error. But if I remux a slightly longer segment:

ffmpeg -i analog.ts -c copy -t 2:33 output.ts

The glitch can be seen near the end of the video, but ffmpeg doesn't detect it.

So I don't think ffmpeg will work for you.

[DPage]

OK, thanks so much for taking the time to reply so thoroughly. It's very much appreciated.

[DB83]

Just a suggestion.


Rather than capturing with a variable bitrate, what happens (assuming the software allows) if you capture at a constant bitrate ?

[jagabo]

I worked out a way to detect the purple blocks with AviSynth.

LWLibavVideoSource("Analog.ts") 
Crop(0,0,-0,32) # just the first 32 scan lines
UtoY() # look only at the U channel (of YUV), V channel has the same problem
WriteFileIf(last, "badframes.txt", "(YPlaneMax(last) > 180)", "current_frame", append = false)

That script will output a text file called badframes.txt with a list of frame numbers that have the purple blocks. (If the video is not letterboxed, or if there is other noise at the top of the frame, it may generate false positives). With your sample file it generates just:

3802

If you want the time instead of frame number change "current_frame" to ""current_frame/framerate". That will give you the time in seconds. I don't know a way to change that to HH:MM:SS format within the script.

To generate badframes.txt you have to open the script in an editor and run through every frame of the video. I recommend you use VirtualDub. Open the AviSynth script as if it was a video (the image will just be a narrow grey horizontal box) then select File -> Run Video Analysis Pass. VirtualDub will quickly read through the entire video. On my computer the 2.5 minute sample clip took less than 1 second to process. If you do this with a player

[DPage]

Thank you so much, jagabo. Excuse me, DB83, the method jagabo has come up with is something I really want to go with at this point in time. Sounds intriguing and could offer a real breakthrough.

jagabo, I really want to be able to use your method, but, although I am very competent with computing in general, this area is out of my depth and is a learning curve for me.


Can you go through each step of the procedure you have come up with, set out in a way that is as easy-to-understand as you can please? I know I am a pain but to be able to go about the method in your last post assumes a certain level of knowledge in this area of computing, and I am not at that stage quite yet.

I have AviSynth and Virtualdub installed. What do I do next, can you explain so I can clearly understand?

[jagabo]

Since you have AviSynth and VirtualDub alreardy you probably only have to install the LSMASH filter package for AviSynth (LWlibavVideoSource() is part of LSMASH). Download the package and put a copy of LSMASHSource.dll in AviSynth's plugins folder. Be sure to use the right one. 32 bit LSMASHSource.dll for 32 bit AviSynth, 64 bit LSMASHSource.dll for 6 bit AviSynth. This gives AviSynth the ability to open .TS files.

http://avisynth.nl/index.php/LSMASHSource

Then create a script like the one in post #24 with Notepad or any other plain text editor (copy/paste from the post). Change the name of the video in the first line. If the script is in the same folder as the file you're checking you only need the file name. If the script is in a different folder you should use the full path name. When you save the file be sure to set the extension to .AVS, not .TXT.

Open the script in VirtualDub, either by drag and dropping the script onto VirtualDub or by using File -> Open Video File... in VirtualDub. If everything is working you should see a thin wide grey box in the preview windows. This is the U data from the top 32 lines of the video. If you scrub though the video you'll the box artifacts (they'll be gray, not purple) when you hit a frame with them.

Select File -> Run Video Analysis Pass in VirtualDub.

When it's done there will be a file called badframes.txt in the same folder as the AviSynth script. You can open that file with Notepad or any plain text editor.

[DB83]

NP


jagabo, who's contributions here I profoundly respect, indicates a solution to highlight errors in the capture.


I am attempting to suggest a workflow where such errors may not even happen.


For me there is no obvious difference between 16:9 in a 4:3 frame to 4:3 in a 4:3 frame. If errors occur in the former they should occur in the latter. If they do not then the cause may not be due to the device but the source.

[DPage]

Thanks, DB83. Yes, Hauppuage Capture allows CBR but I'd rather use VBR so I'd like to try jagabo's method for the moment.

Jagabo, thanks for the clarification/extra info.

I've followed your steps, I am up to the point where I save your script in Notepad, ensuring I save the extension to AVS.

I have no such option. It offers me rtf extension only (RichText)

[DPage]

Installed AVSEdit Plus, which I understand allows the AVS extension.

[DPage]

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.