Wlroots: Interlaced output modes

[ElkMonster]

Hi,

i just wanted to report that there's a need for interlaced output mode support. Interlaced modes are currently skipped (per https://github.com/swaywm/wlroots/pull/1382, as a solution to https://github.com/swaywm/sway/issues/3167). In the commit, the author says: "a better solution could be made if there's a need to".

My use case is rather special, so I'd understand if my request should be declined. Here it is:

The company I work for creates content for various TV stations around the world. Some TV stations require very specific ways of content delivery. In this particular case, we have to provide a PC that provides the content via SDI (Serial Digital Interface) at 1080i50, using an HDMI to SDI adapter. We're using Sway on that machine because it allows us to easily control the output window exactly as we want to (activate fullscreen, move to a specific display, hide mouse cursor).

For now, I've created a patched version of wlroots that simply skips progressive modes instead of interlaced modes, and installed it on the concerned box. We'll be able to live with that hack because that box will probably rarely be touched, however, I'd be happy to be able to use upstream wlroots in the future.

Thanks for your consideration
Sascha

[emersion]

I'd rather not add support for a dying standard. You're the first one to request this since the creation of wlroots.

[sjnewbury]

@emersion I'm not sure calling interlaced display modes a dying standard is really accurate. It's very much the predominant broadcast standard because it allows the maximum definition and temporal resolution in the least bandwidth. As long as bandwidth is limited and there is a push for higher definition screens, broadcasters and videographers will continue to use interlacing.

It never really was a standard with respect to PC displays, despite a short period in the 90s as a cheap way to achieve 1024x768 on limited hardware. If wlroots is purely a PC technology, I think you're probably right not to add support, since it's unlikely anybody would use hardware incapable of generating display output with sufficient bandwidth to drive their screen technology at full resolution, probably... (Up until recently I was actually running a patched MythTV frontend on an Atom Pineview system on an old LCD TV that only supported 1920x1080i, and prior to that system I used a CRT with a Radeon with interlaced field synchronisation!)

On the other hand, making wlroots useful to broadcasters and video production might not be a bad idea, even if there hasn't been a visible demand for it, it's something which I suspect would be utilized quite eagerly by that particular niche if they came to know what could be achieved.

Just some thoughts...

[emersion]

cc @cyanreg for the video/broadcasting side of things

[cyanreg]

As long as bandwidth is limited and there is a push for higher definition sc ureens, broadcasters and videographers will continue to use interlacing.

That's plain wrong. 4k video is never interlaced. HEVC and AV1 don't even support interlacing. 720p video was never interlaced. A historical quirk made 1080i video the standard in professional broadcasting, and that too is on its way out. All modern TVs made in the past 16 years support progressive content. In fact, true interlaced monitors have not existed since CRTs were phased out. Nowadays deinterlacing algorithms butcher the image in such a way that its impossible to justify the alleged savings. Even OTT set-top boxes are outputting progressive.
Enabling support for interlacing in wlroots would do more harm than good to anyone wanting to hook up a TV to their computer, since DRM makes it easy for API users to pick them. That's the reason why it was disabled, for a lot of TVs wlroots would pick 1080i59.94 instead of 1080p60, despite both being advertised as supported.

On the other hand, making wlroots useful to broadcasters and video production might not be a bad idea, even if there hasn't been a visible demand for it, it's something which I suspect would be utilized quite eagerly by that particular niche if they came to know what could be achieved.

What you're wanting to do with wlroots is a hack, both in the broadcasting domain and in the desktop compositor domain. Please, use proper tools instead. Yes, you have to pay for a lot of them, but anyone who's working in broadcasting has enough to pay for them. Hacking open source projects and offloading the maintenance burden isn't exactly endearing. We carry a lot of such burden at FFmpeg. And no burden is heavier than old broadcasting gear burden.

The company I work for creates content for various TV stations around the world. Some TV stations require very specific ways of content delivery. In this particular case, we have to provide a PC that provides the content via SDI (Serial Digital Interface) at 1080i50, using an HDMI to SDI adapter. We're using Sway on that machine because it allows us to easily control the output window exactly as we want to (activate fullscreen, move to a specific display, hide mouse cursor).

That's such a duck-taped setup my friends who work in broadcasting would unceremoniously dismiss it.

[sjnewbury]

@cyangreg Fair enough.

I'm a little surprised though to read 1080i is "on the way out", technologically superseded for sure but 4K/60Hz progressive isn't going to replace the vast swathe of satellite, cable, and digital terrestrial channels out there anytime soon, there just isn't enough bandwidth and the installed base is just too significant. I've never had a STB which supports 1080p output although I'm sure the latest 4K models do. 720p was never a broadcast standard in most of the world, I've never seen it myself outside of YouTube!

Here in the UK : "All HD channels in the UK broadcast at 1080i, apart from BT Sport Ultimate and Virgin TV Ultra HD which are broadcast at 4K.[1] HD channels can dynamically switch between 1080i/25 and 1080p/25 when broadcast via Freeview HD. (Wikipedia). 1080i 50/60 fields/s is superior to 1080p 25/30 frames/s where temporal resolution is needed even with imperfect de-interlacing techniques.

Anyway, not arguing for the feature, I was just a little surprised with what you wrote and your categorical rejection of my perspective on broadcast tech.

Edit: I also don't see why F/OSS shouldn't be used in professional environments generally. It is used in a great many, not sure why broadcasting/TV production should be an exception.

[kennylevinsen]

We are not opposing the use of FOSS in the broadcast industry in any way.

First of all, I'll quote Wikipedia regarding 720i:

720i (720 lines interlaced) is an erroneous term found in numerous sources and publications. Typically, it is a typographical error in which the author is referring to the 720p HDTV format. However, in some cases it is incorrectly presented as an actual alternative format to 720p.[3] No proposed or existing broadcast standard permits 720 interlaced lines in a video frame at any frame rate.

Back on topic: We just do not find there to be any technical merit for supporting interlaced output modes, as no output natively display interlaced content, and de-interlacing is terrible. The incidental analogue bandwidth optimization it grants as a side-effect of older CRT operation is only relevant in analogue broadcasting. Both CRTs and analogue broadcasting are indeed on their way out.

Catering to this would be extremely niche for wlroots, and maybe even just be you alone needing it, so we'd prefer to not take the hit and general user problems it would cause upstream. Instead, if you want to use this, I'd recommend patching locally to undo the PR. Note that you will probably get additional artifacts if you display deinterlaced content like this.

For digital broadcasting, bandwidth optimization of digital content should be done by tuning the encoder used for compressing your content, not by interlacing. I am fairly confident that modern codecs will present far superior "temporal resolution" to any interlace hacks with less bandwidth (they can do tricks like shifting content), and that interlacing probably only causes trouble for the encoder. I doubt its use here could be for anything other than historic reasons.