OSSC Pro

[nmalinoski]

Noninterlace restore

Could you please elaborate on this mode? Would this, for example, take 480i60, buffer a field, then output 480p30? Or is this like an overlay-type deinterlacing that takes a composite frame of the previous two fields and just keeps writing each new field on top?

[Extrems]

I assume it mean restoring 240p output as 480i.

[6t8k]

Like Extrems wrote, I have been thinking of "noninterlace restore" as going from (X)i to (X/2)p, where X is a line count (refer to this post and the table above).

The feature changing the framerate seems to be ruled out because it works in ALM mode, which is framelocked, so I was wondering whether it A) dropped one half of the picture information (all odd or all even fields), or B) drawed interlaced video's alternating X/2 lines per field onto a (X/2)p canvas for every input field, producing a bobbing effect similar to the one produced by the aptly named bob deinterlacing.

[Kez]

It's for games that should be in 240p but are running at 480i. Many of the ports on PS2 for example do this. There would be no bob or shimmer, as the 480i output is effectively Line2x 240p. It's restoring progressive scan to incorrectly interlaced images.

[Fudoh]

It applies BOB deinterlacing (doubling each field on its own), but is shifting the fields towards each other until the flicker is gone.

[6t8k]

Kez: I understand the use case, but isn't it a bit more complex? 240p x2 is not 480i; with 480i, as opposed to 240p, the same picture information is arranged in a different way on the time scale: the same 1/60s frame in 240p is divided into two 1/60s fields in 480i, isn't it? Edit: nah, it actually makes sense, yes, thanks. As you have 240 lines in each 480i field, you could simply project each 240p frame onto one 480i field.

Fudoh: but doesn't doubling the lines of each field imply retaining a canvas of the original line-height?

[Fudoh]

Fudoh: but doesn't doubling the lines of each field imply retaining a canvas of the original line-height?

I'm thinking of 480p+ output from a 15khz source. If you want native 240p output instead you can half the resolution afterwards. You can even shift the original fields towards each other without the doubling, but if you do that, you can run into problems if there's ever so slight filtering applied to the image. Going to an higher internal resolution first gives you more options.

Mike Chi is implementing a field shift option into the next generation Retrotink 2X as well, so you can manually adjust the level of visible flicker depending on the type of 480i source you're using.

The GBS(Control) in Bob mode is using the biggest possible vertical offset between the fields. I've only seen this on the Micomsoft XPC-4 before. The XRGB-3 is using the smallest. The OSSC is somehwere in the middle. This way bob deinterlacing can look very different from device to device.

[Fudoh]

the same 1/60s frame in 240p is divided into two 1/60s fields in 480i, isn't it?

no, not at all, this would essentially cut the motion resolution into half. You can have perfectly fine 60fps, even for 2D titles, in 480i.

[6t8k]

I'm thinking of 480p+ output from a 15khz source. If you want native 240p output instead you can half the resolution afterwards.

Yeah, but we were writing about the noninterlace restore feature, which does, for example, 480i->240p. If you first double the lines of the fields, and then throw away half of the doubled fields again, aren't we then simply back to my first post on this page? Shifting them towards each other or not, in the end you have to output 240 lines in 1/60s. You only have access to 240 lines in 1/60s from the input signal's field. In the next 1/60s - so only during the next frame of your 240p output - it is when you have access to the next input field, so the image will necessarily have to bob, unless I'm still missing something?

the same 1/60s frame in 240p is divided into two 1/60s fields in 480i, isn't it?

no, not at all, this would essentially cut the motion resolution into half. You can have perfectly fine 60fps, even for 2D titles, in 480i.

I noticed that too, my comparison was misguided - it's the reverse what's nontrivial, what noninterlace restore is about, and what I should've written about :p

[Fudoh]

Yeah, but we were writing about the noninterlace restore feature, which does, for example, 480i->240p.

me too, and I think it can help to go to 480p first, first because it allows you to apply the same processing for actual 480p output and second because it can help to get rid of filtering artefacts. When you capture 240p as 480i and double to 480p, you can - on the way - reduce to a vertical resolution of 240p as well, just to double back to 480p again in the next step. It helps.

If you first double the lines of the fields, and then throw away half of the doubled fields again, aren't we then simply back to my first post on this page?

Shifting them towards each other or not, in the end you have to output 240 lines in 1/60s. You only have access to 240 lines in 1/60s from the input signal's field.

so? You don't want or need more than those 240 lines if your original signal isn't really interlaced (meaning that it doesn't rely on the combination of two fields to create an image).

[6t8k]

Yeah, I agree doubling to 480p first helps to some degree. But I'm not sure whether it actually tackles the root cause of the bobbing issue (I described my understanding of it in my previous post), because it was said that the bobbing will be gone?

so? You don't want or need more than those 240 lines if your original signal isn't really interlaced (meaning that it doesn't rely on the combination of two fields to create an image).

That is what I was just thinking as well. Is it really that the "interlaced" lines of eligible games are not vertically offset against each other at all? I thought that would always be the case with interlaced video. "Fake interlace" :o

[Fudoh]

That is what I was just thinking as well. Is it really that the interlaced lines of eligible games are not vertically offset against each other at all? I thought that would always be the case with interlaced video.

both cases exist. There are titles which you can capture in their native 480i format, just turn the fields into frames and the offset will match, while in other cases each other field is shifted already, so you have to adjust for that in post (or during processing).

The reason why bob'ed 480i flickers in the first place is the existing offset between odd and even fields and because that offset is kept when displaying the 480p output. Totally makes sense for genuine 480i content, but is nonsense for titles that originally are 240p.

When applying bob to 240p material that's output in 480i, the first odd line gets mapped to line 1+2, while the first even one gets mapped to lines 2+3. To get a stable result from the same source material you have to map them both to the same output lines.

[6t8k]

Learning something once again, thanks a lot!

I would be guessing that it's mostly games that were originally presented in 240p, and got ports that output 480i, like G.Darius on the PS2 for example, where the fields can simply be turned into frames. Hence noninterlace restore, arguably.

[Fudoh]

only applies to very select titles. The ones on the Taito Memories compilations are quite heavily filtered and I'm not sure if the original line mapping is even intact. For those you'd definitely need to double first and then try to discard the filtered lines.

I can't think of too many titles that really work with bob + a matching field shift. The ones I use for bechmarking are Sengoku Blade and Dragon Blaze, both on the PS2.

[NormalFish]

The Metal Slug Anthology on PS2 is probably a good check for it, since (at least when patched with a hex editor) it runs without any filtering and gives a pixel-perfect image at 240p, but looks a bit of a mess at 480i.

[6t8k]

Meanwhile I had time to think a bit about this again, and visualize what was in the back of my mind when I was first posting about the noninterlace restore feature, because I couldn't help but sense that there must still be something dissonant between what was said here about the feature and my current understanding.

I'm convinced that the resulting video will bob vertically in ALM mode, because I think that it is, in fact, technically unfeasible to avoid this. Of course: if I'm still missing something, or if I'm arriving at the wrong conclusions, please don't hesitate to bring it up.

The last few posts at first created the impression for me that there exists an interlaced video signal where each field's constituent lines are not vertically offset against the lines of the previous and next fields (from the perspective of the full frame that was recorded/is generated, and is to be displayed). That is not the case. With interlaced video, the individual lines of all odd fields are always vertically offset by one line in relation to the individual lines of all even fields, and vice versa. This is true for all souces of interlaced video.


(source)

Even assuming that, for any given source, it could be the case that from the view of the full frame that was recorded/is generated, and is to be displayed, the lines would not be offset against each other, and it's just that the second half of the last line of field 'A' contains the first preequalization pulse of the next field, such that the sink thinks that the signal is interlaced and should be displayed as such – but then it would be displayed completely wrong on a CRT: it would bob like the OSSC's bob deinterlacing does on a digital display. A completely different, and much more visible kind of flicker than the traditional interlaced video flicker on CRTs. Could it be the case that the noninterlace restore feature specifically tackle sources that act like this? Does something like that even exist outside of tinkering/erroneous processing chains or outright software/hardware faults? At least I haven't ever seen anything like that.

I learned that there are games (ports) that introduce an additional line offset, namely, in relation to the video signal output by the originally released version of the game (which was subsequently ported). It's independent from the offset introduced from the output video signal itself being interlaced, and if it is there, it goes on top. But this aspect doesn't seem relevant to my point, which is about feeding interlaced video into the noninterlace restore feature, and obtaining an output video signal of half the vertical resolution as a result, as written by marqs. These basic parameters are not affected by any possible game/port-specific line offset being there or not.

In the light of this, as I understand it, the video signal resulting from use of the noninterlace restore in ALM mode will necessarily have to bob. An attempt to express what I mean:

You're outputting 240 lines in 1/60s. You only have access to 240 lines in 1/60s from the input signal's current field. Consequently, what you're outputting as one frame will have to look like this:


(For field 'A', as an example. In practice, a still frame deinterlaced like this will not look as garbled because the example divides the source material into a very low number of lines.)

For the next output frame, the OSSC Pro samples field 'B', the constituent lines of which are vertically offset by one line as compared to the lines of field 'A'. This means that while processing field 'B', we access a different region of the whole source frame, a region that doesn't overlap with the region we have access to when processing field 'A'. This means: the output video will bob vertically.

Internally line-multiplying the input field or not, you still only have access to the information contained within the current input field, and in the course of outputting frames with half the line-height of the input signal, you will have to throw away any copied information anyway. Furthermore, you can't make the bobbing disappear by shifting odd or even fields up or down X lines. The next output frame, as compared to the current one, will either look like this:



or like this:


(Sorry for the uneven alignment.)

In no case will the output video signal not be percieved as bobbing vertically.

What am I missing?

[nmalinoski]

Meanwhile I had time to think a bit about this again, and visualize what was in the back of my mind when I was first posting about the noninterlace restore feature, because I couldn't help but sense that there must still be something dissonant between what was said here about the feature and my current understanding.

I'm convinced that the resulting video will bob vertically in ALM mode, because I think that it is, in fact, technically unfeasible to avoid this. Of course: if I'm still missing something, or if I'm arriving at the wrong conclusions, please don't hesitate to bring it up.

The last few posts at first created the impression for me that there exists an interlaced video signal where each field's constituent lines are not vertically offset against the lines of the previous and next fields (from the perspective of the full frame that was recorded/is generated, and is to be displayed). That is not the case. With interlaced video, the individual lines of all odd fields are always vertically offset by one line in relation to the individual lines of all even fields, and vice versa. This is true for all souces of interlaced video.
...
In no case will the output video signal not be percieved as bobbing vertically.

What am I missing?

I might be mistaken, but the way I interpreted it is that the source signal is 240p, which is output as 480i, and deinterlacing should give you effectively that 240p line-doubled to 480p; from there, you could simply discard every other line and end up with the original 240p (or at least as close to it as possible).

Your visual aids look like they start with 480-line content instead of 240-line content, and that's why they look janky when you discard every other line.

[6t8k]

nmalinoski: but then again what is 240p content output as 480i? This?

Spoiler

Even assuming that, for any given source, it could be the case that from the view of the full frame that was recorded/is generated, and is to be displayed, the lines would not be offset against each other, and it's just that the second half of the last line of field 'A' contains the first preequalization pulse of the next field, such that the sink thinks that the signal is interlaced and should be displayed as such – but then it would be displayed completely wrong on a CRT: it would bob like the OSSC's bob deinterlacing does on a digital display. A completely different, and much more visible kind of flicker than the traditional interlaced video flicker on CRTs. Could it be the case that the noninterlace restore feature specifically tackle sources that act like this? Does something like that even exist outside of tinkering/erroneous processing chains or outright software/hardware faults? At least I haven't ever seen anything like that.

It would bob like crazy on a CRT, because you're alternatingly displaying picture information within lines where it doesn't belong. This does not happen with e.g. G.Darius or Dragon Blaze on the PS2, and I don't believe said scenario would apply here... but if it's indeed the case – against all odds – then I understand how line-doubling and discarding half of the lines again would work. The latter has already been written here and I wouldn't have posted if I wasn't still at odds with that premise being correct.

Of course, the visual aids I used are based on 480-line content, but the basics apply anyway, since we're still talking about a 480i video signal. If the above turns out being true, the difference would be that the content that's put onto field B's lines would be meant to be displayed on the same height as the content that's put onto field A's lines, as you touched upon. But many, many sinks would put it onto different heights regardless, because the signal would announce itself as being interlaced.

[maxtherabbit]

I would assume "240p output as 480i" would just be the same 262 lines sent twice in a row with the extra half line added at the end of each field to cause the display to interlace

in essence, "line doubling" the 240p but only showing half of the doubled lines on each field

[6t8k]

^

the same 1/60s frame in 240p is divided into two 1/60s fields in 480i, isn't it?

no, not at all, this would essentially cut the motion resolution into half. You can have perfectly fine 60fps, even for 2D titles, in 480i.

[maxtherabbit]

ok i give up then lol

don't actually even care about playing ports on ps2

[Fudoh]

That is not the case. With interlaced video, the individual lines of all odd fields are always vertically offset by one line in relation to the individual lines of all even fields, and vice versa. This is true for all souces of interlaced video.

the fact is irrelevant, when you consider the alignment of the lines on the SOURCE side of things. The offset is only introduced at the SINK's side due to the interlaced flag in the video stream.

Does something like that even exist outside of tinkering/erroneous processing chains or outright software/hardware faults? At least I haven't ever seen anything like that.

Think of the 480i to 240p conversion using the Extron RGB interfaces, where the display is tricked into displaying 480i as 240p just by altering the first line of video. The source signal isn't changed, nor is anything buffered. Just the flag gets changed and suddenly the CRT is displaying the odd and even lines on top of each other instead of alternating their position.

If you think of it like this, it's really up to the processor on WHERE to display each field.

This means: the output video will bob vertically.

Furthermore, you can't make the bobbing disappear by shifting odd or even fields up or down X lines. The next output frame, as compared to the current one, will either look like this:

That's the difference between a genuine 480i signal (like video material or hi-res video games) and 240p games that are accidentally ported in 480i (or by bad choices). For true 480i material the offset is supposed to be there, otherwise you're altering the original position of details. For 240p material though the offset is there "by mistake" and can be removed without causing (and EVEN REMOVING) any bob effect.

What am I missing?

for true 480i, nothing. But your example graphics don't show 240p material and that's why marqs calls this "noninterlaced RESTORE" and not a 480i to 240p CONVERSION. It's only meant to be applied to material that was supposed to be output in 240p in the first place. For bob-free conversion of TRUE 480i material to 240p you need a two step process with PROPER deinterlacing first and a 240p conversion next. It's like running a 480i signal through a DVDO and then into an Emotia.

[Xer Xian]

What am I missing?

The fact that, as Fudoh said, 240p games adapted to 480i are usually filtered. See pictures in the OP of this thread.

Those that are unfiltered, I guess that they simply didn't do it right? (actually, didn't do the wrong thing the right way - right thing woul've been keeping it 240p)

Even in that case, most CRTs wouldn't bob nearly like a digital panel would - consumer CRTs blended lines together to some extent.

[orange808]

Most of us already know, but PS2 Fantasy Zone Collection is a good test pattern to see all of this in action.

It has native 240p output, 480p, and 480i output. It also has an option to toggle 480i filtering on and off.

[FBX]

I was doing some calculations, and found that for 256 mode games (NES, SNES, Genesis 256 mode, etc.), it's possible to reach perfect signal aspect ratio correction at a size of 8 by 7 (2048x1680). Is this within the realm of something the OSSC Pro can do? Thankfully it's within the 4K range for 4K TVs if doable.

[marqs]

I was doing some calculations, and found that for 256 mode games (NES, SNES, Genesis 256 mode, etc.), it's possible to reach perfect signal aspect ratio correction at a size of 8 by 7 (2048x1680). Is this within the realm of something the OSSC Pro can do? Thankfully it's within the 4K range for 4K TVs if doable.

Even with reduced blanking, 2048x1680_60 needs pixel clock of almost 230MHz. That significantly exceeds max. input video clock spec of ADV7513 (165MHz) so I'm afraid it wouldn't work reliably, at least with all samples. The only dedicated TX chip with higher spec I'm aware of is SiI1136 (300MHz), but its programming guide is under NDA.

[Sirotaca]

Would it be possible to allow an interpolated non-integer scale on the horizontal axis in the pure/adaptive LM modes? That would allow aspect ratio correction without increasing the pixel clock, while still retaining most of the sharpness benefits of optimal sampling. For example, at a 6x vertical scale, 256-pixel NES/SNES/MD games would need a ~6.86x horizontal scale.

[6t8k]

But your example graphics don't show 240p material and that's why marqs calls this "noninterlaced RESTORE" and not a 480i to 240p CONVERSION. It's only meant to be applied to material that was supposed to be output in 240p in the first place.

I introduced them to set the stage, key aspects of it still apply – though I acknowledge that showing 480-line content in this context is not entirely on-topic and may confuse things more than help. I should've considered how to better represent "240p content output by a 480i video signal". To imagine the right thing, for a still frame, as shown by my visual aids, one has to envision that field 'A' contains exactly the same picture information as field 'B'. And for motion, field 'A' will contain the original 240p material's frame number X, while field B will contain 240p's frame number X+1 (generalization of the still frame case).

Think of the 480i to 240p conversion using the Extron RGB interfaces, where the display is tricked into displaying 480i as 240p just by altering the first line of video. The source signal isn't changed, nor is anything buffered. Just the flag gets changed and suddenly the CRT is displaying the odd and even lines on top of each other instead of alternating their position.

If you think of it like this, it's really up to the processor on WHERE to display each field.

Yes, this must be what's happening. I tested Dragon Blaze on a PVM 2053-MD (video, note that with YT's webplayer you can frame-step using the , and . keys), and was quite surprised to see the picture bobbing vertically by one line. When the gameplay is not moving, one can clearly see that the same picture information gets displayed within both field A and field B, which causes the observed bobbing. I was honestly not considering that option and would've thought that something like that would've been reason for the customer to return the game/think that something is broken. I guess I had never really paid attention to that aspect. On the other hand, I only had this game running on a consumer CRT before, so perhaps the bobbing isn't as pronounced on these, as Xer Xian wrote, which could be why this was never an issue in the first place. Now I'm looking forward to trying out the feature in combination with a good CRT!

And it also seems that I had a wrong understanding of how the OSSC's bob deinterlacing works, because I would've expected the picture to not bob when using it in Dragon Blaze's case. However, it does. My former understanding was that each field is doubled and each output 480p frame is simply started with the first line available from each input field – so the exclusive cause for the bobbing would have been that each field's constituent lines correspond to different, vertically offset areas out of the source material's frame.

But according to this and this (third line, I assume with odd/even you're referring to field numbers, not line numbers. the second line doesn't seem entirely correct then though), it makes sense again: it seems that the OSSC itself is offsetting every other field by one line, in addition to the above (but now I wonder why it's implemented like this, wouldn't not introducing any offset reduce bobbing for true 480i material and completely eliminate it for 240p output as 480i, as discussed? I don't expect an answer, leads too far here.).

Xer Xian: not sure why a filter would necessarily matter in this case. As I understand it, Dragon Blaze on the PS2 doesn't employ any filtering, right? Still, everything discussed here applies to it.


Anyway, I think I understand most key aspects reasonably well now, and hope that my 'excursus' turns out being helpful in some way for somebody else too. Thank y'all for helping me get on the right track ^^;

[L8RSK8R]

Hey, sorry if this is off topic but I have an issue that is semi related to the OSSC.
I recently just got my hands on a DVDO VP50 to use in conjunction with my OSSC, due it taking care of the OSSC's weaknesses. The only issue being that I don't know how to work the VP50 by itself. I plugged it in and managed to get everything setup enough to have the VP50's menu on my screen, but when I turn on my connected PS2 the screen goes black and nothing happens. I'm not really sure what the problem is and there's no real guide on how it's suppose to be setup, so it's possible I may just not have something right. I'd like to mention this is just the VP50 and PS2, I did try connecting the OSSC to with an HDMI to see if something different would happen but the problem persisted. If someone could help me out with how this is supposed to be setup I would really appreciate the help!

[Fudoh]

The vertical offset between the doubled fields is a design decision. I know three different settings that have actually been used on processors in the wild and which produce visibly different results, both on true 480i material and on "fake 480i" material (like Dragon Blaze). The XRGB-3 has zero offset, the OSSC uses a medium offset and the XPC-4 and GBCControl use a large offset.

Here's an old shot from my XPC-4 review: http://retrogaming.hazard-city.de/xpc_480i.jpg
You can see the thick (double pixel) "shadow" outlines on top and bottom of all edges, while on the OSSC you only get a single "ghost" line.

On a processor without manual offset control (none so far, Retrotink coming up) the medium settings makes the most sense, since you should assume that most 480i sources are true 480i material. The large offset on the XPC-4 and GBSControl make it hard to watch, even for true 480i material, while the zero offset method on the XRGB gives a more low-res impression of true 480i material than you would expect from a regular bob'ing processor.

What we discuss here (no bob'ing effect on Dragon Blaze and similar titles) is really a side effect. There only very few titles to profit from this.