Simulating CRT Monitors with FFmpeg (Pt. 1: Color CRTs) | Hacker News Reader

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

int10h.org

173 pointssep59 comments

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

Output from iphone 11 seems to confirm your theory: https://dpaste.com/GU8A3X4H7#wrap

Hah, actually that code is correct (Although I realise it probably looks like gobbledygook :D) so it disproves my theory.

The code is mostly arithmetic, so the only thing I can see which could be implementation sensitive is the canvas fillStyle HSL string, which omits commas and spaces since the % postfixes are enough to delimit the saturation and luminance, but obviously this depends on the canvas interface implementation.

I looked into it and this turned out to be the problem exactly.

If you change the part of your code where you have

  hsl(${i*120} 99%${K*99}%

To instead

  hsl(${i*120} 99% ${K*99}%

(That is, by not omitting the space after 99%)

Then it works in the versions of Safari that I tested; Safari 14.0.3 on macOS Big Sur 11.2.2 running on a MacBook Pro M1, and Safari on iOS 14.4 running on an iPhone X.

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!

https://www.youtube.com/watch?v=V8BVTHxc4LM

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.

haha so it is happening... CRTs are for gaming, in the same vein LPs are better for music, and valves are better for amps, etc, etc

If you care about this stuff...

(and there is absolutely no reason to care, but you are making a comment, so you seem to care a little)

...the tradeoffs are really fascinating. Don't think of it as one being better. It's just a different set of tradeoffs. CRTs are objectively better at some things, and are of course also objectively worse in a lot of obvious ways.

I would say that LPs and tube amps are objectively worse than their modern counterparts in every way. But the tradeoffs involved and the subjective issues are cool and sometimes do make for a better subjective experience in some ways.

Tube amps are amazing for distortion effects, no doubt. But for a 1-to-1 reproduction of audio signals, it's not great.

For sure. The even-order harmonic distortion can sound "good" though. It's not my cup of tea but I wouldn't say somebody's crazy if they prefer it!

LPs are a slightly more interesting discussion IMO. Objectively inferior to Redbook audio by a mile. But, given the 30-40dB noise floor even in a "quiet" room, and the THD added by the loudspeakers, I think their real-world performance competes very very well with digital audio...

A lot of the differences people ascribe to CDs vs. LPs may not be due to the medium, but to different paradigms used when mastering audio for one or the other.

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 tricks to fix this, but consumer display tech is quite inconsistent.

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.

A perfect 120Hz OLED is still over 8ms of blur (MPRT), a crt is closer to 1.5ms MPRT.

There also are almost no OLEDs the right size for PC gaming.

Hopefully as VR tech becomes mainstream, display tech can improve up to the 1.5ms mark.

The issue with modern displays (OLED and LCD) is that they are sample-and-hold, which means that a frame will remain lit for its whole duration, leading to motion blur. Even a perfectly instantenous pixel response won't fix that.

Very true. A project I'm working on involves some scrolling and animation on older hardware at 60Hz. Looks absolutely smooth on the CRT, but when emulated on a modern display there's always some kind of trailing/blurring.

Some older Zowie gaming monitors let you strobe the backlight at 60Hz to work with older software, as well as some modern TVs. It's quite fiddly to setup, but it can be worth it if you enjoy your old 60Hz locked games looking smooth.

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.

I've been using CRTs again for the first time in a few years and none of these really capture the way they look.

The TTL RGBI 320x200 one looks pretty accurate to me when compared to a real 15.7khz 200-line CRT, and the render of Crystal Caves on a double-scanned VGA also looks about right as compared to an early 90's 14" VGA CRT.

Can't comment on the others, though.

In Part 2 (monochrome) the Apple II green monochrome is spot-on accurate and the Amber MDA 80x25 textmode is pretty good except that the background contrast is quite poor. A real amber MDA monitor has much deeper blacks.

The contrast issue is what I notice the most. CRTs had much more "glow" and "bleed" I guess

Many of the retro takes on CRTs seem to over-emphasize the scanlines and (perhaps in pursuit of capturing the CRT "glow") also end up over-doing the background. On a properly adjusted CRT you shouldn't be able to see any scanlines at all in areas that are displaying pure black, unless you're viewing the display in an extremely dark room.

Yeah I don't see the scanlines at all on the CRT I've been using

(Author of the script here): appreciate the observations. Pretty much all of these parameters (scanline intensity/sharpness, pixel blur, glow/halation, blackpoint for the background) can be adjusted to taste in the configuration files. :)

I tried to show the range of possibilities in the screenshots/video samples, e.g. higher-res EGA/VGA with no visible scanlines, and some amber monitor shots with deeper blacks, etc. Admittedly, this script is geared more towards simulating lower-resolution CRTs - mostly because my approach entails a large oversampling of the input.

I'm impressed with the results from your lo-tech batch file approach. The output is really quite nice.

It turns out that real CRTs also have a number of user-adjustable parameters, which of course makes it impossible to define any sort of "canonical" or most-accurate preset. :)

(Like this weird paper-white monochrome CRT that uses P7 phosphor, designed for 350-line MDA but can also handle a greyscale 15.7khz 200-line CGA input... the scanlines are so sharp that it looks 100% fake!)

Yup, multisync/multi-scan sure complicates things. :)

I'd still like to give it enough flexibility so that a preset can at least be accurate to a particular mode of operation. I actually went down the rabbit hole of looking up a precise persistence curve for the P39 phosphor (as used in the IBM 5151) - found conflicting data, but a friend will be helping out with a video and an ad-hoc program to get some results, so we'll see!

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 roughly halve that with a 120hz display.

But it won't ever touch the sub-16ms latency that's possible with a "retro" 8/16-bit console hooked up to a CRT display.

A lot of those games were garbage, but damn... it felt like your brain was wired directly into the machine. A very very cool part of the experience that is being lost to time.

Yes, the same thing with telephone calls over copper. No latency. You could both talk at the same time, more immersive.

I also remember vector displays first-hand.. those were pretty awesome. You're never going to get a vector graphics experience ever on an LCD because LCDs are rasterized pixels not a drawn line.

No one will ever make a limited run of CRTs or vector monitors ever again, but I wish they would. People would buy them.

That's a great example. Nobody will ever really experience that again!

   No one will ever make a limited run of 
   CRTs or vector monitors ever again, but 
   I wish they would. People would buy them.

The prices people are paying for high-quality CRTs today are proof of that. I was lucky enough to get a sweet Sony PVM before the prices really went through the roof.

But yeah, they'll never be manufactured again. It would be such an absolutely massive undertaking.

   I also remember vector displays first-hand.. those 
   were pretty awesome. You're never going to get a 
   vector graphics experience ever on an LCD because 
   LCDs are rasterized pixels not a drawn line.

Yeah and there's also the temporal aspect -- the "smearing" of ultrabright vector dots, like your bullets in Asteroids.

I've seen folks be totally blown away when seeing something like an Asteroids cabinet in person for the first time.

I have an old Vectrex video game that I got as they were closing them out. Amazing machines because they had the monitor built in, you didn't have to connect them to a TV. Because the monitor was built in they could drive it any way they wanted, so it was vector all the way - no rasters.

I can't find the link now but there is a company making still brand new CRTs and the owner has considered making some for gamers, however i doubt this will be a thing since - at least for now - CRTs are easy to find for very cheap and a limited run would be very expensive. Exception being the high end trinitrons and similar, but i doubt said company is making CRTs of that caliber (i think they're making TV-like stuff) anyway.

Perhaps in 20 years if they're still around things will be different though. After all CRTs do wear out from use.

Resolution is rapidly reaching the point where it won’t be the limiting factor in properly simulating a vector display, at least in a “good enough” fashion. Similar to how resolution and refresh rate improvements are making it feasible to simulate a raster CRT.

At this point, one of the primary limiting factors is the reality that the majority of folks using and implementing emulation technology probably have never seen a vector display in the flesh.

Conceptually, emulating a vector display is easy. They are unique but not thaaaat magical.

1. You have a certain amount of bloom

2. You have decay time function

3. You need, perhaps, a surprising amount of dynamic range? If you've seen something like an Asteroids cab in person, the bullets are super bright (with correspondingly larger decay times) relative to everything else

But, how people are interested in implementing that kind of thing and have access to a real vector display in order to study it? I suppose sufficiently good recordings of vector displays might suffice so maybe it's not that dire.

You can get 37.5ms latency on a MacBook Air running at 60Hz: https://news.ycombinator.com/item?id=15488191

I think if you use a 120Hz monitor on a Linux text console, it would be sub 20ms.

That's awesome!

I love that one reply:

    "This is incredible. Single user mode 
    feels like the screen updates BEFORE 
    pressed the keys, like it is time 
    travelling. I guess I've used to the 
    high latency on newer computers."

Do you know of any games/emulators that run in such an environment? (Maybe stuff like RetroPie does by default, I have no idea!)

Closest I can recommend is FreeDOS to run games natively. It's so good but the drivers are very basic. It does have a package manager.

This is part of why I’d be happy to see more hardware reproductions of classic computers and consoles. Emulators are pretty good but they bring a certain amount of unavoidable overhead that can never be entirely eliminated.

psychophysicists love them for exactly this reason. it's easier to put an accurate physical timestamp on the display of a stimulus with analog crts without resorting to measuring an onscreen fiducial marker.

Yes - that's a great point. Although from the article, it seems that most of the latency isn't down to the display, but to the CPU/GPU part of the chain?

Yes, about 2/3 of it comes from the software/hardware stack in your computer/console.

The remainder (a few frames' worth of latency) is from the display itself. There's something like a frame buffer inside the display if I understand correctly although implementations vary widely; some displays are good for gaming and some aren't.

If you have a chance to game with original 8/16-bit hardware with wired controllers on a real CRT it's such a treat. You can really feel the difference.

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.

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.

XScreenSaver also has a demo that simulates an analog tv instead of a monitor like this.

It’s called “XAnalogTV”: https://www.youtube.com/watch?v=VmM1KkFsry0&list=PLbe67PprBS...

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.)

it's a dos batchfile on github that applies ffmpeg filters in clever ways to recreate the distortions and artifacts of displaying images on old cathode ray tube displays.

cool!

I would not have expected an AVISynth reference in 2021. VFW for the win!

I use it with VapourSynth, actually, but as the name implies it would never have existed without AVISynth and its community <3 http://www.vapoursynth.com/about/

Loving it! Get into shaders asap if you want to push it further.

Thanks. Yep, a pure GPU approach is probably the way to go for this stuff in general. One reason I used FFmpeg here was the goal of applying the effect to stand-alone videos/images, which you can't conveniently/easily do with shaders (AFAIK).

The other reason is that my shader coding experience is pretty much zero, something I should fix at some point. ;) But if someone more knowledgeable gets inspired by this in the meantime and cooks something up, that'd be cool for sure.

cool-retro-term is fab for this.

It takes me back to the Amstrad PCW8256 that I used as a kid.

Those double sided CF2 disks were a better disk than either the 5.25" or the 3.5" IMHO.

> Those double sided CF2 disks were a better disk than either the 5.25" or the 3.5" IMHO.

Not sure how they were better than 3.5" disks at that time (they might have been better than the poor quality once sold towards the end of the Floppy era), but for sure they were much more expensive. I don't miss them one bit.

Reply on news.ycombinator.com