Yep Yep. Working fine now with the HVR-1950. Couldn't get the 955Q to comply with ALL the installed filters namely the Hauppauge Format converter.
But the 1950 is working out fine so far... Takes a little bit of setting up logistically but once the groove is established it goes pretty fast. Cuts production time in 1/2.
+ Reply to Thread
Results 121 to 150 of 150
So this WAS working as I wrote previous to this but it was the first time out for CCdata capture on the newly rebuilt dedicated win7 machine. I have to say this same phenomenon was showing up on the original machine I was doing s CCdata capture on as well... Now after one day I cannot get EITHER DEVICE TO DISPLAY INTELLIGIBLE CC'S. I do not believe it to be the hardware devices causing these issues because on a virgin install of OS/GraphEd/drivers etc, it was working fine using the same hardware.. Now all I am able to glean is jibberish/garbage CCdata. It's not the source as I have checked that already by turning on the source device hardware decoding and its all OK. It seems to me this is manifest of Graphedit[next] the drivers and filters. I have tried different cables and resetting and rebooting commputer/hpg hardware a number of times at this point to no avail.
Is there a way to reset the filters/drivers/graphedit[next] to be as they were at ground zero BEFORE every capturing any ccdata on a given computer? This setup worked fine on my video capture machine the first time I tried it and then it started decoding CC jibberish just after the first capture session (shutting down machine capture hardware for the day, then firing it up again the next). In the past I was able to blindly remake graphs, reset hardware powering off back on etc and was somehow able to get CCdata to be decoded properly but at this juncture it's basically all screwed.
So if there is a way anyone knows of that will simply reset all of this software junk it just before starting a capture session please let me know. I am currently UNABLE to capture any INTELLIGIBLE cc's with EITHER device (1950 or 955Q) until I can get this issue resolved.
Here's an example...
I was able to get a graph working for the 955Q using the native Dshow color space converter instead of the HPG one. But still unable to get intelligible CCdata to be decoded.
Last edited by thghgv; 15th Feb 2021 at 20:27.
Is the output file from the Dump filter also exibiting this problem?Ignore list: hello_hello, tried, TechLord, Snoopy329
I've been doing somersaults trying to figure this deal out. It's not computer platform specific as this issue follows to a whole different machine - the only similarities being the hauppauge hardware (1950 & 955Q) and the drivers, cabling (which I have already tried swapping, it's not cables), and graphstudio(edit). I have tried older versions of graphedit 32/64bit, the latest ones 32/64bit. I had been uncrating fresh copies of the Graphedit binary (and the associated graphs) each time before starting a capture session (I archived and sequestered working copies and simply pulled a fresh one from the archive) which helped but still dicey operation at best. I even had seen good capture data at the beginning of a session of one piece of content and successfully completed the entire 1 hour capture and stopped to get the next capture of another piece of content going and found good data being capped at the beginning only to come back after around an hour to find it had degraded to crap whilst doing the capture.
There has to be a better way than this.. I have tried messing around with different filter combinations to see if that helped but there are so very few filters that will work with this hardware in the first place it's really not practical. Very curious as well that first runs of these softwares on the platform machines are fine but all other subsequent runs hence are dicey as hell and almost impossible to GET IT TO WORK correctly. Seems like that if it works one day then starts defaulting to crap from then on there should be a way to reset the environ back to a state where the stuff will work. I dunno, just grasping at straws now... But like I said I have been able, between uncrating fresh binaries/graphs, and rebooting the platform machine and the HPG devices, to get some proper content captured but it's very dicey. Yesterday I was messing with the thing all day to no avail at all - most frustrating, and lost a whole days worth of capture time.
These are the graphs I built on the new machine platform (which are virtually identical to the ones built on the original machine) for the two HPG devices. They are simple and to the point nothing real fancy going on - just bringing in composite video/audio from the device crossbar to the device capture filter, splitting the video content on to the renderer and the vertical blanking signal down to the VBIfilter, to the line-21 decoder and finally on to overlay the CC's onto the content display from the renderer. The CC's being displayed is what gets dump.filtered to the binary CC capture file. These DO work and will display CC's over the video. Just that the CC integrity is for the most part, junk ;
For the HVR-1950
and for the HVR-955Q
Has anyone else had this happen before using hauppuage hw and drivers? Curious.
Last edited by thghgv; 16th Feb 2021 at 15:37.
I haven't yet seen the problem you are describing with the DirectShow filter graphs that I built for the HVR-950Q but to be fair, you have probably used your devices a lot more than I have used mine. I don't have any theories that would explain the problem.Ignore list: hello_hello, tried, TechLord, Snoopy329
Ok I believe I have found A solution but it's somewhat around the bend and possibly out of reach of some...
I am fortunate that my test machine has a VERY wide range of support in that I can successfully image OS's on it from WinXP to Win10 and everything in between. In this instance I have built a WinXP x86 image onto it and installed WINTV 6 along with Graphstudio. it was said that WinTV 6 (later versions DO NOT have this capability for composite video) has the capability of recording CCdata inside a captured composite video file for later extraction and it does seem to work. However using the graphs are FAR more efficient and I have been able to simply fire up the computer in the morning and all day long these graphs have been doing pristine CC data captures from composite video, BACK to BACK with out degradation, dropped dialog, missing words, letters, etc. This was unheard of on more recent platforms in my experience here. I have come to the conclusion that the only real difference in the graphs I use under WinXP is the "CC decoder" filter. This is the ONLY real difference graph wise from WinXP to win7 or win10. The "CC decoder" that was dropped from subsequent windows systems after XP was apparently replaced with the "VBI codec" from Vista on up thru win8 and 10... I believe the VBI codec is substandard and unable to hold up to any sort of intensified CCdata collection.
So, to finalize, if you're having issues with CC data integrity while doing multiple captures back to back from composite video, THE solution is WinXP 32, Graphstudio and WinTV 6. I have had NO more issues with re-initializing capture devices or resetting graphs or rebooting host machines. Just fire up and go. Which is the way it should be...
Which version of WinTV 6 did you install? I think there could be more than one version of WinTV 6 because Hauppauge sometimes updates WinTV with bug fixes for a period of time before issuing a major revision.Ignore list: hello_hello, tried, TechLord, Snoopy329
Re: Wintv-6 - I just installed that for the "filters"/drivers. WinTV-6 is clunky and fudgey and not worth my time to mess with for what I need to do.
BUT, just when I thought everything was sorted... Came in to start up captures yesterday, fired everything back up that I was using still connected from just the day before when everything was working, nothing touched or mussed, and now I'm back with garbled CC data.... SO frustrating.
I rebuilt WINXP Pro 32bit on the test machine just to eliminate that as a culprit. Got some decent CCdata for a about 2-3, 1 hour passes and then CCdata went to crap again. I am beginning to think that maybe these USB capture devices are just not up to the task of industrial grade use?
At this point given that the work I have to complete is piling up and these devices are simply NOT working well enough, I should be thinking about getting a good internal PCI bus CAPTURE CARD that I can use with GraphStudio to get myself caught up.
If there is a known good [ PCI ] capture card that will take in a composite video stream (don't care about audio or the video quality at all as this will be used solely for CC capture) that I can use with GRAPHS to record CC data RELIABLY, one capture after next, please chime in with suggestions. Doesn't matter if it's in production or not. I just need suggestions from you all who have been doing this longer than I at this point.
Just to re-iterate
- RE: Requirements for card suggestions;
* the card MUST BE PCI
* it must have a proven track record for being able to record CCdata to a McPoodle RAW binary format using Graphs
* it doesn't have to be in production (quite honestly it probably won't be in production anyway given all my previous requirements)
* it doesn't have to be hauppauge (I am, in fact, quite over messing with hauppauge stuff in general) but if it fits the criteria then so be it...
Thanks in advance!
Have you tried shutting down the software and disconnecting the USB devices when you are not going to use them for a while? Based on your description, the USB devices seem to be working OK up until the time when you stop using them for a while.
You are right. Nearly all of the PCI/PCI-e devices capable of capturing CCs are discontinued. Since it is unusual to capture CCs by themselves, you may not get a definitive answer, but i'll do the best that I can.
Diamond made a few PCI and PCI-e cards that could capture closed captions via composite. I owned all three versions of the TV-Wonder 650 (PCI-e, PCI, and USB) but I captured closed captions as part of the MPEG-2 GOP user data. The USB version, which could only encode video and audio using software running on the PC, could probably capture closed captions in a file by themselves. I'm less sure that the other two, which could use either an onboard encoder chip or software running on the PC to encode video and audio, could also do that.
I never used the TV-Wonder 750 PCI-e or the the TV-Wonder 750 USB. However, they both encode video and audio using software and there is part of a thread where someone used GraphEdit to capture CCs with the USB version. I suspect that the PCI-e version can do the same.
The PCI-e version is available on eBay: https://www.ebay.com/itm/DIAMOND-ATI-TV-Wonder-Tuner-HD750-Card-TVW750PCIE-For-Windows...sAAOSwtvxf48qj
Last edited by usually_quiet; 22nd Feb 2021 at 13:09.Ignore list: hello_hello, tried, TechLord, Snoopy329
Graphstudio - in that GS stores all of its init, settings and capture info inside the windows registry. In fact, in most cases with this USB stuff its the only way I even have half a chance at getting something working. The host machine is shutdown as well as disconnecting Power AND USB from the capture devices. In more cases than not anymore even that is a dicey lot not guaranteed to do much at that instant in time. I will say I have ZERO issues with the HD audio/video portion of all this. The PVR2+ is always spot on and easily worked with via the latest Hauppauge Capture utility.
The HVR-2250's apparently only came in a PCI-E version? At least I am not seeing any offered in a PCI bus format.
There was also made mention in another thread of something called a BT878 Tuner card that was said to have capabilities of capturing CCdata from GRAPHS. PixelView made some and also Kworld... The 878A is a Conexant chipset. Any idea if that decodes CC's in hardware? if the hardware does decode CC's I would think the GRAPH filter for that would have a "CC" output pin on its capture module to run to say a DUMP.FILTER? Just spitballing here I never used one of these things...
Last edited by thghgv; 22nd Feb 2021 at 17:14.
Maybe the AJA KONA LHI ?
[Edit] AV adapter for TV Wonder 650. I think I had to buy it separately.
Last edited by usually_quiet; 23rd Feb 2021 at 00:02. Reason: added picture of adapterIgnore list: hello_hello, tried, TechLord, Snoopy329
[Edit] The most recent Hauppauge TV card with a PCI interface that does software encoding is the Hauppauge 1288 WinTV-HVR-1150 PCI. It is still being sold new although there are no Windows 10 drivers available. Cards that encode video and audio using software are more likely to allow CCs to be recorded by themselves in a separate file.
Last edited by usually_quiet; 23rd Feb 2021 at 12:02.Ignore list: hello_hello, tried, TechLord, Snoopy329
Have you had hands on practical experience with that card/breakout combo, in that it does reliable and accurate capture of closed captions with a GRAPH?
Last edited by thghgv; 23rd Feb 2021 at 15:20.
The 600's were JUST CAPTURE cards right not Hybrid capture+system video? I believe that has a (top down) RF Tuner IN, S/Video IN, Composite Video in (rca), Audio IN (1/8" phone jack) correct?
Here's a TV Wonder 650 PCI that appears to come WITH the breakout box (tiny wording on the end flap of box) >> https://ebay.to/3sohEiK
That look familiar? This could capture to a RAW bin file with a GRAPH?
When you did those captures (you did them with a 600 PCI or 650 PCI?) how many times did you run captures back to back and how accurate was the resultant data? Were you able to fire it up day after day and get the same results, assuming that it was accurate data you were getting that is... Quite frankly at this point if I can get separated data quickly and easily and most importantly RELIABLY and ACCURATELY it really doesn't matter what I use.
The issue here is I cannot seem to depend on these USB devices (most of which it seems are doing "software based" decoding of captions?) from one minute to the next. When on the lark that I do happen to get a good and accurate capture of a 1 - 2 hour piece of content the next capture(s) subsequent are garbage or semi-garbage... When you have data that is missing letters of words throughout, missing words throughout, and at times even whole pieces of dialog just gone, it makes the work that SHOULD be a simple 5 minute realign of captions to edited breaks, into a 30 to 45 minute clusterf**k of wasted time and frustration.
Just for my sanity I have checked on the SOURCE material more than once just to see for myself if perhaps the garbagey data I am seeing output from these devices was actually there to begin with. So I connect the vid out on the SAT to a TV with hardware CC decoding turned on and EVERYTHING is shiny clean. So the issues I am having with garbled CCdata is DEFINITELY a product of these devices/drivers.
I have always been of the opinion that onboard processing in hardware usually yielded the best result of what ever it is being done. Of course it wholly depends on how well that onboard processing is coded and constructed. But that doesn't seem to be the case with CC data capture? Or is it just that the onboard decoding makes it harder to dump the binary data to a capture file perhaps?
P.S. - What's the story on those Hauppauge 1288 WinTV-HVR-1150 PCI cards? What do we know about them? Have they been used successfully to grab CCdata ACCURATELY and RELIABLY over a long haul?
Last edited by thghgv; 23rd Feb 2021 at 18:18.
My ATI All-In-Wonder Radeon 8500DV definitely can capture captions from any analog signal. I used to do it all the time. Unfortunately, it is in an old (2005) computer which needs to be re-capped before it will function again, so I can't use it at the moment.
Also, someone just gave me a high-end capture card, the AJA Kona LHe card that jagabo mentioned. Unlike the ATI card, which is PCI, this is PCIe. This Kona card is supposed to support closed caption capture, but I haven't yet installed it, so I cannot verify this.
Although this card cost close to $1,000 when new, you can get them for only $25 on eBay. My old ATI Radeon 8500DV goes for about the same.
Pretty much ALL the 8500DV radeons I saw offered were AGP. But you did say there was a PCI version of that card? With the 8500DV were you able to capture CC data ACCURATELY and RELIABLY, capture after capture, using a GRAPH to dump the data to a RAW format binary file? Also the 8500DV card seems to be a hybrid capture + system video card from the looks of it? Just wondering how it would work and play with the system video card that is already installed.
Anyone familiar with these cards? https://ebay.to/37GAqtC
That is a PCI bus based Conexant BT-878 chipset card from Kworld. Anyone have first hand knowledge about how they operate using GRAPHS to record CCdata?
Are they reliable and accurate? Do they decode closed captions ONBOARD or via software running on the host machine?
My 8500DV is indeed an AGP card. It is in an ancient Polywell computer using an ASUS P4B-LX motherboard. The 8500DV manual makes it sound like there might be a PCI version, but a little searching reveals that it is only AGP.
My motherboard does not have a built-in video card, but most of my other computers do have built-in video. I always disable the on-board video and instead use a "real" video card in order to get the GPU and other performance advantages. With your computer, I expect you can disable the video and use the video in this instead.
As for your specific workflow of setting up a GRAPH, that is not how the software I used was set up. Also, I have no idea what a "RAW format binary file" might be. I always wanted to capture text along with the timing, and the 8500DV worked perfectly for that, letting me directly put the information into SRT or other normal subtitle format. I don't remember any problem with massive errors (i.e., unreadable text).
The McPoodle RAW format .BIN files are just the raw data being collected from the driver filters from a GRAPH, being shoved into a disk file for later parsing with CCextractor. The resultant parsed .SRT file looks like any other subtitle file below;
00:58:31,775 --> 00:58:33,675
as much as we do.
00:58:33,677 --> 00:58:35,511
I'm just worried that --
00:58:35,513 --> 00:58:37,446
you know how she is.
She breaks out.
For me getting the data put to a single file that only has to be parsed once and then is able to be used is the easiest workflow I could ask for... Just that the data MUST BE ACCURATE.
The osprey cards do this natively. And although I havent done any CC work. That stream is always there. They work for me as I need analog video adjustment before digital.
They sure as heck aren't cheap, but they're available used on the SD side quite often. I've got the quad card, but wished I bought the breakout panel system way back then.
The two internal TV Wonder 600 cards (which I never owned) use totally different hardware than the USB version of the TV Wonder 600 so my experience with the USB version isn't applicable to the two internal versions of the TV wonder 600.
Using the TV Wonder 600 USB, I could build a graph to capture CCs in the MPEG2 video GOP user data but I never tried capturing CC's alone. I still have a TV Wonder 600 USB but I don't know if it still works. It may be fried due to inserting it into a bad USB port. I haven't had the courage to try it again since then.
DScaler or Virtualdub. Both TV Wonder 650 cards died long ago.
My track record with questions isn't great, but here goes. Are you setting up the graph to use the clock? Using the clock synchronizes the filters in the graph. Otherwise, they all run on their own schedule.
I have seen mention of those cards from other members but as I recall they are using them with Linux.
Last edited by usually_quiet; 23rd Feb 2021 at 22:04.Ignore list: hello_hello, tried, TechLord, Snoopy329
So get this.. I found a ISO image of HPG WinTV 7. Installed it on the XP box and was getting PERFECT captures from the 955Q for about 4 days IN A ROW. Then today I come in, fired everything back up, got all ready to start another "perfect session" of CCdata captures, and did a caption check before I actually started to roll.
The Caption check was a total fail. Today. For 4 straight days previous it was pristine, TODAY... Total crap... No idea...
It just so happens that the ATI TV Wonder 650 PCI arrived today as well. So, I boxed up all the HPG gizmos and threw in the ATI card. rebooted. Built a quick graph for it to capture CC's to a raw file thus;
...and we're off to the races once again... The ATI TV Wonder 650 is capturing CCdata just fine - just as fine as the retarded 955Q WAS doing for like 4 days previous before it just plain stopped grabbing intelligible captures, YET AGAIN.... I will admit that the PCI card is a MUCH cleaner looking setup than the USB. I'm not even bothering to connect audio up anymore for captures since It's not needed anyway. Just once RCA cable to connect video's ant that's it.
Sooooo.... Now we'll see how long it takes the ATI 650 PCI card to totally crap itself...
Last edited by thghgv; 1st Mar 2021 at 19:38.
I don't know about the PCI/e versions but the ATI TV Wonder USB HD 650 has an AGC function that can't be turned off.
When switching from a dark shot to a bright shot the picture is initially over-bright, then darkens to normal over the next several frames. When switching from a bright shot to a dark shot the picture is initially over-dark, then brightens to normal of the next several frames. It's especially unfortunate as the device is very good in every other measure.
Some sample images I posted a while back:
Last edited by jagabo; 1st Mar 2021 at 21:07.
i able to get closed captions from
hvr 1600 , hvr 2250, 950q, usb wonder 600, i dont sure but also from one avermedia usbs.
like 4 years ago i play it with them. and all with graphedith.
all runs fine. i stop to record tv so i leave it.
when i was recording tv i did from a colossus but being unable to get closed captions from colossus , i try this route. im not full sure but i build one graphic where i capture colossus video and closed captions too.
idk if its you talking about but just sharing info.
Ignore list: hello_hello, tried, TechLord, Snoopy329
Premiere pro and DaVinci Resolve and checked parameters on the waveform monitors & vector scopes there. The output from the DISH Sat PVR device is actually not bad at all...