OSSC Pro

[Zacabeb]

Hey i was wondering about this for a while but how do you know you can get the input lag to under a frame in scaler mode if it hasnt been done yet? And if its in the works what is an ETA for that feature?

I'm curious about this too. There being a frame (or field?) of input lag in the first place with framelock on seems a bit strange. Simple edge detection de-interlacing (like Intel's "Deinterlacer I" core I think is used) doesn't rely on data from future video fields and polyphase scaling theoretically doesn't need much more than an input line more delay than integer scaling. So I wouldn't be surprised if the delay is already less than one field.

[orange808]

I haven't bought an OSSC Pro just yet. I see a question about 1080p input signals in another thread.

Can the OSSC Pro accept and process 1080p input signals? If that's possible, how much processing latency does the OSSC Pro require? I assume it needs to be in scaler mode?

[LDigital]

I haven't bought an OSSC Pro just yet. I see a question about 1080p input signals in another thread.

Can the OSSC Pro accept and process 1080p input signals? If that's possible, how much processing latency does the OSSC Pro require? I assume it needs to be in scaler mode?

Yes it can. This is my main use for the pro

I use 1080p hdmi input to add bfi and custom scanlines for my switch to my oled. I also use the downscaling function to 240p for shmups on my bvm using the av out board. I believe it adds a frame or something but I don’t know exactly. Marqs can probably confirm

[marqs]

Hey i was wondering about this for a while but how do you know you can get the input lag to under a frame in scaler mode if it hasnt been done yet? And if its in the works what is an ETA for that feature?

I'm curious about this too. There being a frame (or field?) of input lag in the first place with framelock on seems a bit strange. Simple edge detection de-interlacing (like Intel's "Deinterlacer I" core I think is used) doesn't rely on data from future video fields and polyphase scaling theoretically doesn't need much more than an input line more delay than integer scaling. So I wouldn't be surprised if the delay is already less than one field.

Fundamentally there is no technical barrier to significantly reduce latency outside of corner cases like rotation or putting a zoomed-out stamp sized source somewhere on the output frame. The extra latency currently comes from usage of external frame buffer IP which does not allow reading a buffer that is still being written to. This is similar to how things work on PC side when you have vsync enabled, with the major exception that write of the GPU framebuffer happens almost instantaneously whereas filling the buffer from an external video source occurs slowly over the scanout duration (e.g. 16ms). Designing your own IP to operate in between other 3rd party IPs takes time and you need to stay focused on that task for a while. With so many other things on your table (add-on cards, next batch, USB & RF features, CMU, alternative fw support, bug fixing, final fw for OSSC Classic etc.) I can't give ETA on when I can start concentrating on this. I was and still am hoping for larger community support on development side to balance out these kind of tasks, but that has yet to materialize (with more units out things might eventually improve).

[WasherFace]

Hey i was wondering about this for a while but how do you know you can get the input lag to under a frame in scaler mode if it hasnt been done yet? And if its in the works what is an ETA for that feature?

I'm curious about this too. There being a frame (or field?) of input lag in the first place with framelock on seems a bit strange. Simple edge detection de-interlacing (like Intel's "Deinterlacer I" core I think is used) doesn't rely on data from future video fields and polyphase scaling theoretically doesn't need much more than an input line more delay than integer scaling. So I wouldn't be surprised if the delay is already less than one field.

Fundamentally there is no technical barrier to significantly reduce latency outside of corner cases like rotation or putting a zoomed-out stamp sized source somewhere on the output frame. The extra latency currently comes from usage of external frame buffer IP which does not allow reading a buffer that is still being written to. This is similar to how things work on PC side when you have vsync enabled, with the major exception that write of the GPU framebuffer happens almost instantaneously whereas filling the buffer from an external video source occurs slowly over the scanout duration (e.g. 16ms). Designing your own IP to operate in between other 3rd party IPs takes time and you need to stay focused on that task for a while. With so many other things on your table (add-on cards, next batch, USB & RF features, CMU, alternative fw support, bug fixing, final fw for OSSC Classic etc.) I can't give ETA on when I can start concentrating on this. I was and still am hoping for larger community support on development side to balance out these kind of tasks, but that has yet to materialize (with more units out things might eventually improve).

Dang i wish i could be able to help with this. Maybe by spreading the word out that youd want help with this feature?

[emmeka]

What output resolutions do the Extra AV add-on board support? The product page on VGP just says "15khz and 31khz output supported", and I'm assuming that all the "CRT output modes" listed on the wiki like 540p, XGA, QVGA, would all probably work, but does the analog output support higher resolutions from "DFP output mode" too, like say 1600x1200, 1920x1080p, or 1920x1440? In my current setup I have basically everything run through an RGBHV distribution amplifier connected to CRT monitors, LCD TVs, etc and it'd work best if I could just keep everything analog.

[marqs]

Dang i wish i could be able to help with this. Maybe by spreading the word out that youd want help with this feature?

I'd be mainly expecting other devs to start work on new features they are most interested to see included, e.g. some of the previously listed ones or porting some FPGA arcade/console cores. Time-consuming rewriting/optimization of existing ones may not be so exciting, but would be appreciated just as much.

What output resolutions do the Extra AV add-on board support? The product page on VGP just says "15khz and 31khz output supported", and I'm assuming that all the "CRT output modes" listed on the wiki like 540p, XGA, QVGA, would all probably work, but does the analog output support higher resolutions from "DFP output mode" too, like say 1600x1200, 1920x1080p, or 1920x1440? In my current setup I have basically everything run through an RGBHV distribution amplifier connected to CRT monitors, LCD TVs, etc and it'd work best if I could just keep everything analog.

The DAC is rated to 140MHz so it should work fine at least up to 1920x1080p.

[Zacabeb]

I've noticed weaving in some games even if Motion Shift is set quite low, especially in Ridge Racer V on the PS2 (that game is pretty much a torture test for any deinterlacer.) I'm wondering if that motion detection error in the deinterlacer could be reduced by tweaking the Motion Scale parameter and if so, a few variants with different Motion Scale values be added to help optimize deinterlacing for problematic games. An interlaced game that uses field rendering versus one that uses flicker reduced progressive rendering may cause differences in motion detection.

It is possible to almost get rid of the weaving artifacts in moving parts and still retain reasonable weaving of static parts in Ridge Racer V with Motion Shift set to 1 or 2, at the cost of some flickering in menus.

[orange808]

I've noticed weaving in some games even if Motion Shift is set quite low, especially in Ridge Racer V on the PS2 (that game is pretty much a torture test for any deinterlacer.) I'm wondering if that motion detection error in the deinterlacer could be reduced by tweaking the Motion Scale parameter and if so, a few variants with different Motion Scale values be added to help optimize deinterlacing for problematic games. An interlaced game that uses field rendering versus one that uses flicker reduced progressive rendering may cause differences in motion detection.

It is possible to almost get rid of the weaving artifacts in moving parts and still retain reasonable weaving of static parts in Ridge Racer V with Motion Shift set to 1 or 2, at the cost of some flickering in menus.

I don't understand why you're doing this. IIRC, RR5 has a 240p frame buffer, so the correct way to boot and play is GSM NTSC 240p.

AFAIK, it's a 240p game, so force the output to 240p, skip the interlacing step at the console, and upscale it.

[XtraSmiley]

Hey i was wondering about this for a while but how do you know you can get the input lag to under a frame in scaler mode if it hasnt been done yet? And if its in the works what is an ETA for that feature?

I'm curious about this too. There being a frame (or field?) of input lag in the first place with framelock on seems a bit strange. Simple edge detection de-interlacing (like Intel's "Deinterlacer I" core I think is used) doesn't rely on data from future video fields and polyphase scaling theoretically doesn't need much more than an input line more delay than integer scaling. So I wouldn't be surprised if the delay is already less than one field.

Fundamentally there is no technical barrier to significantly reduce latency outside of corner cases like rotation or putting a zoomed-out stamp sized source somewhere on the output frame. The extra latency currently comes from usage of external frame buffer IP which does not allow reading a buffer that is still being written to. This is similar to how things work on PC side when you have vsync enabled, with the major exception that write of the GPU framebuffer happens almost instantaneously whereas filling the buffer from an external video source occurs slowly over the scanout duration (e.g. 16ms). Designing your own IP to operate in between other 3rd party IPs takes time and you need to stay focused on that task for a while. With so many other things on your table (add-on cards, next batch, USB & RF features, CMU, alternative fw support, bug fixing, final fw for OSSC Classic etc.) I can't give ETA on when I can start concentrating on this. I was and still am hoping for larger community support on development side to balance out these kind of tasks, but that has yet to materialize (with more units out things might eventually improve).

I think that rotate feature will help move some units, but doubt it will help with community input. I'm still excited for it though!

[Zacabeb]

I've noticed weaving in some games even if Motion Shift is set quite low, especially in Ridge Racer V on the PS2 (that game is pretty much a torture test for any deinterlacer.) I'm wondering if that motion detection error in the deinterlacer could be reduced by tweaking the Motion Scale parameter and if so, a few variants with different Motion Scale values be added to help optimize deinterlacing for problematic games. An interlaced game that uses field rendering versus one that uses flicker reduced progressive rendering may cause differences in motion detection.

It is possible to almost get rid of the weaving artifacts in moving parts and still retain reasonable weaving of static parts in Ridge Racer V with Motion Shift set to 1 or 2, at the cost of some flickering in menus.

I don't understand why you're doing this. IIRC, RR5 has a 240p frame buffer, so the correct way to boot and play is GSM NTSC 240p.

AFAIK, it's a 240p game, so force the output to 240p, skip the interlacing step at the console, and upscale it.

Ridge Racer V is natively 448i, rendered by the game in 640x224 with vertices offset vertically by half a pixel every other field. If the GS CRTC was forced to output non-interlaced the game would either keep rendering with a subpixel offset every other field, or at best drop half the vertical resolution in static parts like the HUD and menus. There'd also be a slight reduction in refresh rate that the game logic might not like.

To make things worse, it's the PAL version which causes additional headaches (some of which, like the infamous PAL vertical squeeze, can be rectified in Scaler Mode on the OSSC Pro.) But short of using an emulator to run RRV natively at a higher resolution, de-interlacing is needed.

[orange808]

Ridge Racer V is natively 448i, rendered by the game in 640x224 with vertices offset vertically by half a pixel every other field. If the GS CRTC was forced to output non-interlaced the game would either keep rendering with a subpixel offset every other field, or at best drop half the vertical resolution in static parts like the HUD and menus. There'd also be a slight reduction in refresh rate that the game logic might not like.

It's not 448i. That signal doesn't exist in any meaningful way.

I don't recall any artifacts when GSM displays the game at 240p. It's my understanding that the interlacing and flicker filtering is never applied.

To make things worse, it's the PAL version

I just don't understand. You're certainly welcome to play at 50Hz, but it's really a substandard way to enjoy a fast paced racer.

Yeah, it's a torture test. Then again, I can turn on a skateboarding video and break any low latency video game deinterlacer. It's that difficult to defeat these fast algorithms.

[Zacabeb]

Ridge Racer V is natively 448i, rendered by the game in 640x224 with vertices offset vertically by half a pixel every other field. If the GS CRTC was forced to output non-interlaced the game would either keep rendering with a subpixel offset every other field, or at best drop half the vertical resolution in static parts like the HUD and menus. There'd also be a slight reduction in refresh rate that the game logic might not like.

It's not 448i. That signal doesn't exist in any meaningful way.

I don't recall any artifacts when GSM displays the game at 240p. It's my understanding that the deinterlacing and flicker filtering is never applied.

In static areas like the HUD it does become 448i/480i since those elements have a half pixel offset as well and are vertically downscaled to half size each field with alternating pixels dropped, letting those parts be deinterlaced into 448p/480p/576p. But of course any moving parts rendered as single fields at 60 fps/50 fps are effectively comparable to 224p/240p. I won't argue that.

(When I say 448i, of course that exists inside a regular 480i or 576i signal with black bars. But one can argue that the active area proper of 525i is any of 487i, 486i, or 480i, so I use the term 448i for convenience since that's all the game renders.)

It's nice to hear the game seems to handle being forced into non-interlaced output. I also don't want to play the game in 50 Hz if it accepts being forced to run at 60 Hz (I don't think they've slowed the gameplay down though.) Aside from the PAL squeeze (which can be undone on the OSSC Pro) there are some audio glitches that I believe may be related to the PAL conversion. However, for the time being I have to live with it and that's where the adaptive deinterlacing of the OSSC Pro is nice to have.

[fernan1234]

Is color correction filter support a planned feature of the OSSC Pro?

[marqs]

Is color correction filter support a planned feature of the OSSC Pro?

There's discussion about CMU earlier on this page. Planned - yes, high priority - no.

[SGGG2]

Brought this up earlier, but want to point it out again. Using GSM set to 1080i on PS2, paired with "noninterlace restore" on the OSSC can result in an image that's identical (or superior) to native progressive. When good, It's better than MADI because there's no processing time and motion is MUCH clearer. Sometimes, it's not progressive looking due to shimmering (but better than bob), other times neither offset looks correct.

Some examples, Sonic Riders Zero Gravity and Clock Tower 3. Unfortunately, Clock Tower requires one offset for FMV, and other for gameplay. Espgaluda. NIR at 1080i yields a proper looking image, 480i NIR or 480p both look bad. Give it a try!

[Strider77]

So how does the rotate feature on the OSSC Pro work out in use?

What source resolutions can it rotate?

[XtraSmiley]

So how does the rotate feature on the OSSC Pro work out in use?

What source resolutions can it rotate?

It doesn't exist yet ask far as I thought. On the "to do" list.

[Amsteffydam]

Is the 8 standard + 2 custom shado mask options a hard limit or is it possible that more can be added in firmware? I would love to have more than 2 custom options at least.
And would anyone know if someone is working on shadow masks that resemble the handheld screens of the GB/GBC/GG/GBA That is compatible with the OSSC Pro?

[LDigital]

Is the 8 standard + 2 custom shado mask options a hard limit or is it possible that more can be added in firmware? I would love to have more than 2 custom options at least.
And would anyone know if someone is working on shadow masks that resemble the handheld screens of the GB/GBC/GG/GBA That is compatible with the OSSC Pro?

I think there are just the two custom slots for now. Maybe Marqs can add more.

I haven’t found anyone who is producing custom masks for it though.

I did experiment with importing some MisterFPGA masks which it is compatible with. The problem I found was there is no gamma compensation setting so the screen ends up way to dark, even with hdr and everything dialled to max.

[underage]

Does the OSSC Pro retain the line3x laced (linetripled to 1440i/1728i) output option of the original OSSC?

[jaffa225man]

Does the OSSC Pro retain the line3x laced (linetripled to 1440i/1728i) output option of the original OSSC?

It appears so, but only in the same mode (Pure Line Multiplier) as of the current v0.75 firmware, and not Adaptive Line Multiplier or Scaler modes. My projector doesn't support Pure Line Multiplier 480i Line3x, though, so every menu screenshot you see in the photos below is using Scaler mode CRT 1280x960.

https://imgur.com/gallery/PadRn9p

Spoiler

Pure Line Muliplier "Line3x (laced)" Available:


Adaptive Line Multiplier 480i Options:


Adaptive Line Multiplier 576i Options:


Scaler DFP Options:


Scaler CRT Options:

[underage]

It appears so, but only in the same mode (Pure Line Multiplier) as of the current v0.75 firmware, and not Adaptive Line Multiplier or Scaler modes. My projector doesn't support Pure Line Multiplier 480i Line3x, though, so every menu screenshot you see in the photos below is using Scaler mode CRT 1280x960.

https://imgur.com/gallery/PadRn9p

Spoiler

Pure Line Muliplier "Line3x (laced)" Available:


Adaptive Line Multiplier 480i Options:


Adaptive Line Multiplier 576i Options:


Scaler DFP Options:


Scaler CRT Options:

Thanks for taking the time to check that!
In pure LM mode, does the Pro model offer more seamless 240p to 480i transitions compared to the standard OSSC? Or is that only possible in scaling mode?

[jaffa225man]

Thanks for taking the time to check that!
In pure LM mode, does the Pro model offer more seamless 240p to 480i transitions compared to the standard OSSC? Or is that only possible in scaling mode?

You're quite welcome! It's certainly not seamless switching on my projector in any mode other than scaler with aspect ratio set to not be based on the source (or auto) and with framelock turned off (and not based on the source Hz).

Currently the highest scaler resolution available that's interlaced is 1920x1080i, but maybe Marqs can add two Line3x modes to scaler to suit your needs (for 1440i, and 1728i). I don't think it would be much harder than adding modelines for them, but I wouldn't want to compile the source code myself because toolchains for projects like this aren't always GNU/Linux friendly. and more importantly. I have been running out of storage for a while. Besides that, I don't even have a display that goes to resolutions that high.

[underage]

You're quite welcome! It's certainly not seamless switching on my projector in any mode other than scaler with aspect ratio set to not be based on the source (or auto) and with framelock turned off (and not based on the source Hz).

Currently the highest scaler resolution available that's interlaced is 1920x1080i, but maybe Marqs can add two Line3x modes to scaler to suit your needs (for 1440i, and 1728i). I don't think it would be much harder than adding modelines for them, but I wouldn't want to compile the source code myself because toolchains for projects like this aren't always GNU/Linux friendly. and more importantly. I have been running out of storage for a while. Besides that, I don't even have a display that goes to resolutions that high.

So maybe I'm under misapprehension, I had assumed that screen blanking with 240p/480i transitions (or 720p/1440i for that matter) are due to some kind of latency inherent to the OSSC when switching resolutions, rather than just the display being output to?
I would also be using the OSSC Pro with a projector, but in my case it's CRT front projection (so no added processing latency), and now I'm wondering if the screen blanking issue would even persist under these circumstances.

Anyway, it would be nice if the OSSC project could implement some sort of bounty system for feature requests. I certainly couldn't do it on my own either. And I understand that such a niche use case is unlikely to garner much developer interest, but with a bit of financial compensation there might be more incentive to cater to even the arcane ones.

[Guspaz]

It's the age old problem with all scalers. 240p and 480i have different timing, and if you're using a scaler in some sort of framelock mode, the change in video timings gets exposed to the display, which can cause a full resync. The obvious method to address this is a full framebuffer to normalize the video timings, which has the downside of additional latency, but these days there are intermediate solutions (something like VRR+genlock on RetroTINK devices) that can in many cases avoid display resyncs without additional latency.

[underage]

It's the age old problem with all scalers. 240p and 480i have different timing, and if you're using a scaler in some sort of framelock mode, the change in video timings gets exposed to the display, which can cause a full resync. The obvious method to address this is a full framebuffer to normalize the video timings, which has the downside of additional latency, but these days there are intermediate solutions (something like VRR+genlock on RetroTINK devices) that can in many cases avoid display resyncs without additional latency.

So a CRT is just faster at resyncing then, and hence wouldn't need any workarounds?
240p/480i transition doesn't cause perceptible blanking on a SD-CRT, so I'm assuming 720p/1440i transitions wouldn't cause any with a HD-CRT (like say a PC monitor)?

[fernan1234]

So a CRT is just faster at resyncing then, and hence wouldn't need any workarounds?

CRTs (those which support multiple scan rates) do blank out for half a second or so when switching between scan rates (often accompanied by a clicking sound). However, "240p" and 480i are the same scan rate (15khz) so as far as the CRT is concerned there is no change so the transition is instant.

[orange808]

Provided you have a fast display, fast output frame rates from the video scaler can reduce the penalty for using a full frame buffer.

Consider how long it takes for all the information in a single 60Hz frame to reach the display when directly connected to the display. That's straightforward. It's 16 and 2/3 milliseconds. Let's round it off. It's about seventeen milliseconds (~17ms). A CRT scans the frame as it arrives, but the entire frame isn't displayed until ~17ms have passed. Obviously, we can't display a frame without all the information.

Let's talk about using the OSSC Pro.

Now, consider feeding the OSSC Pro and outputting to your display. First, the OSSC Pro will buffer the entire frame. That takes ~17ms for your ~60Hz source. Next, the OSSC Pro sends the information up the wire to the display.

If you send the frame at 60Hz, the signal takes another ~17ms to go up the wire to the display. So, the total latency for a zero lag display is a little under 34ms (~17ms buffer + ~17ms display time).

But, consider sending the frame at 120Hz and repeating the frame one time (before sending the next frame). The information goes up the wire faster. The display has to show the frame and be ready for the next one. The display doesn't know we are repeating frames. So, a fast display will scan out the frame in 8 and 1/3 milliseconds. Let's round again. It's about eight milliseconds (~8ms).

At 120Hz, the OSSC Pro, the signal takes ~8ms to go up the wire. So, the total latency is ~25ms (~17ms buffer + ~8ms display time).

So, for a fast display, the entire frame is transferred and fully displayed about eight milliseconds (~8ms) later than wiring a direct 60Hz source to your display. So, you get a full frame buffer with half a frame of actual additional latency.

So, you can learn to love the full frame buffer with a fast display and an OSSC Pro. It doesn't have to cost a full frame of extra total lag if you can output 120Hz from the scaler.

[jaffa225man]

The 60Hz scaler mode's frame buffer is my preference over my projector's inputs displaying every time it resyncs. They remain onscreen for about ten seconds each time. That's not to say that 120Hz wouldn't be great, but my projector didn't support it, and I don't notice this minor lag at all.