bobrockso5 wrote:Modern TVs process native-res content in the same processing path they use for processing lower-res content. So yes, essentially upscaling is lagless, because 1080p and 4K on the same set will have the same amount of lag.
And modern consoles also use the same processing path for all content, so upscaling is equally lagless there (because even at native resolution output you can't avoid it having a framebuffer).
If you want the lowest lag, you should always avoid devices you don't need. The OSSC is an exception for 240p content, because 240p content (and only 240p content) is often seriously mishandled by modern displays.
bobrockso5 wrote:Modern TVs process native-res content in the same processing path they use for processing lower-res content. So yes, essentially upscaling is lagless, because 1080p and 4K on the same set will have the same amount of lag.
And modern consoles also use the same processing path for all content, so upscaling is equally lagless there (because even at native resolution output you can't avoid it having a framebuffer).
If you want the lowest lag, you should always avoid devices you don't need. The OSSC is an exception for 240p content, because 240p content (and only 240p content) is often seriously mishandled by modern displays.
It's bigger than 240p.
480i deinterlacing is often done badly. 480p scaling is usually accompanied by a filter that makes games look blurry.
There are exceptions, but most new displays will struggle with any input "below" 720p.
Guspaz wrote:A 1080p to 4K scan line doubler is simultaneously not possible with affordable FPGAs today, and also way beyond what the Wolf Edition is planned to be, a firmware-compatible alternate take on the OSSC...
It's also an enormous amount of work just to upscale 1080p to 4K, something that will be an incredibly small difference from the lagless upscaling done by a 4K display or console.
Plans change.
And displays have their own upscalers and they are not lagless. Some add like 5 frames of lag which is why if this only does 1080p to get it to 4k a high end external upscaler with minimal lag would be the way to go. Internal upscalers differ in the same line of displays based on the size of the display sometimes or just randomly get swapped out based on affordability and the production run. It is maddening trying to predict what hardware you will get inside a display and it runs the gambit from amazing to garbage seemingly at random.
Console upscalers are also not lagless. Anything with a framebuffer = at least 1 frame of lag. Now naturally console internal upscaling is usually done very well because it is designed for that system but it still adds lag.
And yea it looks like 4k at 60fps isn't feasible so 1080p with an additional upscaler looks like the best we could expect from this gen assuming the dev goes for it.
Brand new factory OEM 4k display scalers will add about one or two tenths of a millisecond when scaling progressive signals to 4k. That is virtually nothing.
Displays aren't laggy because of the scaling. New displays consistently test within a few tenths of a millisecond with a native 4k input signal--versus lower progressive signals. The problem is the display panels (themselves) and the hardware that drives the panels, not the scaling. Slow displays are always slow, regardless of the input signal resolution.
The second issue is quality. Many OEM scalers use a filter to smooth out low resolution inputs. Old games just look blurry.
Wolf_ wrote:And is that true for game mode as well? You would think that direct output that requires no processing would be faster than processing that requires a buffer. It makes no sense to enforce a buffer and lag on content that doesn't need it.
When it's cheaper and easier to route all signals the same way, and when 99.9% of your customer base doesn't know enough to care, it starts making a lot of sense.
I believe some Vizio's offer a single HDMI input that bypasses some processing. I don't remember any lag statistics though. It still scales.
Go look at the latency ratings from rtings, where they typically measure both 1080p and 4K input. Compare the tests with the same parameters, such as 1080p60 to 4K60, or 1080p60 4:4:4 to 4K60 4:4:4. While there were a very small number of displays that had an appreciably higher latency with 1080p input, the vast majority of them were roughly equivalent, with quite a few offering *lower* input latency with 1080p.
bobrockso5 wrote:Modern TVs process native-res content in the same processing path they use for processing lower-res content. So yes, essentially upscaling is lagless, because 1080p and 4K on the same set will have the same amount of lag.
And modern consoles also use the same processing path for all content, so upscaling is equally lagless there (because even at native resolution output you can't avoid it having a framebuffer).
If you want the lowest lag, you should always avoid devices you don't need. The OSSC is an exception for 240p content, because 240p content (and only 240p content) is often seriously mishandled by modern displays.
It's bigger than 240p.
480i deinterlacing is often done badly. 480p scaling is usually accompanied by a filter that makes games look blurry.
There are exceptions, but most new displays will struggle with any input "below" 720p.
I was talking in terms of lag.
480i is equally bad as 240p there, but you're going to end up with lag if you want 480i to look decent no matter what you do.
Guspaz wrote:Lagless deinterlacing is possible, the OSSC does it. Bob deinterlacing may not look the greatest, but it can be done without any lag.
I assume that the result cuts in half the framerate, doesn't it?
I mean, if I play a game that runs at 480i60, it would run at 480p30 after deinterlacing?
Do you mind if I ask you to explain this? It sounds interesting
NTSC consumer cathode ray tube televisions were designed to draw about 253 lines in 16 2/3 (aka 16.666..) ms.
60 frames * 16.666ms = 1000ms = 1 second
480i has 525 lines to draw. To draw them at 60 frames per second, the television needs to draw 525 lines in 16 2/3 ms, but the television cannot draw more than 252 lines. Therefore, 480i at 60 frames per second cannot exist.
480i draws half of the lines of each frame in each pass. Each pass is called a "field". Two fields is a frame. Each field takes 16 2/3 ms to draw. 60 fields is 30 full frames. So, 480i is about 30 frames per second.
orange808 wrote:So, 480i is about 30 frames per second.
You make it seem like the OSSC outputs 480i60 as 480p30. Both OSSC and Framemeister deinterlace 480i to 60fps.
It's a paradox isn't it?
Have you ever made a simple animation with a paper "flip book"?
What's the difference between: drawing 30 pictures and flipping the pages at regular speed AND drawing each of the 30 pictures twice (60 pictures) and flipping the pages at twice the speed?
Drawing each of the individual 30 frames twice yields 60 frames. Only, there aren't 60 unique frames there--just 30 frames doubled.
paulb_nl wrote:There are 60 unique frames in 480i. The 60 fields are taken from 60 frames.
Exactly. each field of 60i interlaced video signal is from a separate moment in time, so to display it properly at the full/original motion it needs to be deinterlaced (with motion-adaptive deinterlacing) to 60 frames per second.
If you deinterlace it to 30 fps you loose half of the motion information, making the video look jerky/stuttering.
Umm, no offense, but if you're going to try to boil down complicated issues, please make sure you understand the thing you're trying to boil down. Nrg and paulb_nl are correct, 480i60 involves 60 distinct fields taken at 60 different points in time: this is why deinterlacing is so hard, otherwise you could just combine two fields into a frame for perfect deinterlacing every time. While it may not be directly the subject of this thread, it is important to correct these sort of inaccuracies when they occur so that false information is not spread as common wisdom.
You may be confusing a telecine (converting a 24FPS video to a 60i video), which does involve a limited number of progressive frames being split up into interlaced fields, which can be reversed to reconstruct the progressive frames if you align the inverse telecine to the pattern used for the original telecine (it's an uneven repetition). However, a telecine is purely used for film content, and has no real relevance to gaming.
Hi folks. I'm still working on the Wolf whenever I get time. I did a lot of hours this weekend on the schematic. I keep adding stuff then tearing it back out. I was trying large changes that ultimately seemed unwise.
Two examples :
I wanted to add a TVP5146M2 for composite video and S-video. After doing the schematic work I came across a sentence in a different document that said 480i input. It is unclear if it can process 240p since it only mentioned 480i.
Another example of lost time is I drew up all input connectors doubled. So there would be 2 VGA, 2 SCART, 2 YPrPb. Everything looked good until the SOG needed to connect to the video encoder and I realized things were MUX in such a way that there are not enough SOG inputs.
These are amature oversights and cost a lot of time.
I'm in the process of making the schematic closer to Marqs reference so I can have something known to work.
There is one big difference planned for this next revision. The 144 pin FPGA is switched to a 256 pin BGA. The additional pins will go to a connector or cardedge. This will create a OSSC dev board that allows daughter boards to be tried. If a daughter board is a success then it can be designed into the base later.
This seems like a smart direction because it gives a working base with the ability to prototype new ideas.
You could always try prototyping with the TVP5146M2 to see if it works with 240p.
Kevtris indicated that he favours PCIe sockets for edge connectors (the physical standard, not the protocol). They're extremely common (and thus cheap and easily available), can be had in vertical, right-angle, or edge mount, are keyed for correct orientation, and are available in a variety of different pin counts: 36 (1x), 64 (4x), 98 (8x), and 164 (16x).
becker wrote:
I wanted to add a TVP5146M2 for composite video and S-video. After doing the schematic work I came across a sentence in a different document that said 480i input. It is unclear if it can process 240p since it only mentioned 480i.
Another example of lost time is I drew up all input connectors doubled. So there would be 2 VGA, 2 SCART, 2 YPrPb. Everything looked good until the SOG needed to connect to the video encoder and I realized things were MUX in such a way that there are not enough SOG inputs.
These are amature oversights and cost a lot of time.
I'm in the process of making the schematic closer to Marqs reference so I can have something known to work.
There is one big difference planned for this next revision. The 144 pin FPGA is switched to a 256 pin BGA. The additional pins will go to a connector or cardedge. This will create a OSSC dev board that allows daughter boards to be tried. If a daughter board is a success then it can be designed into the base later.
This seems like a smart direction because it gives a working base with the ability to prototype new ideas.
Very nice ideas Seems like here comes a high end version of the OSSC.
If you switch to a BGA packaged FPGA, have you thought about using a FPGA with SoC?
This would overcome the code space limitation of the NIOS II which is almost full at the moment.
borti4938 wrote:
Very nice ideas Seems like here comes a high end version of the OSSC.
If you switch to a BGA packaged FPGA, have you thought about using a FPGA with SoC?
This would overcome the code space limitation of the NIOS II which is almost full at the moment.
That is interesting. I did not know the cpu emulator was the bottle neck. I looked up Cyclone V SoC and the smallest package is 484 BGA 0.8mm pitch. It is intimidating. I have not done a board that needed more than four layers. Maybe this can be revisited later. I still haven't made a working base model.
I'm not sure how possible this would be given your lack of coding inclination but one major issue of the ossc is that as a result of having no buffer signals get passed on at the exact sync they are output at and many of the consoles that output offspec syncs have problems on digital displays. For those consoles which don't display well on modern displays it would be amazing to have an optional buffer that would standardize the sync to a whole number so you don't get something like 59.9fps but instead get 0.9 fps of delay and 59 fps output. This would increase the compatibility of the ossc with gaming focused displays that can accept variable fps to probably 100%.
borti4938 wrote:If you switch to a BGA packaged FPGA, have you thought about using a FPGA with SoC?
Maybe an external microcontroller is another option? As far as I know the SoC-FPGA-combo chip feature feature quite powerful processors which would be way oversized for the OSSC's UI unless you want to add software video processing features.
For those consoles which don't display well on modern displays it would be amazing to have an optional buffer that would standardize the sync to a whole number so you don't get something like 59.9fps but instead get 0.9 fps of delay and 59 fps output. This would increase the compatibility of the ossc with gaming focused displays that can accept variable fps to probably 100%.
something like 59Hz can't be displayed on most displays. NTSC standard is 59.94Hz. VESA is 60.00. Anything in between these two is usually fine.
If you add a frame buffer you gain a lot of things (like overscan control, free scaling, massively increased compatibility), but you also add a little lag. And you need to look into a proper scaling engine (which shouldn't be too hard) and of course you have to deal with the framerate conversion. The OSSC's output is locked to the input refresh rate. If you unlock that you have to somehow convert the incoming refresh rate to the output refresh rate. Many processors CAN do that (Framemeister) or enforce it anyway (many home theater scalers), but it's never considered a good thing and should only be used to increase compatibility when abosolutely necessary (e.g. for capturing).
For those consoles which don't display well on modern displays it would be amazing to have an optional buffer that would standardize the sync to a whole number so you don't get something like 59.9fps but instead get 0.9 fps of delay and 59 fps output. This would increase the compatibility of the ossc with gaming focused displays that can accept variable fps to probably 100%.
something like 59Hz can't be displayed on most displays. NTSC standard is 59.94Hz. VESA is 60.00. Anything in between these two is usually fine.
If you add a frame buffer you gain a lot of things (like overscan control, free scaling, massively increased compatibility), but you also add a little lag. And you need to look into a proper scaling engine (which shouldn't be too hard) and of course you have to deal with the framerate conversion. The OSSC's output is locked to the input refresh rate. If you unlock that you have to somehow convert the incoming refresh rate to the output refresh rate. Many processors CAN do that (Framemeister) or enforce it anyway (many home theater scalers), but it's never considered a good thing and should only be used to increase compatibility when abosolutely necessary (e.g. for capturing).
If you use a gaming display then the displays are designed to accept whatever the gpu can output which has frames go up and down based on what is going on in the game and what setting your graphics are at. As a result they can pretty much accept any fps that is a whole number.
If you use a gaming display then the displays are designed to accept whatever the gpu can output which has frames go up and down based on what is going on in the game and what setting your graphics are at. As a result they can pretty much accept any fps that is a whole number.
Where did you pick that up? You don't need integer fps. If you set your GPU to what's called 59Hz in the GPU settings, you get 59.94Hz. That's to allow video editing in a standard refresh rate without the need to display at a forced VESA timing.
Also of course that applies to PCs with the proper GPU only. We don't have that tech for non-PC gaming yet, nor do we have the connections to support it.
Most video game system will display fine through the OSSC on modern TVs. The most critical ones are the Neo Geo systems (MVS at 59.15Hz). At that refresh rate you either don't get a picture or your TV will perform a framerate conversion. Lower than that and a black screen is pretty much guaranteed.
If you use a gaming display then the displays are designed to accept whatever the gpu can output which has frames go up and down based on what is going on in the game and what setting your graphics are at. As a result they can pretty much accept any fps that is a whole number.
Where did you pick that up? You don't need integer fps. If you set your GPU to what's called 59Hz in the GPU settings, you get 59.94Hz. That's to allow video editing in a standard refresh rate without the need to display at a forced VESA timing.
Also of course that applies to PCs with the proper GPU only. We don't have that tech for non-PC gaming yet, nor do we have the connections to support it.
Most video game system will display fine through the OSSC on modern TVs. The most critical ones are the Neo Geo systems (MVS at 59.15Hz). At that refresh rate you either don't get a picture or your TV will perform a framerate conversion. Lower than that and a black screen is pretty much guaranteed.
You can't just set your gpu to 59fps, you get whatever it can output. Sometimes it is the max the monitor can take be it 120fps or even 140fps or sometimes it is 5 or 1 fps if you generate some insane explosion with all the physics.
of course you can. You can enforce any timing your GPU *AND* monitor supports.
you get whatever it can output.
you're talking games that are supposed to run that way. Your desktop doesn't and so do a trilion of games.
Sometimes it is the max the monitor can take be it 120fps or even 140fps or sometimes it is 5 or 1 fps if you generate some insane explosion with all the physics.
you're talking in-game rendering performance. That's not necessarily coupled to the GPU's output. Even on GSYNC or Freesync it's only within a certain range.
of course you can. You can enforce any timing your GPU *AND* monitor supports.
you get whatever it can output.
you're talking games that are supposed to run that way. Your desktop doesn't and so do a trilion of games.
Sometimes it is the max the monitor can take be it 120fps or even 140fps or sometimes it is 5 or 1 fps if you generate some insane explosion with all the physics.
you're talking in-game rendering performance. That's not necessarily coupled to the GPU's output. Even on GSYNC or Freesync it's only within a certain range.
Is this going anywhere console related ?
It has always been console related. Gaming monitors can accept basically any fps as long as it is a whole number and doesn't exceed their maximum input (not a problem as most consoles output 30-60 fps) so if you have a gaming monitor and use an ossc to get hdmi in at a whole number... it's compatible. Boom no more issues, end of story. And you would just have to tolerate a virtually imperceptible fraction of a frame per second of lag.
I said this in my initial post suggesting it. Did you not follow?
It has always been console related. Gaming monitors can accept basically any fps as long as it is a whole number and doesn't exceed their maximum input (not a problem as most consoles output 30-60 fps) so if you have a gaming monitor and use an ossc to get hdmi in at a whole number... it's compatible. Boom no more issues, end of story. And you would just have to tolerate a virtually imperceptible fraction of a frame per second of lag.
that's simply wrong - on so many levels that I can't even start. You make it sound as if you believe what you're writing. Please stop spreading misinformation like that.
a) monitors won't accept anything but a few standarized timings EXCEPT when they're driven by a GSYNC or Freesync GPU.
b) rendering fps are only rarely related to the output refresh rate (and NEVER on consoles).
c) what's that BS about integer fps ?
d) if you even try to framerate convert a hardware synced input signal by 0.1Hz you get VERY noticable and constant stutter.
Seems like here comes a high end version of the OSSC.
