RAW capture hardware

[jmac698]

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.

[JK1974]

Great to see this progress. And if the hardware would no be too expensive, I would be really interested - maybe something for a Kickstarter project? ;)

[jmac698]

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.

[Guest]

Mouseover is not working for me. Why not post both screenshots separately so everyone can see it?

[jmac698]

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.

[SassBot]

You can use imageshack without a login.

[jmac698]

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.

[pandy]

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.

[jmac698]

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).

[Perepandel]

I was reading the cx2388x datasheet, there is something called vbi mode, which outputs the entire raw line including hsync

I'm talking from memory but this mode was also available in bt8x8.

[Filker]

I'm talking from memory but this mode was also available in bt8x8.

"The Bt848 is able to capture VBI data and store it in the host memory for later processing by the Bt848 VBI decoder software. Two modes of VBI capture exist: VBI line output mode and VBI frame output mode2"

"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.

[JK1974]

Anything new on this or any progress on any other solution to get (better) software TBC functionality?

[jmac698]

It's an exciting project, but I've been dealing with other areas of life for a few months. Asking is good though; it reminds me.

[jmac698]

Btw, anyone see perepandel? I bought a cap card from him, and sent a final payment, but never heard back from him.

[ChiDragon]

There's been some progress in this area. :D

LaserDisc Database forum: (WIP) Laserdisc software image decoder from raw signal (http://forum.lddb.com/viewtopic.php?f=32&t=2671)
Gallery: ld-decode in stages (http://imgur.com/a/7VNff)
happycube's YouTube channel with samples of software-decoded LaserDiscs (https://www.youtube.com/channel/UC4RanzdImbW8yxvpkTKnayg)

It uses an updated version of the Linux CX2388x raw ADC drivers for software-defined radio (http://forum.doom9.org/showthread.php?t=162832&highlight=raw+video+capture).

I installed an ATI TV Wonder Pro PCI card, Linux Mint Cinnamon 64-bit, and happycube's software to attempt 4fsc (http://www.pcmag.com/encyclopedia/term/55773/4fsc) capture of NTSC composite.

http://s14.postimg.org/6lq0n05s1/dvd_output2_dd.png

http://s14.postimg.org/opt17n3gh/dvd_output2.png

You can download a raw capture I made of a DVD pattern here (https://drive.google.com/file/d/0B123gnOHhKFwVFppSHowVlRnMG8/view). 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.

http://s11.postimg.org/dm5j44mcj/pxcrop_tbc_1.png (TBC'd, frame 1)
http://s11.postimg.org/qaztnssgz/pxcrop_O_n0_N0_B_v_W.png (TBC'd + combed, frame 0)

VHS, of course, jitters at distracting levels.

The decoder also skips some frames of the glitchanalyzer (http://forum.doom9.org/showpost.php?p=1462931&postcount=81) tape I recorded. It's on a garbage tape though. None of the TBCs I own can decode every frame.

http://s30.postimg.org/y5p50ude9/21mar_tbc_164.png
http://s30.postimg.org/owmyqq4i9/21mar_tbc_165.png

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.

[jmac698]

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.

[jmac698]

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.

[ChiDragon]

From the other thread:
And here is a perfectly software TBCd VHS video:
https://www.youtube.com/watch?v=CPG2THCxODg
you can see that it's perfectly stable, as would be expected.
Isn't this an NTSC broadcast capture, not VHS?

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?

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.
I'm sort of surprised that you thought there would be more to it. In the article (http://forum.lddb.com/viewtopic.php?p=53370#p53370) about the Betacam "Full RF" capture method, I don't think they ever mention increasing the definition that could be captured.

I'm also curious what would be necessary to digitize and then decode an S-Video signal instead of composite.

[ChiDragon]

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/Winter2002/projects/zimet_report.pdf

http://s22.postimg.org/rbctiyddd/NTSC_decode_Stanford_block.png

The first 2 stages of preparing the analog signal and converting it to digital are done by hardware and will be discussed in section 2. The samples out of the ADC are digital quantized form of the 1D signal. To extract the valid video data, in stage 3, the timing information is used and the data is organized in a field matrices. Each raw in the matrix represents the active video of one horizontal line. This stage is discussed in section 3. For easier processing of the chrominance and luminance separation, the data is resampled to four times the sub-carrier frequency. Y/C separation is the most challenging part of composite video processing. In section 5 we discuss the different methods for implementing Y/C separation. In the next stage the color information is being demodulated from the sub-carrier as discussed in section 7. To display the information on a progressive display such as a PC monitor, interlace to progressive conversion as well as YUV to RGB conversions are performed. These two stages are discussed in sections 8 and 9.