[vlc-devel] Display update/restart

[Rémi Denis-Courmont]

Le lundi 16 novembre 2020, 13:24:33 EET Steve Lhomme a écrit :
> The current way of handling source changes is to redo the filter
> chain(s) and add an extra filter if the last filter doesn't output what
> it was supposed to. So the source change is effectively canceled by this
> last filter.

That's a very confusing statement. If the decoder output format changes, then 
of course you have to redo the display and the filter chain. (Also what I wrote 
in the previous mail.)

If the filter chain output changes, then that's the asynchronous filtering 
problem: what if a filter changes its output while running or if the user adds 
a filter than changes the output.

Currently, the former is outright not permitted, and the later is assumed not 
to occur, and clumsily handled. But they're really two different ways to 
trigger the same issue.

The "correct" solution is to instantiate the pipeline from upstream down, i.e. 
spawn the display after the filter, and respawn everything downstream when a 
filter changes. That's more or less what we already do at packetizer and 
decoder levels. For audio, this is not practical because of pass-through. For 
video, I don't know any obvious problem, but there may be.

The simpler hack is to just destroy the display and make a new one, as in the 
previous mail, when the filter chain changes. Now that the picture pool, the 
hardware context and the window are all independent of the display, that's not 
a problem.

(...)
> This is becoming critical because we have to handle interlaced HEVC
> which decoders output field by field, rather than 2 fields at a time for
> all other interlaced codecs. So when deinterlacing kicks in (patches
> coming soon), the dimension coming out of filter is double the height.
> To display it properly we need to update the display or create a new
> one. We should not use a filter to reduce by half the height and display
> it in the old display. And given the picture surface is actually double
> the size, it's quite a big change for the display module.

I have to disagree here. First, it's not clear at all if we want to support 
interlaced HEVC, because on the face of it, that's really an incredibly stupid 
idea.

And then, the deinterlace resolution problem is not new. We already have some 
deinterlacing algorithms changing the resolution by a factor of 2 (not to 
mention the cropadd filter whose essence is to change the resolution).

-- 
Rémi Denis-Courmont