Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simulating CRT Monitors with FFmpeg (Pt. 1: Color CRTs)

int10h.org

Post reply on HN
Print view View original

41–50 of 62 posts

Re: Simulating CRT Monitors with FFmpeg (Pt. 1: Color CRTs)

#41

Post by opencl »

Bancakes wrote: post #30
IronWolve wrote: post #7

Digital Foundry did some good videos on CRT and Gaming, how lower resolutions looked so well, and could crank up the ray tracing at lower resolution. We really traded high pixel count for the CRT's blending of pixels with higher refresh. >DF Direct: CRT Displays - Was LCD A Big Mistake For Gaming? https://www.youtube.com/watch?v=tvRyVZWuvQ4 >DF Direct! Modern Games Look Amazing On CRT Monitors... Yes, Better than LCD…

Ah yes I remember the 1440p 144hz CRT's. Wait, no I don't. I think the best feature CRTs could provide was the purely analogue display chain in older models. Super fast "response time" and clarity.

The FW900 did 1440p or 120Hz, though not both at the same time. Only 80Hz at 1440p.

Re: Simulating CRT Monitors with FFmpeg (Pt. 1: Color CRTs)

#42

Post by kdrag0n »

JohnBooty wrote: post #14

I suspect (worry?) that a lot of folks miss out on the other thrill of physical CRTs... an experience that is as close to zero latency as is physically possible. This article breaks it down in wonderful detail: http://renderingpipeline.com/2013/09/measuring-input-latency... The TL;DR is that on a "modern" stack (USB, display buffering, etc) with a 60hz display you're looking at over 100ms of input latency. You can ro…

Sub-16 ms latency is still possible with modern hardware and 60 Hz AMOLED/LCD displays. It's probably not quite as low as an ideal CRT setup, but it should be pretty close. Most modern latency comes from the software stack, so I don't think switching monitors will make that big of a difference.

Example of 10 ms latency on a phone with an OLED display: https://twitter.com/kdrag0n/status/1291213993219039232 (source code: https://github.com/kdrag0n/touchpaint)

Drawing on the screen almost feels natural with such low latency, and it's probably ine of the most latency-sensitive applications for modern computers.

Re: Simulating CRT Monitors with FFmpeg (Pt. 1: Color CRTs)

#43

Post by viler »

Cheers for the comments. I'm still improving and tweaking this script - planning to test a fully 16-bit-per-component version of the filter chain, to eliminate any artifacts that might still exist. (Also, halation/diffuse glow for color CRTs isn't yet true to real-life visual results, but that will be improved.)

Re: Simulating CRT Monitors with FFmpeg (Pt. 1: Color CRTs)

#44

Post by viler »

kdrag0n wrote: post #42
JohnBooty wrote: post #14

I suspect (worry?) that a lot of folks miss out on the other thrill of physical CRTs... an experience that is as close to zero latency as is physically possible. This article breaks it down in wonderful detail: http://renderingpipeline.com/2013/09/measuring-input-latency... The TL;DR is that on a "modern" stack (USB, display buffering, etc) with a 60hz display you're looking at over 100ms of input latency. You can ro…

Sub-16 ms latency is still possible with modern hardware and 60 Hz AMOLED/LCD displays. It's probably not quite as low as an ideal CRT setup, but it should be pretty close. Most modern latency comes from the software stack, so I don't think switching monitors will make that big of a difference. Example of 10 ms latency on a phone with an OLED display: https://twitter.com/kdrag0n/status/1291213993219039232 (source cod…

Impressive work! Makes sense that this would require writing directly to the framebuffer - that was the oldschool way after all, and it's pretty cool to see this done on a modern device.

Re: Simulating CRT Monitors with FFmpeg (Pt. 1: Color CRTs)

#45

Post by tomxor »

Shameless plug.. I made a super slow motion 184 byte aperture grille (Trinitron) animation:

https://www.dwitter.net/d/12335

And a more recent one with more interesting motion at faster speed:

https://www.dwitter.net/d/21705

It is interesting how even as an animation it makes it look a lot smoother than the raw upscaled pixels of the same simple graphics.

Re: Simulating CRT Monitors with FFmpeg (Pt. 1: Color CRTs)

#46

Post by codetrotter »

tomxor wrote: post #45

Shameless plug.. I made a super slow motion 184 byte aperture grille (Trinitron) animation: https://www.dwitter.net/d/12335 And a more recent one with more interesting motion at faster speed: https://www.dwitter.net/d/21705 It is interesting how even as an animation it makes it look a lot smoother than the raw upscaled pixels of the same simple graphics.

The second one does not run for me on an iPhone X, but the first one does.

Re: Simulating CRT Monitors with FFmpeg (Pt. 1: Color CRTs)

#47

Post by techrat »

astrange wrote: post #38
NathanielK wrote: post #33

Earlier quoted context omitted.

CRTs have some really nice characteristics with moving content. If you're using an LCD or OLED display now, if you quick scroll or drag a window around you'll see you can't read the text while it's moving. CRTs are different though, they strobe in a way that means motion is always clear. While film lets you hide these artifacts with clever tracking and angles, it's very obvious with interactive video games. There are…

You should be able to read it on OLED, which has instant response time, especially if it's a fancier one with 120fps or black frame insertion. The issues are more likely to be with your eyes than the screen. LED has more motion blur and occasionally flickery blacklights to deal with.

At lower pixel or subpixel brightness OLED is still terribly affected by PWM strobing. Turn/move your head and you can see the on-off-on-off steps required for dimmer scenes or dark portions of a scene.

Re: Simulating CRT Monitors with FFmpeg (Pt. 1: Color CRTs)

#48

Post by Bancakes »

opencl wrote: post #41
Bancakes wrote: post #30

Earlier quoted context omitted.

Ah yes I remember the 1440p 144hz CRT's. Wait, no I don't. I think the best feature CRTs could provide was the purely analogue display chain in older models. Super fast "response time" and clarity.

The FW900 did 1440p or 120Hz, though not both at the same time. Only 80Hz at 1440p.

I guess that's cool but like you said, not at the same time, so it fails.

Re: Simulating CRT Monitors with FFmpeg (Pt. 1: Color CRTs)

#49

Post by pixelpoet »

herf wrote: post #13
IronWolve wrote: post #7

Digital Foundry did some good videos on CRT and Gaming, how lower resolutions looked so well, and could crank up the ray tracing at lower resolution. We really traded high pixel count for the CRT's blending of pixels with higher refresh. >DF Direct: CRT Displays - Was LCD A Big Mistake For Gaming? https://www.youtube.com/watch?v=tvRyVZWuvQ4 >DF Direct! Modern Games Look Amazing On CRT Monitors... Yes, Better than LCD…

Shadow-mask CRTs were the best ever for low-res antialiased text. It looked great for the low resolutions of the time. (Even trinitron wasn't as good.) You were guaranteed a near-gaussian point in the output, and from a signal-processing POV, this makes filtering and display just really beautiful and easy to do right. For instance, you could do a totally convincing subpixel translation with no visible artifacts.

omg, it's the stereopsis guy! I learnt so much from your old gfxcoding articles, thanks very much for those.

Re: Simulating CRT Monitors with FFmpeg (Pt. 1: Color CRTs)

#50

Post by tomxor »

codetrotter wrote: post #46
tomxor wrote: post #45

Shameless plug.. I made a super slow motion 184 byte aperture grille (Trinitron) animation: https://www.dwitter.net/d/12335 And a more recent one with more interesting motion at faster speed: https://www.dwitter.net/d/21705 It is interesting how even as an animation it makes it look a lot smoother than the raw upscaled pixels of the same simple graphics.

The second one does not run for me on an iPhone X, but the first one does.

I can only speculate as to why because it's safari which i don't have. If the eval is throwing an exception it's probably something to do with the unicode encoding that packs 2 ASCII chars into each UTF16 surrogate pair - the second one ultilises slightly more of the 20bits available and some UTF16 implementations/interfaces are buggy.

You could replace 'eval' with 'throw' and see if the output looks like sane JS

Post reply on HN