Will OSSC Pro handle 480i better than Framemeister

[XSync-1]

From what I understand now, it seems that the Framemeister’s one saving grace when compared to the original OSSC is its ability to handle 480i better than any other device on the market. Will the OSSC Pro be able to beat the Framemeister at this particular task? Also, not to change the subject, but will the OSSC Pro have S-Video support?

[Fudoh]

t seems that the Framemeister’s one saving grace when compared to the original OSSC

that's really not doing the FM any justice. With 240p content the OSSC is only better when you dive into the optimal timings, which is a mood point if your setup is aimed at capturing and you're using a codec that uses color subsampling. The codec will then eventually create very similar artefacts to what you would get by generic sampling (or the FM's sampling) in the first place. Optimal timings also aren't very practical when it comes to systems that output multiple resolutions.

The OSSC Pro has the potential to get very good deinterlacing, but keep in mind that this (=creating such a high level quality deinterlacing algorithm in FPGA) has never been done on a community-based project before, so nobody can tell you how this will eventually work out.

The O.Pro won't have s-video support out of the box.

[fernan1234]

With 240p content the OSSC is only better when you dive into the optimal timings

Nah not really though, although you can fine tune the Framemeister to be close to as good as the OSSC with the latter on the default generic modes. But if you compare both out of the box, configuration free, the OSSC wins hands down for 240p (and this is not even considering the way better scanlines options, which subjectively greatly improve a scaled/line-multiplied 240p picture).

I have a good amount of belief in the potential for the OSSC to provide the best deinterlacing eventually, precisely because it is community-based and will receive contributions from people who care, which cannot be said of almost all commercial products.

[NewSchoolBoxer]

I don't own these devices. Open to corrections or clarification.

Framemeister uses a frame buffer and OSSC does not to stay in "no lag" territory. The buffer is an enormous and insurmountable advantage in de-interlacing 480i to 480p and above. I read here that OSSC uses bob deinterlacing, a simple but fast technique where a buffer is optional. FM seems to use both weave and motion-adaptive de-interlacing, both of which require a buffer: viewtopic.php?f=6&t=33450&start=10200

Just not possible for a no buffer / no lag de-interlacing to beat one with a buffer that is of the same build quality and not cheap off the shelf generic. Buffer also opens up the ability for image stacking. My iPhone 8 has an "Auto HDR" option that blends three separate exposures into a single photo. This is image stacking and reduces the noise by about sqrt(3) or 70%. Is diminishing returns but mathematically easy to do if you have the time. How Hubble Telescope works to give a clear image by averaging out the Gaussian noise.

No, OSSC Pro be better at 480i but it won't have half a frame of lag or so. I don't perceive 1-2 frames. FM issue to me is it's not made anymore. Existing supply going to run out.

I see 240p brought up. As a streamer I never want scanlines and average gamer today doesn't know what they are. Sure, OSSC Pro scanline features would be a selling point to hardcore niche and most of us are hardcore by virtue of reading about video processing on the internet and being willing to spend big money on these products.

[orange808]

It's frustrating that Altera uses yadif in their IP, but they ignore their obligations. At the very least, yadif is licensed under LGPL, but some of the dependencies fall under GPL. It's unfortunate that FFmpeg cannot adopt a single license.

Either way, we should have an open source implementation available already. I don't believe their modifications would allow them to create a closed source port. The yadif code should be already be available--even if their additional IP remains closed source. LGPL isn't MIT.

https://github.com/michaelni/FFmpeg/blo ... LICENSE.md

[Extrems]

Most of the GPL code was inherited from MPlayer.

[Fudoh]

And you consider yadif is good solution? On my tests (more than a decade ago) it couldn't hold up to any of the proper hardware deinterlacers back then.

[orange808]

And you consider yadif is good solution? On my tests (more than a decade ago) it couldn't hold up to any of the proper hardware deinterlacers back then.

I think yadif would be a convenient place to start, if there was already an implementation available (unfortunately, there isn't). A better solution would need to take a hybrid approach.

[NormalFish]

Framemeister uses a frame buffer and OSSC does not to stay in "no lag" territory.

The OSSC does not have a framebuffer, but the OSSC Pro does.

[Sumez]

I don't know anything about deinterlacing, so this might sound stupid. But I'll ask anyway.

If a 480i game is running 30fps to avoid interlacing artifacts, wouldn't "one" frame (ie. half of an interlaced picture) of lag be completely acceptable, or even desirable? If you need two frames to form a full image, you'd only need to buffer the first half.

That said, I seem to recall a lot of PS2 games at least sending new frames at 60fps causing a lot of visible interlacing when something moves fast? Are there any common deinterlacing methods that always repeats the previous frame's scanlines combined with the current frame's, at a 60fps rate - essentially using a frame buffer but without any footage lagging behind? While this doesn't sound "ideal", it feels closer to the effect you get from a CRT monitor.

[6t8k]

If a 480i game is running 30fps to avoid interlacing artifacts, wouldn't "one" frame (ie. half of an interlaced picture) of lag be completely acceptable, or even desirable? If you need two frames to form a full image, you'd only need to buffer the first half.

In interlaced video, with most consoles/games, one frame consists of two (interwoven) fields. So a game that renders its content in 30 frames per second (=frame rate) outputs 60 fields per second (=(vertical) refresh rate) when interlaced video is output - to get one frame, you would have to ingest two fields (two fields form one "full image"). If you only buffer a few lines instead of a frame, then you can only employ simpler deinterlacing methods like line doubling/bobbing, with a framebuffer on the other hand, you can employ more sophisticated deinterlacing methods like motion adaptive deinterlacing. The choice depends on your needs and tastes. I hope that somehow helps and I haven't completely talked past what you meant? ^^"

That said, I seem to recall a lot of PS2 games at least sending new frames at 60fps [that's new content in each new field at 60Hz, but still 30 frames per second, Ed.] causing a lot of visible interlacing when something moves fast? Are there any common deinterlacing methods that always repeats the previous frame's scanlines combined with the current frame's, at a 60fps rate - essentially using a frame buffer but without any footage lagging behind? While this doesn't sound "ideal", it feels closer to the effect you get from a CRT monitor.

Weave deinterlacing is a common flavor of field combination deinterlacing, which does this.

(it can be confusing that 'fps' can be ambiguous and that the number in '60i' refers to a field rate, while the number in '30p' refers to a frame rate. You can specify a frame rate explicitly by using a forward slash like so: 480i/30 (EBU notation), 480i/30 = 480i60)

[Fudoh]

If a 480i game is running 30fps to avoid interlacing artifacts, wouldn't "one" frame (ie. half of an interlaced picture) of lag be completely acceptable, or even desirable? If you need two frames to form a full image, you'd only need to buffer the first half.

yeah, in theory that's easy. You buffer the first field (of the full frame) and combine it line by line with the fields from the second field. The problem here is cadence and how it can change and if the processor doesn't keep a close eye on it it can suddenly start combining the second field of a frame with the first field of the next one.

Funny enough deinterlacing MOVIES in PAL format (25fps over 50i) is basically the same as deinterlacing games in 30fps over 60i (these are 2:2 cadences) and that's considered way harder than deinterlacing NTSC based movies with their unique 3:2 cadence (24fps over 60i).

If you let a motion adaptive deinterlacer made for 60fps run wild at a 2:2 cadence, the result looks worse than actually detecting the cadence and applying a much simpler deinterlacing method (weave the two matching fiels and repeat the resulting frame).

[orange808]

Now, correct me if this isn't the target, Fudoh:


For pixels in motion:
We want to line double the current frame and next frame. Then, we want to buffer a per-pixel motion adaptive frame based on the last, current, and next frames.

We have three "working" frames: two line doubled frames and one motion adaptive frame.

Then, we want to interpolate our buffered working frames, double the frame rate of the video fields (~120fps for NTSC), insert the interpolated frame, and display the motion adaptive frame.


For stationary pixels:
We just weave the fields. It's all got to be pixel based. (Pixels meaning samples of course)

[Fudoh]

Then, we want to interpolate our buffered working frames, double the frame rate of the video fields (~120fps for NTSC), insert the interpolated frame, and display the motion adaptive frame.

I didn't exactly lose you here, but I can't say that I have any idea how you came to that conclusion.

[orange808]

Then, we want to interpolate our buffered working frames, double the frame rate of the video fields (~120fps for NTSC), insert the interpolated frame, and display the motion adaptive frame.

I didn't exactly lose you here, but I can't say that I have any idea how you came to that conclusion.

I like the potential of algortithms that double the "frame rate" and something like that is possible on an FPGA. Really great machine learning in real time is out of reach.

Do you think bob and weave are the only tools required? Without machine learning, I'm not so sure.

[headlesshobbs]

I was given a thought if the original ossc was good enough to do bob interlace, then it's possible the pro will be able to do a much better job at just screening full interlaced mode to the progressive signal that can be thrown out in the same manner. That way it shouldn't look at all different from trying to run it on your pc crt in x3 pass thru mode.

De-interlacing has always been confusing to me to think there should be only one method of displaying it out. I'm note sure if fields were meant to be read top to bottom, but any case where the reverse is true or other tricks I don't know of are beyond me. Would there be a page talking about different kinds of de-interlace somewhere?

[fernan1234]

De-interlacing has always been confusing to me to think there should be only one method of displaying it out. I'm note sure if fields were meant to be read top to bottom, but any case where the reverse is true or other tricks I don't know of are beyond me. Would there be a page talking about different kinds of de-interlace somewhere?

Yeah I also don't "get" the point of deinterlacing either, as long as there is a way to represent interlaced material with fidelity. And there is. The kings of video and broadcast, Sony, have been using it for years on their professional and broadcast monitors, up to this day with the latest BVM-HX310--albeit only for 1080i, support for SD signals is not documented officially, and I don't know anyone fortunate enough to own one and do tests.



Some of their other BVMs still officially support interlaced SD signals too, and all of the prior OLED and LCD BVM and PVMs did also. It looks pretty much like bob line doubling with black scanlines, and is extremely effective at simulating how interlace ought to look like on a CRT. IMO this is the only way that interlaced content should be displayed on flat panels in a way that is respectful to the original content.

I don't know of any other maker besides Sony that includes this feature on their professional monitors. And of course no consumer set ever does. Maybe some early LCDs and Plasmas did, but now no one else seems to care about the real look of interlaced video.

There are currently three retro game devices that can achieve a similar result, that I know of: OSSC, GBSControl, and RT2X.

[orange808]

How would you go about upscaling 480i without deinterlacing it first? What would it look like after you upscaled it?

[6t8k]

@Sumez: to explain my reply to your third paragraph in more detail, I meant weave deinterlacing from Xi to Xp (e.g. 60i -> 60p). Like so:

weave(BlackDummyField, Frame1FieldA), weave(Frame1FieldB, Frame1FieldA), weave(Frame1FieldB, Frame2FieldA), weave(Frame2FieldB, Frame2FieldA) ... or, depending on when you start:
weave(BlackDummyField, Frame1FieldB), weave(Frame2FieldA, Frame1FieldB), weave(Frame2FieldA, Frame2FieldB), weave(Frame3FieldA, Frame2FieldB) ...

You push the current field out as soon as possible while using the previous field, which is buffered, for the other half of the output frame. This buffer only "looks back".
Cadence detection is not applicable here and an implementation incurs essentially no latency (for all practical intents and purposes). The PS1Digital for example uses this variant of weave deinterlacing and has been measured by Bob of RetroRGB to have about 2ms of latency in weave mode [1] [some weave footage].

This is in contrast to weave deinterlacing from Xi to (X/2)p (e.g. 60i -> 30p). Like so:

weave(Frame1FieldA, Frame1FieldB), weave(Frame2FieldA, Frame2FieldB), weave(Frame3FieldA, Frame3FieldB), weave(Frame4FieldA, Frame4FieldB) ... or, if the cadence detection goes awry:
weave(Frame1FieldB, Frame2FieldA), weave(Frame2FieldB, Frame3FieldA), weave(Frame3FieldB, Frame4FieldA), weave(Frame4FieldB, Frame5FieldA) ...

This can avoid combing with frame-rendered games depending on how well cadence detection works, but incurs one field/half a frame of latency, as you need to buffer one field first before you can weave it together with the next one, forming an output frame.

With field-rendered games (your third paragraph), cadence detection is not needed as a new game state gets drawn every field.

[Sumez]

I hope that somehow helps and I haven't completely talked past what you meant? ^^"

It feels like you did, not sure. I wasn't talking about buffering a few lines, or a full frame, but buffering the complete first field, and then using that buffer while outputting the second field "without" lag. So you only get "half a frame" of lag, in terms of the functional framerate (30fps).

Your second posts hits exactly both of the things I was talking about though. Thanks for clearing up the terminology for me.

yeah, in theory that's easy. You buffer the first field (of the full frame) and combine it line by line with the fields from the second field. The problem here is cadence and how it can change and if the processor doesn't keep a close eye on it it can suddenly start combining the second field of a frame with the first field of the next one.

I understand that. But don't all deinterlacing methods face this exact challenge? What is the typical measure against it? Buffering three full fields to "find the best one"? :S

[orange808]

Cadence detection is not applicable here and an implementation incurs essentially no latency (for all practical intents and purposes). The PS1Digital for example uses this variant of weave deinterlacing and has been measured by Bob of RetroRGB to have about 2ms of latency in weave mode [1] [some weave footage].

It looks like RetroRGB is discarding half the fields. In theory that will cut the effective frame rate in half and double the display latency, right?

Edit: Why not use a geniune deinterlacer if you're already investing a frame of latency?

[strayan]

Seems like a good time to link to this option (weave plus a 1pixel blur):

viewtopic.php?p=1415657&sid=39b4e6ecee4 ... 2#p1415657

Stills: https://imgur.com/a/GEv4B7n

[Fudoh]

Seems like a good time to link to this option (weave plus a 1pixel blur):

this gives you ghosting (blending effects that increase in length the faster the motion gets).

The kings of video and broadcast, Sony, have been using it for years on their professional and broadcast monitors, up to this day with the latest BVM-HX310--albeit only for 1080i

As you mentioned, that's really nothing different than what the XRGB-3, the OSSC and the Retrotink offer by enabling field based scanlines for interlaced material.

[6t8k]

Cadence detection is not applicable here and an implementation incurs essentially no latency (for all practical intents and purposes). The PS1Digital for example uses this variant of weave deinterlacing and has been measured by Bob of RetroRGB to have about 2ms of latency in weave mode [1] [some weave footage].

It looks like RetroRGB is discarding half the fields. In theory that will cut the effective frame rate in half and double the display latency, right?

I suppose you're referring to the section where he tries weave in combination with scanlines?

Blacking out every other source field or overlaying black lines (both would work, it's an implementation detail) corresponds to replacing one parameter of weave() with that. First weave...-Line from above:
weave(Blackness, Frame1FieldA), weave(Blackness, Frame1FieldA), weave(Blackness, Frame2FieldA), weave(Blackness, Frame2FieldA) ...

It becomes clear that depending on whether you choose odd or even scanlines, the odd or even fields are lost, and the remaining field of each frame is output twice. This halves the effective frame rate, yes, but latency is not increased technically: the fields you still get to see you're not seeing delayed compared to before. It will of course still feel less responsive when playing.

[strayan]

Seems like a good time to link to this option (weave plus a 1pixel blur):

this gives you ghosting (blending effects that increase in length the faster the motion gets).

It absolutely does cause ghosting. I tried to capture that in the stills. Far more tolerable than combing from my perspective.

[Fudoh]

It absolutely does cause ghosting. I tried to capture that in the stills. Far more tolerable than combing from my perspective.

yes, that's right. But do we really want to stop there for a brandnew $500 device in 2021? Yes, you can argue about the minimized delay, but is this really worth saving a single frame of lag? I could appreciate it as an available option, but I'm not sure if too many available deinterlacing methods would help the more novice users.

[fernan1234]

The kings of video and broadcast, Sony, have been using it for years on their professional and broadcast monitors, up to this day with the latest BVM-HX310--albeit only for 1080i

As you mentioned, that's really nothing different than what the XRGB-3, the OSSC and the Retrotink offer by enabling field based scanlines for interlaced material.

I didn't know the XRGB-3 did this also, that's cool. And like I said GBSControl can also do it when set to bob.

Too bad that all of these only can do this for SD interlace content though. The Sony monitors also do it for HD. 1080i content (lots of blurays, etc.) also look perfect with this interlace mode. I'm hoping that the OSSC Pro will be able to do it too since it will support 1080i output.

[Fudoh]

The Sony monitors also do it for HD. 1080i content (lots of blurays, etc.) also look perfect with this interlace mode

The difference is subtle, especially since my BVM OLED is only 25" and not 30". On the Sonys the idea behind is to present the material as close to the original as possible. For an end-user I don't think that's this important.

But of course I'm sure that the OSSC Pro will have this feature available for 1080i - should you desire to use it.

[fernan1234]

The difference is subtle, especially since my BVM OLED is only 25" and not 30". On the Sonys the idea behind is to present the material as close to the original as possible. For an end-user I don't think that's this important.

On the 25'' OLEDs as well as on the old 32'' LCDs I've seen it makes a lot of difference to my eye, makes it a must for me (though of course the I/P conversion these do is also stellar).
It's true that most end-users don't think this is important, but I'd say that's mainly because they have never seen the true look of HD interlaced in their entire lives. I bet many would be converted if they actually could see it. I know I was!

The OSSC Pro supporting this would make having to own one of those expensive or old monitors much less necessary, for this particular purpose at least.

Edit: actually on the LCDs which have 120hz panels it feels even more effective, with less flicker appearance even for 2X or aspect corrected SD interlaced content, so there's potential for new consumer 120hz panels to do really well with this if the OSSC Pro supports it.
Another big plus of this kind of interlace emulation is that, although unintended, the alternating black lines serve to reduce eye-tracking blur on sample-and-hold displays, reducing the need for intense black frame insertion on consumer sets.

[orange808]

As a follow up, I know I've posted this elsewhere, but: I had better luck bob deinterlacing (line doubling) flicker filtered 480i to 960p and adding blank scanlines with the OSSC to mask fields. Then I downscaled it 240p. The scaler was forced to average the blank lines away. Unfortunately, it leaves a checkerboard artifact in places where there were gradients. I still prefer it over dropping half the frames.

I suppose I could try some screen grabs at 240p. I can't upscale the video properly because the OSSC is already engaged earlier in the chain. I need to fix my Gonbes.