pyqt5: second video does not play: concurrent QMediaPlayer issue?

tl:dr;

Use layout managers.

Explanation

Well, it seems you accidentally found a (possible) bug by doing something really wrong.

QVideoWidget is a widget that is more complex than it seems, since it interfaces itself with the underlying graphics system of the OS, and, in order to correctly show its contents (the video), it has to be actively notified of its geometry.

Simply speaking, QVideoWidget does not directly show the "pictures" of the video QMediaPlayer shows, but tells the Operating System to do so (well, not exactly, but we won't discuss it here). This is because video displaying might take advantage of some hardware acceleration, or require some processing (for example, for HDR videos), similarly to what 3D/OpenGL graphics does.

When a program is going to display some (system managed) video, it has to tell the OS about the available geometry for that video, so that the OS is able to show it at the correct coordinates, and possibly apply resizing, some form of "clipping" (if another window is overlayed, for example) or any other level of [post]processing.

The "something really wrong" I was talking about before is based on the fact that you are using fixed geometries (sizes and positions) for both video widgets, and I think that Qt is not able to notify the system about those geometries for more than a widget at once if that happens before the video window is actually mapped (as in "shown").

Why is it really wrong, besides the issue at hand?

Each one of our devices is mostly unique: what you see on your device will be shown in a (possibly radically) different way on other's.
There are many reasons for that, including:

• Operating System (and versions) and its behavior;
• screen size and DPI (for example, I wasn't able to view the complete window of your code, since I've a smaller screen);
• default/customized system font size; most importantly, if the default font is very big, the widgets might overlap;
• further customization (for example, default margins and spacing);
• if the interface is "adaptive", the user should be able to resize the interface:
  • if the user has a smaller screen, the ui should be resizable, so that everything is visible instead of having the need to move the window beyond the screen margins (something that is sometimes impossible: for example on Windows you can't move a window above the top margin of the screen);
  • if the user has a bigger screen (or uses a very high DPI setting), the interface would be too small and some elements might be hard to read or interact with;

That's the reason for which almost any nowadays website uses "responsive" layouts, which adapt the contents according to the screen of the device they're going to be displayed into.

The solution is very simple, and will also solve the big issue about your GUI: avoid any fixed geometry for your GUI and use layout managers instead.

Note that you can still use fixed sizes (not positions, sizes!): that's not that big of an issue, but using layout managers will help you a lot with it, by repositioning all elements according to the available space.
The reason for it is that layout managers ensure that any resizing operation (something that also happens many times as soon as a window is shown the first time) is also notified to the system, whenever it's required (like, for instance, adapting the QVideoWidget output).

If you want to keep the "bottom-right/top-left" layout, you can still do that: set a main QGridLayout for the widget (DNN_Viewer), create another grid layout for each player and add those layout to the main one.

The structure will be something like this:

+------------------------- DNN_Viewer -------------------------+ | | +------ player2Layout ------+ | | | | | | | | | vw2 | | | | | | | | | +-------+-------------------+ | | | | pb2 | sld1 | | | | +-------+-------------------+ | +------------------------------+-------------------------------+ | +------ player1Layout------+ | | | | | | | | | vw1 | | | | | | | | | +-------+------------------+ | | | | pb1 | sld2 | | | | +-------+------------------+ | | +------------------------------+-------------------------------+ 

class DNN_Viewer(QWidget): # ... def init_gui(self): # create a grid layout for the widget and automatically set it for it layout = QtWidgets.QGridLayout(self) player1Layout = QtWidgets.QGridLayout() # add the layout to the second row, at the first column layout.addLayout(player1Layout, 1, 0) # video for weights and gradients self.vw1 = QVideoWidget(self) # add the video widget at the first row and column, but set its column # span to 2: we'll need to add two widgets in the second row, the play # button and the slider player1Layout.addWidget(self.vw1, 0, 0, 1, 2) # ... self.pb2 = QPushButton(self) # add the button to the layout; if you don't specify rows and columns it # normally means that the widget is added to a new grid row player1Layout.addWidget(self.pb2) # ... self.sld1 = QSlider(Qt.Horizontal,self) # add the slider to the second row, besides the button player1Layout.addWidget(self.sld1, 1, 1) # ... player2Layout = QtWidgets.QGridLayout() # add the second player layout to the first row, second column layout.addLayout(player2Layout, 0, 1) self.vw2 = QVideoWidget(self) # same column span as before player2Layout.addWidget(self.vw2, 0, 0, 1, 2) # ... self.pb3 = QPushButton(self) player2Layout.addWidget(self.pb3, 1, 0) # ... self.sld2 = QSlider(Qt.Horizontal,self) player2Layout.addWidget(self.sld2, 1, 1) 

This will solve your main issue (and lots of others you didn't consider).

Some further suggestions:

• use more descriptive variable names; things like pb2 or lb23 seem easier to use and you might be led to think that short variables equals less time spent typing. Actually, there's no final benefit in that: while it may be true that shorter variable names might improve compiling speed (especially for interpreted languages like Python), at the end there's almost no advantage; on the contrary, you'll have to remember what "sld2" means, while something like "player2Slider" is way more descriptive and easier to read (which means you'll read and debug faster, and people reading your code will understand it and help you much more easily)
• for the same reason above, use more descriptive function names: names like cb_mp1_3 mean literally nothing; naming is really important, and the startup speed improvement reported above is almost dismissible with todays computers; it also helps you to get help from others: it took more time to understand what was your actual issue, than to understand what your code does, since all those names were almost meaningless to me; read more on the official Style Guide for Python Code (aka, PEP 8);
• use comments wisely:
  • avoid over-commenting, it makes comments distracting while losing much of their purpose (that said, while "Let the code be the documentation" is a good concept, don't overextimate it)
  • avoid "fancy" formatted comments: they might seem cool, but at the end they are just annoying to deal with; if you want to comment a function to better describe what it does, use the triple quotes feature Python already provides; also consider that many code sharing services have column limits (and StackOverflow is amongst them): people would need to scroll each line to read the corresponding comment;
  • if you need a description for a single line function, it's possible that the function is not descriptive as it could or should be, as explained above;
• be more consistent with blank lines separations between functions or classes: Python was created with readability in mind, and it's a good thing to follow that principle;
• don't overwrite existing attribute names: self.width() and self.height() are base properties of all QWidgets, and you might need to access them often;
• be more consistent with the imports you're using, especially with complex modules like Qt: you should either import the submodules (from PyQt5 import QtWidgets, ...) or the single classes (from PyQt5.QtWidgets import QApplication, ...); note that, while the latter could be considered more "pythonic", it's usually tricky with Qt, since it has hundreds of classes (and you might need tens of them in each script), then you always have to remember to add every class each time you need it, and you might end up importing unnecessary classes you're not using anymore; there's not much performance improvement using this approach, at least with Qt, especially if you forget to remove unnecessary imports (in your case, the possible benefit of importing single classes is completely canceled by the fact that there are at least 10 imported classes that are never actually used);
• avoid unnecessary imports from other frameworks if they are not absolutely necessary: if you need to know the screen geometry, use QApplication.screens(), don't import Tk just for that;