OSSC (DIY video digitizer & scandoubler)

[marqs]

UPDATE 06/2016: The thread covers development phases of a DIY video digitizer/scanconverter project that eventually became Open Source Scan Converter (OSSC). General discussion about OSSC still continues here, but support and more specific questions should move to OSSC-specific section on Videogameperfection.com forums. Basic information about the device and how to get one can be found on JunkerHQ wiki.

Hi!

Since the spring, I've used some of my spare time to design a gamer-friendly video digitizer & scandoubler -system. One may wonder why, as there some pretty good commercial ones available which are more or less suitable for retro gaming. I'm mostly doing this for fun and to see how good results it's possible to pull out with a DIY system.

Anyway, the main parts of the system are video digitizer IC, FPGA and HDMI transmitter IC. My first prototype is a PCB with input video connectors and the video digitizer IC. The PCB (shown below) is connected to a FPGA development board, which contains logic for video processing and scandoubling, and a HDMI transmitter daughter card for video output. The next step would be to integrate the FPGA and HDMI TX chips to the same PCB, which would make it a standalone system.





The features of the current system include:

• -digitizes&scandoubles 240p/480i to 480p, 288p/576i to 576p, and digitizes 480p and higher
  -very low latency (less than 2 scanlines)
  -single-field "deinterlace" for interlaced modes - a fast method which looks okay
  -quick 240p<->480i switching
  -multiple inputs supporting various formats
  • -RGBS via SCART connector
    -RGBHV/RGBS via VGA connector
    -YPbPr/RGsB via 3xRCA connector
  -all video processing done in RGB domain - no conversion to YCbCr at any stage
  -full-range RGB output through HDMI
  -optional scanlines
  -configurable horizontal sample rate (only limited by display support)

I've tested this with some 8 different consoles, of which only one does not sync properly. There are still tons of stuff to do, but it's looking quite good already. Of course the end result depends how well the display scales 480p etc. to its native resolution, but at least in my setup this gives better results than connecting consoles directly to TV's analog inputs. After the standalone system is finished, I'll probably release all the source code and schematics so that anyone with right skills can build one and improve the design.

Below is a link to a video which shows the system in action. I used Chrono Cross as test game, as it contains lots of 240p<->480i switching and uses "field 1"-signaling with 240p (confuses many video processors):

Testing with PSX

[Xyga]

Very nice !
- by 'very low latency (less than 2 scanlines)' you mean frames or milliseconds, or ?
- do fake scanlines work on the HDMI output ?
- any planned overscan/zoom function ?

[blizzz]

Very interesting project. Keep us updated!

[Ed Oscuro]

- by 'very low latency (less than 2 scanlines)' you mean frames or milliseconds, or ?

2/240 (ish) of 16ms, wouldn't you think?

My question is - does that latency apply to HDMI output? Unfortunately I think the output will still have to be scaled by the receiving device.

[BuckoA51]

Nice work! Could be a great replacement for anyone still using the old XRGB scalers.

[Fudoh]

How exactly do you handle the horizontal resolution ? Which sampling do you apply during the A/D stage ? What about pixels wider than 1:1 square ratio (e.g. SNES with 256x224) or narrower than 1:1 ratio (e.g. CPS2 with 384x224).

If you're aiming for integer doubling on the horizontal as well, you might want to look into higher output resolutions like 720p or 1080p as well.

[marqs]

Very nice !
- by 'very low latency (less than 2 scanlines)' you mean frames or milliseconds, or ?
- do fake scanlines work on the HDMI output ?
- any planned overscan/zoom function ?

-2 scanlines @ 240p/60Hz equal around 0.13ms. With higher resolutions/refresh rates, the delay is naturally reduced.

-Fake scanlines work on the HDMI output. Basically every other row is just darkened out.

-It's not possible to freely zoom/scale the video on this hardware, but I can think of 2 ways how overscan could be implemented:
1. Overscan information can be included to AVI Infoframe, which is sent to the display along with HDMI data. Displays should perform overscan based on this, but I'm afraid most just ignore the information.
2. The active area of the video can be reduced, for example from 720x480 to 680x450. However, I'm not sure how many displays would accept a resolution like that, and scale it to full size without letterboxing.

[marqs]

My question is - does that latency apply to HDMI output? Unfortunately I think the output will still have to be scaled by the receiving device.

The latency number is the delay of the HDMI output versus analog input. I couldn't find the exact amount of delay from HDMI TX IC specs, but it shouldn't be much more than the video digitizer delay (18 pixel clock cycles). The display naturally needs to scale the output, but in many cases that doesn't add any delay compared to native resolution input.

[marqs]

How exactly do you handle the horizontal resolution ? Which sampling do you apply during the A/D stage ? What about pixels wider than 1:1 square ratio (e.g. SNES with 256x224) or narrower than 1:1 ratio (e.g. CPS2 with 384x224).

If you're aiming for integer doubling on the horizontal as well, you might want to look into higher output resolutions like 720p or 1080p as well.

The video digitizer IC (TVP7002) contains a PLL which uses HSYNC as its reference input. With a freely selectable divider ratio, a custom sampling rate can be chosen. Ideally, the horizontal sampling rate should be matched to each console's output, e.g. 256x224 of SNES should use value of 341 which includes horizontal blanking (based on this). With active area set to 256x448 (scandoubled output), displays *should* scale it correctly to target aspect ratio. In reality, that's not always going to work. The horizontal total of 341 pixels (or 682 if horizontal is doubled) is far from the values used in standard CEA video modes such as 640x480 (800) and 720x480 (858), and several displays are not going to like it.

So in practice, the sampling rate selection is limited by the display. However, I noticed there's a pixel repetion feature in HDMI when I was browsing through the specs. That would allow using a number of pre-defined sampling rates which would be closer to the outputs of some older consoles. I have to try it at some point and see how it works out.

[Crafty+Mech]

Excited to see someone else working on this bit of tech!

Especially since my own 240p line doubler project has been sidelined for various life reasons for over a year.

I'm guessing you implemented the line buffer as a FIFO in the FPGA?

The PLL component of this kind of project is challenging, made much easier by using an IC that already implements a flexible, robust PLL solution. I'll have to check out the data sheet on the TVP7002, I have in the past used Intersil chips for that purpose but had some issues with phase locking for some video sources.

I'll be following this thread for sure!

[marqs]

Excited to see someone else working on this bit of tech!

Especially since my own 240p line doubler project has been sidelined for various life reasons for over a year.

That's a pity to hear. How far did you get with your project?

I'm guessing you implemented the line buffer as a FIFO in the FPGA?

Actually, I'm using dual-port ram macros for that. Read is done using double the clock frequency of write, so that a line is read twice simultaneously as next input line is written to a buffer.

The PLL component of this kind of project is challenging, made much easier by using an IC that already implements a flexible, robust PLL solution. I'll have to check out the data sheet on the TVP7002, I have in the past used Intersil chips for that purpose but had some issues with phase locking for some video sources.

Yes, it's much easier to use a complete digitizer IC than separate ADCs and PLL. I'm mostly satisfied with TVP7002 - it's cheap, has 3 analog inputs and is documented well. I checked some alternatives from Analog Devices such as AD9984A and ADV7441A (is this inside XRGB Mini btw?), but the former has only 2 inputs and latter is expensive and I couldn't find proper register descriptions for it.

[Ed Oscuro]

My question is - does that latency apply to HDMI output? Unfortunately I think the output will still have to be scaled by the receiving device.

The latency number is the delay of the HDMI output versus analog input. I couldn't find the exact amount of delay from HDMI TX IC specs, but it shouldn't be much more than the video digitizer delay (18 pixel clock cycles). The display naturally needs to scale the output, but in many cases that doesn't add any delay compared to native resolution input.

Interesting. I believe I have heard this about scaling before, but didn't wrap my mind around it obviously

18 pixel clock cycles sounds very fast. What speed are you running the TVP7002 at? 74MHz?

[marqs]

18 pixel clock cycles sounds very fast. What speed are you running the TVP7002 at? 74MHz?

The pixel clock of the digitizer chip is defined by input video properties (total number of lines, refresh rate) and horizontal sampling rate. For 240p/60Hz the resulting pixel clock would be somewhere between 5 and 14MHz depending on the configured sample rate.

[Ed Oscuro]

D'oh, of course, I was thinking of 720p output which we already have ascertained won't be used.

Still this is extremely fast, for our purposes!

[marqs]

D'oh, of course, I was thinking of 720p output which we already have ascertained won't be used.

Still this is extremely fast, for our purposes!

TVP7002 supports digitization up until 1080p, so e.g. those few 720p/1080i -supporting ps2/xbox games would result to 720p/1080p HDMI output. I've also been thinking about scantripling, i.e. converting 240p to 720p. While it wouldn't be that hard to implement (other than horizontal squash to get 4:3 aspect), the resulting number of output lines (3*262 = 786) would probably be a bit too far from the nominal 720p mode (750 lines) to work on most displays. I'd have to test such modes (using PC) with several displays and making sure it works correctly in general before I view scantriple worth implementing.

[Ed Oscuro]

It's the framing of 4:3 content that I'm interested in - also mentioned in the GBA thread. Is this reliably done by sending a special signal / setting a bit flag on HDMI, or would you need to pad signals out with black bars? Or something else entirely?

[marqs]

It's the framing of 4:3 content that I'm interested in - also mentioned in the GBA thread. Is this reliably done by sending a special signal / setting a bit flag on HDMI, or would you need to pad signals out with black bars? Or something else entirely?

With modes like 480p, a flag on the AVI Infoframe indicates whether the content is 4:3 or 16:9, causing TVs to automatically change acpect ratio so that the user doesn't have to pick up the remote. Nothing prevents from setting a 4:3 flag for 720p video, but I'd surprised to see that doing anything. At least my TV doesn't allow switching to 4:3 ratio with 720p/1080p. Therefore, I believe squashing the digitized picture horizontally and padding left&right sides with black bars would be the only option.

[Fudoh]

With modes like 480p, a flag on the AVI Infoframe indicates whether the content is 4:3 or 16:9, causing TVs to automatically change acpect ratio so that the user doesn't have to pick up the remote.

but isn't this something just a media player would interpretate (or a TV's tuner if we're talking about broadcasts) ? I've never seen any display react to anything like this and I don't see how it's kept "alive" on an actual HDMI signal.

[marqs]

With modes like 480p, a flag on the AVI Infoframe indicates whether the content is 4:3 or 16:9, causing TVs to automatically change acpect ratio so that the user doesn't have to pick up the remote.

but isn't this something just a media player would interpretate (or a TV's tuner if we're talking about broadcasts) ? I've never seen any display react to anything like this and I don't see how it's kept "alive" on an actual HDMI signal.

You probably got Audio Video Interleave (video container) mixed with Auxiliary Video Information (an information packet sent per frame/per change basis on HDMI interface). The latter contains aspect, overscan, RGB quantization etc. information about the source video. From my experience, however, most of the data is generally ignored by the displays.

[NightSprinter]

My question on the topic is this: How well would upping the horizontal resolution to 1440, and padding the top abd bottom of the display by 60pix each help in upscaling vertical by 3x? Don't know much for the 720 horizontal part. Am only familiar with upscaling 640x240 up to 1920x960.

[marqs]

My question on the topic is this: How well would upping the horizontal resolution to 1440, and padding the top abd bottom of the display by 60pix each help in upscaling vertical by 3x? Don't know much for the 720 horizontal part. Am only familiar with upscaling 640x240 up to 1920x960.

I guess you mean 4x vertical output in 1080p? Setting the horizoltal resolution to an arbitary value is easy, if you can live with sampling at a rate which does not exactly match the DAC rate at the source console. As far as I know, basically all video digitizers sample 480p/576p or below at around 858 samples per line (720 active) for simplicity. It'd quite trivial so just duplicate the pixels in horizontal direction after sampling, or alternatively sample at a double rate to end up with 1440. Outputting that as part of a 1920-pixel horizontal line is another matter as it'd require generating an independent pixel clock, although in that particular case it'd be exactly 4/3 compared to a 1440-pixel line.

Vertical direction is more problematic, since it's not possible to just arbitarily add or remove lines from the output. That would basically require re-timing the whole frame, which probably is pretty much impossible with FPGA resources. Making the line rate 3x or 4x is relatively easy as you scan out 3 or 4 lines at exactly the same time as one line is scanned in. Adding 60+60 lines - actually, you'd need to add total ~78 lines to get close to nominal 1125 lines of 1080p - would mean that you'd need to scan out 4.297... lines for every line scanned in. Even if such timing was doable with FPGA PLLs, you'd need extra buffering and complexity would be greatly increased. Hopefully that explains my lack of motivation for trying to hit 1080p with 240p input .

[bobrocks95]

Very excited to use this on my EDTV!

2 quick questions:
1) I know you're working to integrate the FPGA and input/digitizer board, but I'm going to buy a Spartan-6 FPGA dev board soon for the Gamecube HDMI work that's being done- is your FPGA logic written in generic HDL of some sort to be portable? It would be nice to just add an input board as you've done with your prototype (also curious how many pins are actually in use, as I see you're using a ribbon cable to connect the boards).

2) Is the analog to digital step something that older TVs did poorly to any degree? Would there be a quality boost going from 480p component input that the TV translates to digital to the separate HDMI conversion beforehand, or is quality pretty consistent?

[alamone]

Any plans for 24KHz support / arcade PCBs with strange sync signals (e.g. 55hz, 56hz, fractional hz)?
Not sure if 24KHz doubling would be feasible, it would be something like 512x384 to 1024x768 (47 KHz / SVGA?)

[fluxcore]

Nice, I'm glad to see more of these kinds of projects popping up. I'd certainly like to ditch my GBS8200 if possible!

[marqs]

Very excited to use this on my EDTV!

2 quick questions:
1) I know you're working to integrate the FPGA and input/digitizer board, but I'm going to buy a Spartan-6 FPGA dev board soon for the Gamecube HDMI work that's being done- is your FPGA logic written in generic HDL of some sort to be portable? It would be nice to just add an input board as you've done with your prototype (also curious how many pins are actually in use, as I see you're using a ribbon cable to connect the boards).

The FPGA logic is written Verilog, and I've tried to avoid vendor-specific modules as much as possible. However, for simplicity and quick compile time I've had to use some Altera-specific blocks such as Nios2 CPU and memory macros. They aren't that hard to replace with generic implementations (or similar blocks from another vendor), and that's one thing to do sometime in the future.

2) Is the analog to digital step something that older TVs did poorly to any degree? Would there be a quality boost going from 480p component input that the TV translates to digital to the separate HDMI conversion beforehand, or is quality pretty consistent?

It depends a lot on TV. Quality-wise, the ADC step is not necessary the biggest problem in general. Usually the issues I've encontered with TVs include bad 240p handling (e.g. treated as 480i) and increased input lag with analog sources (especially interlaced ones). 480p input through component works generally OK with TVs, so it doesn't necessarily get a quality boost. However, there's one advantage I can think of. It's possible to set the sampling rate to exactly match Gamecube's 640x480 output (as with Dreamcast on VGA) instead of using a generic 720x480 to get a pixel-perfect output.

[marqs]

Any plans for 24KHz support / arcade PCBs with strange sync signals (e.g. 55hz, 56hz, fractional hz)?
Not sure if 24KHz doubling would be feasible, it would be something like 512x384 to 1024x768 (47 KHz / SVGA?)

The digitizer chip is specified to work with >40Hz signals and the scandoubling logic just doubles the horizontal frequency, so the only question is does your display support e.g. a 55Hz refresh rate. I wish all monitors were like the NEC LCD I've been using for testing - you can basically throw anything to it, e.g. scandoubled 640x480 (640x960) or some weird refresh rates and it's displayed perfectly

[emphatic]

Very exciting stuff!

[ZellSF]

Do you have any plans of eventually mass manufacturing and selling this?

I want a linedoubler that's not XRGB3 prices already

[fagin]

I want a linedoubler that's not XRGB3 prices already

There are loads of them already available that meet that requirement. I have a whole plethora of them, albeit these are devices that are not made any more, but can be picked up 2nd hand for as little as £50.

[Xyga]

I want a linedoubler that's not XRGB3 prices already

There are loads of them already available that meet that requirement. I have a whole plethora of them, albeit these are devices that are not made any more, but can be picked up 2nd hand for as little as £50.

How many of them as fast, clear and easy as an XRGB though ? Not many...
You have to be very patient and lucky to get anything decent in the £50, if in the past few months you have checked the auctions for even the old DVDO's, Vigatec, Cinemateq, Extron or whatever, you'll see that those attract more and more bidders, and not just two or three.
Plus if you live in Europe you can no longer avoid paying the import tax for anything coming from the US/Canada.