Pairing multiple vlc_player_t <-> vlc_window_t' / vouts in module

[bjornss]

When creating an interface module with "vout window" submodule(s) with linked Callback( vlc_window_t*)-function I need to play several videos concurrently.
Is there any way that multiple vlc_player_t struct/"objects" and the corresponding vlc_window_t structs created on their startup can be uniquely identified with each other?
Can the identification/pairing be done using existing vlc struct members?
Put another way. How can we control / identify the vout thread for each vlc_player instance starting to play media?

As seen above, so far I have run the multiple vlc_players_t linked to a SINGLE libvlc instance, as a module.
Can the identification be achieved with this configuration or do I need multiple libvlc instances to uniquely pair & identify players with vouts?

[Rémi Denis-Courmont]

As long as there is only one window per player, you know which window was set to which player. You don't need mutliple LibVLC instances as such.

A window module doesn't know or care which player it belongs to. It's just there to provide the window ID to VLC.

[bjornss]

Thanks for swift reply,

Yes, there is only one desktop window(in window manager sense) , but multiple players, with multiple vlc_window structs pointing to the SAME desktop window.
(I am adapting part of the compositor framework in VLC Player with multiple players inside one window)

I am probably being a novice here (it is my first attempt at creating/adopting a VLC module), but:
How do you know which vlc_window struct belongs to each vlc_player struct exactly? Are there members in any of the structs pointing to each other?
Are there functions in the VLC (module) API providing links between them?

It appears that an approximate mapping can be achieved by the execution order of vlc_player_Start commands and the corresponding vlc_window_t's structs being forwarded by the module callback(vlc_window_t*) function,
but this is not always the case. Sometimes the vout pipelines/threads appear to start in a different order than vlc_player_Start commands, so my question is how to maintain a proper identification between them.
I need to know the media identity of each video playing in the Desktop window, and I need to keep the geometric arrangement of media fixed on each execution.

[Rémi Denis-Courmont]

You are not supposed to do that. That's called breaking encapsulation.

The player is supposed to know what window(s) it uses, not the other way around.

[bjornss]

The player is supposed to know what window(s) it uses, not the other way around.

HOW can a specific player know which vlc_window_t struct is created upon start of its vout thread, inside an interface module when multiple player's are instantiated?
HOW can I programmatically pair up these structs? Do I have to rely on IMPOSED delays to enforce a certain execution order?

Sorry for being detailed in the following, but I don't see that my SPECIFIC question(s) above has been answered?

Are you saying VLC mandates I use SEPARATE DESKTOP windows for each vlc_player_t I instantiate? (Yes I know this seems to be what happens by default without compositor or other tricks like enclosure of video "window" inside Qt Widget.)
Is the vlc_window_t struct ALWAYS supposed to be tied to its OWN DESKTOP window/OS Windowhandle? If so I am able to run VLC without this restriction and so is the old VLC-Qt library, see below.
Still my question is then, how do I know (programmatically, NOT visually) what player belongs to what window?

NOTE I am talking in-module vlc_player NOT the higher-level libvlc_media_player API where there are OS specific functions binding it to a OS-defined windowhandle, e.g libvlc_media_player_set_hwnd() for Win-platforms.
Incidentally, I don't see any restriction on assigning DIFFERENT player instances to the SAME window handle here. I know this is done in VLC-Qt using Qt Widgets (Granted, unless you impose geometric separation by means of the former or using geometrically separate Compositor surfaces you may see at best, one video of the last vout thread instantiated, or a garbled mix of several player frames mixed up)

Summing up: I have been able by hacking the qt interface module(maininterface) - VLC Player to display multiple videos as geometrically separate DCOMP visuals, superimposed on a COMMON QML UISurface, but my problem is that the display order(ie IDENTITY of visuals) sometimes changes randomly with each execution, as I have not found the LINK between a specific vlc_window_t's and the vlc_player originating it. There is only a partial ordering with respect to execution order of vlc_player_Start) and the invocation of the WindowOpen callback in the vout submodule to the qt module.
With this detailed explanation, I hope you now understand the gist of my question above.

[Rémi Denis-Courmont]

With the plugin API, you can do that by setting a variable on the player object and inheriting it in the window. That really only makes sense if you are writing a custom interface plugin within VLC though, and your OP mentioned LibVLC instances...

[bjornss]

Thanks for clarification.

I understand the concept of defining/setting an additional variable in vlc_objects, but I am still a bit unclear on the structure of C API vlc object hierarchy and inheritance between modules, specifically the vout module wrt. to core:
I guess the low-level vlc_player_t object always belongs to the core module, even though it is USED by other modules, right?
If so I guess the closest common ancestor of vlc_player_t and the vlc_window_t object created in the vout module, will then be precisely the core module, so I would need to define a new variable here from which both vlc_player_t and vlc_window_t would inherit and could therefore be paired?

Or is there another way to insulate core/vout modules from change - e.g by the VLC C API equivalent of subtyping, so I don't have to (minimally) modify core/vout?
If not, I would perhaps suggest that such an extension be included in later official versions of VLC CORE library / Module API for developers needing to use multiple simultaneous players in modules etc.


Optimally I would like to stay in the higher level (Out-of-module) libvlc API, but it seems I can't do this with SINGLE Desktop Window - multiple-video-in-window(as represented by INDEPENDENT vout threads, presenting SEPARATE vlc_vindow_t objects) video compositing, according to your earlier replies. IE It seems that to achieve the latter, I have no choice but to use the lower level core module, vlc_player, rather than the LIBVLC based libvlc_media_player_t object.

If my understanding is correct, a reply is not needed.

Thanks again for your guidance.

[Rémi Denis-Courmont]

You can't get either a vlc_window_t or a vlc_player_t with the high-level LibVLC APIs. That's why I said your question only makes sense in the context of a custom VLC interface plugin, as opposed to a LibVLC application.