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?
+ Reply to Thread
Results 1 to 30 of 52
Last edited by DPage; 5th May 2020 at 12:39.
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.
I'll see about uploading an example tomorrow.
Last edited by DPage; 5th May 2020 at 14:43.
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.
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.
Last edited by DPage; 6th May 2020 at 16:26.
This one's a howler
I trust you are not attempting to capture at the size of these caps.
No, capturing to 720x576i, as per source.
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.
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.
Last edited by DPage; 7th May 2020 at 08:40.
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.
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.
Last edited by DPage; 7th May 2020 at 09:27.
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 ?
Last edited by DPage; 7th May 2020 at 10:24.
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?
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.
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..
Be sure the device isn't overheating. Don't set it on top of a hot cable box or other device.
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.
ffmpeg -v error -i %1 -an -c:v rawvideo -f null - pause
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
Press any key to continue . . .
ffmpeg -i analog.ts -c copy -t 2:32 output.ts
ffmpeg -i analog.ts -c copy -t 2:33 output.ts
So I don't think ffmpeg will work for you.
OK, thanks so much for taking the time to reply so thoroughly. It's very much appreciated.
Just a suggestion.
Rather than capturing with a variable bitrate, what happens (assuming the software allows) if you capture at a constant bitrate ?
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)
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
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?
Last edited by DPage; 8th May 2020 at 06:24.
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.
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.
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.
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)