[vlc-devel] [vlc-commits] vout: start before creating the thread

[Rémi Denis-Courmont]

Le torstaina 31. tammikuuta 2019, 17.26.54 EET Steve Lhomme a écrit :
> On 31/01/2019 13:58, Rémi Denis-Courmont wrote:
> > Hi,
> > 
> > That's a ridiculous argument. VLC plugins have always been such that
> > they would br run on any thread but not be re-entered. And that's a
> > consequence of VLC always being multi-thread-based rather event-based.
> > If you want an event based media framework, you have the wrong project.
> > 
> > Not to mention that the GL provider and GL surface abstractions were
> > specifically designed to support multi-threading, unlike their
> > predecessors. Or that I need the changes to fix outstanding issues
> > assigned to me.
> 
> In the case of Qt it requires all OpenGL calls done with its context to
> be done in the same thread,

Qt requires all graphic calls done on the main thread. The VLC video output 
has never supported that and most likely never will as there are generally no 
ways for LibVLC to access the main thread. Qt OpenGL was never supported - and 
indeed, we never had a display plugin for that.

> that's a performance thing and to make sure
> they don't end up with areas not displayed from time to time.

Performance thing how? VLC does not require the display plugin to be 
reentrant, never did. So it does not need to worry about thread 
synchronization, and do expensive locking.

Indeed, all VLC plugin callbacks are guaranteed to be serialized and all side 
effects of any previous callback on the same module instance are guaranteed 
visible. With the explicitly documented exception (I think?) of the logger 
plugins.

Except on a NUMA system with a crappy scheduler, I don't see how running 
OpenGL on a single thread provides better performance. (And even then, you 
should work around it by pinning the process to a node to ensure the decoder 
and video output are on the same node.)

And if anything, running VLC code on the Qt thread is worse rather than 
better. You will just block out the main loop for longer, and thus actually 
maximize the risk of missing a rendering interval.

-- 
Реми Дёни-Курмон
http://www.remlab.net/