OSSC Pro
Re: OSSC Pro
Yeah, that makes sense. I guess for optimal results, you'd in principle have to adjust the offset for each source/game/kind of video material individually. (actually, introducing a corrective offset can result in a more calm picture, looking at my example above)
Edit: isn't that more like some ringing effect in that XPC-4 shot of yours? Or is it indeed a transition between input fields, caught on camera (your display retaining the old pixels for a short while)?
@marqs: is it planned to give the user control over the offset?
Edit: isn't that more like some ringing effect in that XPC-4 shot of yours? Or is it indeed a transition between input fields, caught on camera (your display retaining the old pixels for a short while)?
@marqs: is it planned to give the user control over the offset?
Re: OSSC Pro
That can be done, but I have to first think how such setting could be presented on UI without overcomplicating things. Current Bob / Noninterlace restore presets set the offset to X/2 (X being line multiplication factor) and 0, respectively, which is easy to understand. The value could be freely selectable between 0 and X, but then should there be a dedicated option for each LineX or a common setting where the value has different effect depending on LineX used? Another question is whether to allow Line3x or Line5x for 480i content - makes sense for noninterlace restore but a "medium" setting wouldn't exist for proper Bob.6t8k wrote:@marqs: is it planned to give the user control over the offset?
Re: OSSC Pro
@marqs do you think the pro will be able to upscale to 1920x1440? it would be great to upscale 640x480 or lower 4:3 resolutions to new monitors keeping the proportion with sharp integer scaling
Working in the japanese language achievement
-
- Posts: 10
- Joined: Wed Jul 17, 2019 10:58 am
Re: OSSC Pro
So a feature I was wondering whether it would be possible to fix or not would be the correction of images that are overly bright or dark..
For example, the Sega mark iii in Japan has an RGB signal that is too dark and typically some sort of amplified cable or something similar is to be used to correct it.
Another one I thought of is the pal N64, using svideo on these systems gives a picture that is overly bright I believe.
So basically my question is, will there be a way that we can amplify dull signals or somehow correct colours of signals that display there colours incorrectly somehow, even in the full scale mode.
Thanks guys!
For example, the Sega mark iii in Japan has an RGB signal that is too dark and typically some sort of amplified cable or something similar is to be used to correct it.
Another one I thought of is the pal N64, using svideo on these systems gives a picture that is overly bright I believe.
So basically my question is, will there be a way that we can amplify dull signals or somehow correct colours of signals that display there colours incorrectly somehow, even in the full scale mode.
Thanks guys!
Re: OSSC Pro
I believe the feature you're looking for is already present in the OSSC, under these menu options:Leewrigley wrote:So basically my question is, will there be a way that we can amplify dull signals or somehow correct colours of signals that display there colours incorrectly somehow, even in the full scale mode.
- R/Pr / G/Y / B/Pb offset
- R/Pr / G/Y / B/Pb gain
- Pre-ADC Gain
-
- Posts: 10
- Joined: Wed Jul 17, 2019 10:58 am
Re: OSSC Pro
Apparently the problem with the pal n64's svideo is that the highlights are clipping and becoming the same brightness value, is this something that can be fixed with these settings or is that not possible?
Re: OSSC Pro
Probably, but neither the OSSC Pro nor the OSSC support s-video input. I would look into N64 RGB mods.
Re: OSSC Pro
Maybe the following could be an efficient solution:marqs wrote:That can be done, but I have to first think how such setting could be presented on UI without overcomplicating things. Current Bob / Noninterlace restore presets set the offset to X/2 (X being line multiplication factor) and 0, respectively, which is easy to understand. The value could be freely selectable between 0 and X, but then should there be a dedicated option for each LineX or a common setting where the value has different effect depending on LineX used? Another question is whether to allow Line3x or Line5x for 480i content - makes sense for noninterlace restore but a "medium" setting wouldn't exist for proper Bob.6t8k wrote:@marqs: is it planned to give the user control over the offset?
- One additional, common setting "LM deint. offset adj.", at the same menu tree level as "LM deinterlace mode"
- Lets user choose one out of "[-6, 6] lines", with the default being "0 lines"
- The formula for the effective offset changes as follows:
For bob deinterlace: min(max(X/2 + Y, 0), 6), for noninterlace restore: max(0 + Y, 0), where X is the current line multiplication factor, and Y the current value for "LM deint. offset adj.".
With 0, behavior is unchanged from the current one, and the effective offset always stays within [0, 6].
I estimate that this setting would be relatively rarely changed, so by implementing it like this, it's kept simple and would not clutter the menu tree too much. At the same time, it's already enough to allow for all combinations. Different offset adj. for different LineX, or for bob deinterlace vs. noninterlace restore, if desired, could be realized by the user with dedicated profiles. Since ideal "LM deint. offset adj" can be expected to depend on the input signal, dedicated profiles seem natural for this. Unlike setting the offset to an absolute value (auto, 0, 1, 2, 3, 4, 5, 6) with "auto" being the current behavior, one could explore what looks best in a more organic way, and enthusiasts would still know what the effective line offset is. It would perhaps also be more elegant to implement than the absolute variant, which would introduce a case differentiation.
If Line3x and Line5x are desired for adaptive line multiplication's 480i proc, they could be implemented as 1280x720, and 1920x1200 with reduced blanking, respectively.
The formula would stay the same for noninterlace restore, and for bob deinterlace it would then be either: min(max(ceil(X/2) + Y, 0), 6), or: min(max(floor(X/2) + Y, 0), 6), which of course would be uneven in comparison to Line4x and Line6x behavior. Speaking only for myself now: although I don't need them considering those that are already announced, I wouldn't have any objections to including these – more choice is always nice. Both will even fill the active area vertically (like Line6x, unlike Line4x). If it doesn't look right, one can choose a different multiplication factor or tinker with "LM deint. offset adj.".
Other opinions?
-
- Posts: 10
- Joined: Wed Jul 17, 2019 10:58 am
Re: OSSC Pro
I should have specified that I already have a koryuu so I would be able to connect it this way if the quality was good enough and I was able to fix the colours. I do have one modded cable that corrects this but the cable sucks and has loads of interference...
-
- Posts: 16
- Joined: Sun May 19, 2019 1:05 pm
Re: OSSC Pro
Will there be support for 1080i input -> line2x -> 1080p output?
Re: OSSC Pro
Hopefully with the PSTV new Sharpscale feature the OSSC Pro is able to do either Linedoubling for 720p and/or Motion Adaptive De-interlacing for 1080i. PSP games look absolutely amazing on the PSTV with Sharpscale and hopefully will look even better through the OSSC Pro.
-
- Posts: 10
- Joined: Wed Jul 17, 2019 10:58 am
Re: OSSC Pro
@marqs do you have any information about how scaling will work in conjunction with rotation. Since you said that the Ossc pro will not be capable of outputting signals larger than 1080p, does this mean that we will not be able to rotate a 480p X2 image as this would give a vertical resolution of 1280 pixels. For 240p games I'm assuming the maximum scale would be 3x as this would give a vertical resolution smaller than 1080? Any clarification on this would be cool
-
- Posts: 1974
- Joined: Wed Jul 19, 2017 1:52 pm
Re: OSSC Pro
I think rotation wouldn't affect the output mode; for resolutions that would exceed the vertical output resolution, I think it would have to either scale or crop.Leewrigley wrote:@marqs do you have any information about how scaling will work in conjunction with rotation. Since you said that the Ossc pro will not be capable of outputting signals larger than 1080p, does this mean that we will not be able to rotate a 480p X2 image as this would give a vertical resolution of 1280 pixels. For 240p games I'm assuming the maximum scale would be 3x as this would give a vertical resolution smaller than 1080? Any clarification on this would be cool
Re: OSSC Pro
Will definitely like to pick up one of these when it's out. Must say I'm a bit disappointed it's not going to have the circuitry for s-video/composite right on the board
Re: OSSC Pro
The HW is not strictly limited to a certain resolution but to a maximum pixel clock frequency - somewhere around 200MHz is current best estimate. That still allows resolutions such as 1920x1440_60Hz (with reduced blanking) but not e.g. standard 2560x1440_60Hz.Leewrigley wrote:@marqs do you have any information about how scaling will work in conjunction with rotation. Since you said that the Ossc pro will not be capable of outputting signals larger than 1080p, does this mean that we will not be able to rotate a 480p X2 image as this would give a vertical resolution of 1280 pixels. For 240p games I'm assuming the maximum scale would be 3x as this would give a vertical resolution smaller than 1080? Any clarification on this would be cool
Technically it should be possible to decode PAL/NTSC etc. from the signals produced by the video ADC, but it's a sub-project of its own.kardus wrote:Will definitely like to pick up one of these when it's out. Must say I'm a bit disappointed it's not going to have the circuitry for s-video/composite right on the board
Re: OSSC Pro
As in the separate add-on board mentioned? Or a future revision having a port for s-video/composite?marqs wrote:Technically it should be possible to decode PAL/NTSC etc. from the signals produced by the video ADC, but it's a sub-project of its own.
Re: OSSC Pro
No, I was referring to the existing design where one could hook composite / s-video into 3xRCA connector block (s-video with an adapter) and PAL/NTSC decoding being fully done on FPGA. The add-on board is an easier option which would include a dedicated chip for doing the decoding (e.g. ADV7280A) but would likely have more limitations such as fixed sampling rate.kardus wrote:As in the separate add-on board mentioned? Or a future revision having a port for s-video/composite?marqs wrote:Technically it should be possible to decode PAL/NTSC etc. from the signals produced by the video ADC, but it's a sub-project of its own.
-
- Posts: 2188
- Joined: Mon Aug 14, 2017 8:34 pm
Re: OSSC Pro
The approach of decoding by the FPGA sounds great, especially for composite where a simple RCA cable would be all one needs. S-video to RCA (or BNC+RCA adapter) breakout cables are also not hard to come by. Hopefully this sub-project eventually comes to fruition, even if the add-on board is also available as an alternative.marqs wrote:No, I was referring to the existing design where one could hook composite / s-video into 3xRCA connector block (s-video with an adapter) and PAL/NTSC decoding being fully done on FPGA. The add-on board is an easier option which would include a dedicated chip for doing the decoding (e.g. ADV7280A) but would likely have more limitations such as fixed sampling rate.
Re: OSSC Pro
That's so neat! I also hope that this sees the light of day sometime.marqs wrote:one could hook composite / s-video into 3xRCA connector block (s-video with an adapter) and PAL/NTSC decoding being fully done on FPGA. The add-on board [...] would likely have more limitations such as fixed sampling rate.
A few more questions/ideas:
Q: Do we know whether the ISL51002 handles constant even field indicator better than the TVP7002? If yes, then this would benefit compatibility with sources like the Taito F3 and GBI.
Q: For processing AV4 (the HDMI input), am I right to assume that it can be fed into the further processing stages the same way as analog sources can after digitization? Consequently, one could use a line multiplication mode for minimal latency on the one hand, and a scaler mode for maximal flexibility on the other hand.
I: Introduce a global metric that gives an estimation about the current latency between the input signal and the output signal.
Re: OSSC Pro
A little off topic but is there any way to sign up for notification on the OSSC Pro release? I'm holding off hunting for a DVDO + OSSC / Framemeister setup because this sounds like the real flexible deal.
Re: OSSC Pro
Yes, doesn't seem to be an issue to this chip.6t8k wrote:Q: Do we know whether the ISL51002 handles constant even field indicator better than the TVP7002? If yes, then this would benefit compatibility with sources like the Taito F3 and GBI.
Yes.6t8k wrote:Q: For processing AV4 (the HDMI input), am I right to assume that it can be fed into the further processing stages the same way as analog sources can after digitization? Consequently, one could use a line multiplication mode for minimal latency on the one hand, and a scaler mode for maximal flexibility on the other hand.
It can be done, but latency is not necessarily a fixed number as it can vary between top and bottom of the picture.6t8k wrote:I: Introduce a global metric that gives an estimation about the current latency between the input signal and the output signal.
Re: OSSC Pro
I'm most looking forward to the Pro for a silly reason. I'm always looking for a quality SCART to HDMI transcoder, and then I realize that's what the standard OSSC does (and more! ). I'll replace it with the Pro when released, then I'll use the standard as my transcoder.
Re: OSSC Pro
marqs: thanks for answering my questions – that's great to hear! I like to think I'm asking on behalf of everybody interested in the Pro, since I'm not the only one benefitting from the answers.
Showing the value of two variables:
- Time difference between first active sample/pixel of input frame and corresponding pixel of output frame
- Time difference between last active sample/pixel of input frame and corresponding pixel of output frame
One way these could be obtained would be to calculate them synthetically based on the parameters of the current input signal and the set of settings that's currently in effect.
However, this would produce potentially confusing (albeit not incorrect) values for rotation, and arrangements like the following, in scaler mode – assuming that users will be able to do something like this (advocatus diaboli):
- Some different part of the input frame comes before the first sample/pixel of the input frame
- After last sample/pixel of input frame, there comes some different part of the input frame
Or, a more extreme example:
- Some different part of the input frame comes before the first sample/pixel of the input frame
- Last sample/pixel of input frame comes before first sample/pixel of input frame
Perhaps users would just have to take this into account when looking at the latency numbers, or would there be a more crafty way of obtaining meaningful latency numbers in all cases?
Would there be something speaking against the following idea?marqs wrote:It can be done, but latency is not necessarily a fixed number as it can vary between top and bottom of the picture.6t8k wrote:I: Introduce a global metric that gives an estimation about the current latency between the input signal and the output signal.
Showing the value of two variables:
- Time difference between first active sample/pixel of input frame and corresponding pixel of output frame
- Time difference between last active sample/pixel of input frame and corresponding pixel of output frame
One way these could be obtained would be to calculate them synthetically based on the parameters of the current input signal and the set of settings that's currently in effect.
However, this would produce potentially confusing (albeit not incorrect) values for rotation, and arrangements like the following, in scaler mode – assuming that users will be able to do something like this (advocatus diaboli):
Spoiler
- After last sample/pixel of input frame, there comes some different part of the input frame
Or, a more extreme example:
Spoiler
- Last sample/pixel of input frame comes before first sample/pixel of input frame
Perhaps users would just have to take this into account when looking at the latency numbers, or would there be a more crafty way of obtaining meaningful latency numbers in all cases?
-
- Posts: 635
- Joined: Fri Apr 20, 2018 9:22 am
- Location: Washigton DC
Re: OSSC Pro
These questions and answers are awesome and there are probably plenty of lurkers like myself who enjoy reading them, keep 'em coming!
That being said, Marqs, it's now August. Can we have a sliver of an update on where the project is currently?
That being said, Marqs, it's now August. Can we have a sliver of an update on where the project is currently?
Re: OSSC Pro
You all should get used to hearing "it's done when it's done."
Re: OSSC Pro
Hi guys, how are you? I've been away for the longest time, so I hope in these odd times you all are well and safe.
I've also been following the news about the OSSC, of course, and I'm just as excited as all of you guys.
I've got a few questions for Marqs, Matt and all the other good people involved in the project, hope you don't mind me asking:
1- Will the OSSC Pro be able to support more advanced post-processing effects, such as CRT shaders à la RetroArch?
2 - I've read this (from VGP website):
Frame buffer mode will also allow for input and output frame rates to be de-coupled. This should help with games that switch between 240p and 480i output modes. The trade off is loss of completely smooth, judder free scrolling, but for games rendered completely unplayable on modern TVs it’s a trade off worth making.
What does it mean exactly? Are we talking about shimmering, here? I've never seen it in action, so it's just to picture it. >>>>>>>>>>>>>>>>>>>>> Thanks Kez for clarifying. ^_-
3 - Would the aforementioned trade-off be in place also with Mega Drive/Genesis games that switch from 320p to 256p widths? Some of them only switch resolution once, after the SEGA logo, but a few of them (some notable too, such as Splatterhouse Part 3 or Vampire Killer) actually keep changing throughout the whole game (intro > options > gameplay > cutscenes > gameplay...), ending up being a real pain to play, for those like me who prefer to use optimal profiles, rather than generic settings.
4 - According to the previous point - and since I already mentioned RetroArch - anything like RA's 1:1 PAR scaling mode would be doable, with the OSSC Pro?
I find it extremely helpful with the MD especially, as it always keep the aspect ratio as it's supposed to be, without stretching occasional 256p graphics into 320p (or viceversa, squeezing 320p into 256p).
From what I understand, the OSSC Pro will retain profiles, so it's probably not possible. It sounds to me like combining two optimal profiles into one, seamlessly... I'm totally uneducated on that, I'm just thinking out loud.
Thanks in advance guys, y'all take care!
I've also been following the news about the OSSC, of course, and I'm just as excited as all of you guys.
I've got a few questions for Marqs, Matt and all the other good people involved in the project, hope you don't mind me asking:
1- Will the OSSC Pro be able to support more advanced post-processing effects, such as CRT shaders à la RetroArch?
2 - I've read this (from VGP website):
Frame buffer mode will also allow for input and output frame rates to be de-coupled. This should help with games that switch between 240p and 480i output modes. The trade off is loss of completely smooth, judder free scrolling, but for games rendered completely unplayable on modern TVs it’s a trade off worth making.
What does it mean exactly? Are we talking about shimmering, here? I've never seen it in action, so it's just to picture it. >>>>>>>>>>>>>>>>>>>>> Thanks Kez for clarifying. ^_-
3 - Would the aforementioned trade-off be in place also with Mega Drive/Genesis games that switch from 320p to 256p widths? Some of them only switch resolution once, after the SEGA logo, but a few of them (some notable too, such as Splatterhouse Part 3 or Vampire Killer) actually keep changing throughout the whole game (intro > options > gameplay > cutscenes > gameplay...), ending up being a real pain to play, for those like me who prefer to use optimal profiles, rather than generic settings.
4 - According to the previous point - and since I already mentioned RetroArch - anything like RA's 1:1 PAR scaling mode would be doable, with the OSSC Pro?
I find it extremely helpful with the MD especially, as it always keep the aspect ratio as it's supposed to be, without stretching occasional 256p graphics into 320p (or viceversa, squeezing 320p into 256p).
From what I understand, the OSSC Pro will retain profiles, so it's probably not possible. It sounds to me like combining two optimal profiles into one, seamlessly... I'm totally uneducated on that, I'm just thinking out loud.
Thanks in advance guys, y'all take care!
Last edited by Galdelico on Sun Aug 09, 2020 2:29 pm, edited 1 time in total.
Re: OSSC Pro
@Galdelico: With regards to point 2, I believe the stuttering in question is related to refresh rate mismatch. So rather than shimmering, it would be an occasional minor stutter, jump or skip.
Re: OSSC Pro
A second prototype board should be finished soon. Estimates on release date etc. will have to wait until that's on my hands and verified. It's also worth remembering that even if the prototype HW works flawlessly and is ready for production, firmware is still far from the point which I feel comfortable releasing it with.XtraSmiley wrote:That being said, Marqs, it's now August. Can we have a sliver of an update on where the project is currently?
Something similar is technically possible, at least to some extent.Galdelico wrote:1- Will the OSSC Pro be able to support more advanced post-processing effects, such as CRT shaders à la RetroArch?
Yes, a dropped / duplicated frame every now and then.Galdelico wrote:What does it mean exactly? Are we talking about shimmering, here? I've never seen it in action, so it's just to picture it. >>>>>>>>>>>>>>>>>>>>> Thanks Kez for clarifying. ^_-
While MD refresh rate remains same after this column mode switch (unlike with 240p<->480i), it still interrupts sync which makes it hard to keep line/framelock. There might be some ways around it, but at least initially disabling framelock would be the only way to keep display synced at all times.Galdelico wrote:3 - Would the aforementioned trade-off be in place also with Mega Drive/Genesis games that switch from 320p to 256p widths? Some of them only switch resolution once, after the SEGA logo, but a few of them (some notable too, such as Splatterhouse Part 3 or Vampire Killer) actually keep changing throughout the whole game (intro > options > gameplay > cutscenes > gameplay...), ending up being a real pain to play, for those like me who prefer to use optimal profiles, rather than generic settings.
I suppose you mean detecting the column mode MD outputs and auto-selecting profile / contolling setting akin to "256x240 aspect" already present in classic OSSC fw. Like other requests related to detection of a specific console/mode, it comes down whether the little extractable information present in the analog signal (number of lines, refresh rate, hsync length etc.) is enough to enable reliably mapping to an unique system/mode considering all the mods and variations out there.Galdelico wrote:4 - According to the previous point - and since I already mentioned RetroArch - anything like RA's 1:1 PAR scaling mode would be doable, with the OSSC Pro?
I find it extremely helpful with the MD especially, as it always keep the aspect ratio as it's supposed to be, without stretching occasional 256p graphics into 320p (or viceversa, squeezing 320p into 256p).
From what I understand, the OSSC Pro will retain profiles, so it's probably not possible. It sounds to me like combining two optimal profiles into one, seamlessly... I'm totally uneducated on that, I'm just thinking out loud.
Re: OSSC Pro
Thanks Kez and marqs for taking the time and reply, much appreciated.
@marqs - Yeah, in regards to point 4, I tend to forget it. You must be bombarded with requests for supporting this or that particular system's obscure video mode.
@marqs - Yeah, in regards to point 4, I tend to forget it. You must be bombarded with requests for supporting this or that particular system's obscure video mode.
Re: OSSC Pro
Is it possible to upscale and downscale simultaneously? For example a 480p HDMI input, I would like to output 240p to a 15hz broadcast monitor and also upscale to lets say 1080p for video capture purposes