Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
16th August 2012, 23:14 | #1 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
RAW capture hardware
I just made a quick decoding of a raw capture
http://www.screenshotcomparison.com/comparison/140857 It's from an embedded device with ARM based cpu and 144MS/s ADC. Haven't written color decoding or TBC yet. I could turn this into a sellable custom TBC, but that's way, way off. Last edited by Guest; 17th August 2012 at 00:14. |
17th August 2012, 15:15 | #3 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
That's a great idea, but I'm really wary of other people's money! To be honest, I'm self taught in electronics, math, and video restoration - so all I have to go on is my reputation on a few forums. But I think passion and some demonstrated ability could help. My costs would be mainly in getting parts and building prototypes. I'd want to be certain I can make something that doesn't exist - a TBC that works in the cases that people complain about. That's going to require samples and testing. If I can make a prototype that passes the "LordSmurf" test and he ok'd it, I'm sure it would be a hit, in this obscure little area of the video world
Just to be clear I'm not announcing any product, this is just the evolution of my testing. Right now I'm using a pre-made device which I can customize - most of the pieces are there for me to make a real hardware product, and I'm sure I could design something to my own requirements, cheaply. It could sell for a few hundred. Anyhow, my biggest interest right now is to look at the raw signal in the cases of : horizontal jitter, flagging, and vertical jumping - to understand exactly what's going on, and to correct it somehow. I'd like to make a device that captures independently (for myself), so there's no issues with windows crappy API and dropped frames. You'd be able to monitor it on an in-built screen. I also am looking forward to digitizing raw signal from the video heads, to see if that gives any better quality. I think dropouts and black lines could be improved with that method. Wouldn't it be great to have a capture that comes with a precise mask of all the physical dropout areas? It's clear that no one has ever tried to build a capture device for scripters. Last edited by jmac698; 17th August 2012 at 15:22. |
17th August 2012, 15:47 | #5 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
In fact there's only one picture. My next test would probably show an aligned image. Do you know some better image hosting places? I really like the convenience of not requiring a login, and the comparison ability is really great for my tests.
I did try imagebam but got errors anytime I uploaded, also I was warned that it served adult ads. |
17th August 2012, 18:51 | #7 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
Ok, here's a look at the HSYNC, which has always been my major interest:
http://desmond.imageshack.us/Himg59/scaled.php?server=59&filename=hsyncfromvhs.jpg&res=landing See those sharp, square dips at the bottom? That's what determines the stability of the image. In this case, they look pretty good. My goal would be to find their position with sub-pixel stability, in the best case. In the worst case, it will be missing or really badly shaped, but I need a bad test tape to see an example. Last edited by jmac698; 17th August 2012 at 18:55. |
21st August 2012, 10:00 | #8 | Link |
Registered User
Join Date: Mar 2006
Posts: 1,049
|
my 2 cents - perhaps is better to consider to hook directly to VCR signal with FM modulation and perform ALL data processing after capturing so skip all processing inside VCR - then restoration even seriously damaged recording should be a bit more possible.
|
1st September 2012, 14:21 | #9 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
I was reading the cx2388x datasheet, there is something called vbi mode, which outputs the entire raw line including hsync. The samplerate is huge, 27MHz. It only relies on vsync detection. It should work for 480p as well. It's about 1400 pixels/line. I got the modified driver to run it. Gotta test this later. You can also capture all the lines, at least 490, but probably up to 514 or so (whatever the vsync area is as a gap).
|
10th September 2012, 20:23 | #11 | Link | |
Registered User
Join Date: Dec 2008
Posts: 39
|
Quote:
"the vertical blanking region can be extended by setting the VDELAY register bit to the appropriate value. The VBI line output mode can in effect extend the VBI region to the entire field. Figure 20 shows a block diagram of the VBI section." http://www.ai.mit.edu/projects/VariableViewpointReality/DataSheets/l848a_a.pdf http://hackipedia.org/Hardware/Tv%20Capture/Brooktree/Bt848,Bt848A,Bt849A%20Single-Chip%20Video%20Capture%20for%20PCI.pdf.raw-conversion.utf-8.txt Sure sounds like it. |
|
22nd March 2016, 22:07 | #15 | Link |
Registered User
Join Date: Sep 2005
Location: Vancouver
Posts: 600
|
cxadc and ld-decode
There's been some progress in this area.
LaserDisc Database forum: (WIP) Laserdisc software image decoder from raw signal Gallery: ld-decode in stages happycube's YouTube channel with samples of software-decoded LaserDiscs It uses an updated version of the Linux CX2388x raw ADC drivers for software-defined radio. I installed an ATI TV Wonder Pro PCI card, Linux Mint Cinnamon 64-bit, and happycube's software to attempt 4fsc capture of NTSC composite. You can download a raw capture I made of a DVD pattern here. It's ~1/3 secs long. You can't really view it or do anything with it though, without the Linux software. EDIT: Well, you can sort of view a rolling output: RawSource("7mar.raw",1820,262,"Y8",show=true).AssumeFPS("ntsc_double") Even though a DVD player should be just about the most stable source available, TBC'd DVD images have notable horizontal jitter. I suspect this is a noise issue? Happycube is currently working on a partial TBC rewrite, so he said he can check whether he can improve it after that. (TBC'd, frame 1) (TBC'd + combed, frame 0) VHS, of course, jitters at distracting levels. The decoder also skips some frames of the glitchanalyzer tape I recorded. It's on a garbage tape though. None of the TBCs I own can decode every frame. P.S. @jmac698: I don't suppose you saved those sample images from the first post somewhere did you? The link on Screenshot Comparison is now some random HD movie. Last edited by ChiDragon; 22nd March 2016 at 23:36. Reason: Added note for a way to view the RAW capture |
23rd March 2016, 11:16 | #16 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
I still have that device and can make new screenshots, don't have a dvd player atm though. I'd love to have a proper test sample to analyze though, there's a test pattern I can make to test jitter a lot better, with some alignment signals.
There already was a driver for cx288, it uses vbi mode 2. You can still miss frames because it still relies on finding a vsync signal, so it's not totally raw. The problem with flagging and some dropped frames still can't be solved without fully raw, probably. Last edited by jmac698; 23rd March 2016 at 11:19. |
28th March 2016, 13:47 | #17 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
So, after more research, it turns out that the ultimate conclusion of these ideas has been done. Here is a video of a raw RF signal, directly from the VCR video head, being decoded digitally, completely in software.
https://www.youtube.com/watch?v=t0eLxQY6-RI It's hard to really tell the quality, but to me unfortunately it's not that much more sharper or amazing than a good quality analog VCR. However there are unique advantages to the approach - reduction of noise, dropouts, jitter, and various other disturbances which couldn't be addressed by normal equipment. Finally, here is the same idea I did myself - software decoding of video directly from an oscilloscope (my oscilloscope is a novel sized, handheld, battery powered unit with built-in display, which I can program) https://www.youtube.com/watch?v=a5UQBVi5Xac These are all greyscale because colour decoding takes a lot more work and we're all too lazy to go that extra step Ultimately, this is a problem that's nearly solved, just a matter of a bit of software work in one module (from the most complete software decoder) and the technique should get released opensource eventually. As far as getting the signal, it's either going to come from usb oscilloscopes or modified drivers with capture cards, and the ultimate version would require finding a spot in a VCR to solder the input directly, a simple mod. This can turn a mediocre vcr/laserdisc into the equivalent quality of the best analog examples of their kind, since all the poor electronics is bypassed. |
6th April 2016, 14:20 | #18 | Link | ||
Registered User
Join Date: Sep 2005
Location: Vancouver
Posts: 600
|
From the other thread:
Quote:
Here is the archived version of that guy's webpage, containing some nice breakdowns of the concepts involved here, the source code, and his thesis. http://www.geocities.ws/pmd_iitgw/software_radio.htm I believe the source code for the Raspberry Bi low-FPS realtime NTSC decoder is also available, though I'm not sure it would offer anything useful. Any more links to that VCR-RF capture guy though? Quote:
I'm also curious what would be necessary to digitize and then decode an S-Video signal instead of composite. |
||
10th April 2016, 16:24 | #19 | Link | |
Registered User
Join Date: Sep 2005
Location: Vancouver
Posts: 600
|
Looks like software decoding of NTSC has a long (but sporadic) history. This 2002 PDF was linked in a 2005 archived discuss-gnuradio discussion.
http://www.stanford.edu/class/ee392j...met_report.pdf Quote:
|
|
Thread Tools | Search this Thread |
Display Modes | |
|
|