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

31–40 of 62 posts

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

#31

Post by Bancakes »

JohnBooty wrote: post #22
rubatuga wrote: post #20

Earlier quoted context omitted.

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.

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

#32

Post by viler »

cmiller1 wrote: post #10
kiwidrew wrote: post #9

Earlier quoted context omitted.

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.

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

#33

Post by NathanielK »

emmanueloga_ wrote: post #15
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…

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

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.

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

#34

Post by viler »

skratlo wrote: post #23

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.

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

#35

Post by kiwidrew »

viler wrote: post #32
cmiller1 wrote: post #10

Earlier quoted context omitted.

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

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

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

#36

Post by viler »

kiwidrew wrote: post #35
viler wrote: post #32

Earlier quoted context omitted.

(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.…

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…

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!

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

#37

Post by viler »

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…

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?

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

#38

Post by astrange »

NathanielK wrote: post #33
emmanueloga_ wrote: post #15

Earlier quoted context omitted.

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

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.

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

#39

Post by viler »

NathanielK wrote: post #33
emmanueloga_ wrote: post #15

Earlier quoted context omitted.

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

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…

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.

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

#40

Post by viler »

JohnBooty wrote: post #26
rubatuga wrote: post #19

Earlier quoted context omitted.

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…

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.
Post reply on HN