Windows Pro x64 current patched LO Version: 5.4.2.2 (x64) Build ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4 CPU threads: 8; OS: Windows 6.19; UI render: default; Locale: en-US (en_US); Calc: CL OpenGL OFF per bug 112958. Since at least LO 5.3 the LO Impress Media Player REPEAT toggle does not loop a selected embedded object MP4 video clip. Play ends in a "black screen" with player PLAY function button selected. Selecting player STOP button returns embedded clip to static first frame placeholder state. Identical behavior on both integrated Intel graphics display and NVIDIA external displays. Other Media Player behavior as expected but I note the SEEK bar does not advance as during play and I presume it should. See bug 100007.
Looks like bug 106981
The search terms I used did not turn up bug 106981. Yes, this bug *extends* bug 106981 with different instance details: + Additional display contexts. See bug 112958 for additional detail on the platform involved. + OpenGL state detail. See bug 112958 for additional detail on the platform involved. So, not exactly a duplicate of bug 106981 but the two should be linked somehow. Not seeing how to link to this bug to bug 106981 except to cross-post and reluctant to mark it a DUPLICATE else the additional context data in this bug might be overlooked.
(In reply to R. Bingham from comment #2) > + Additional display contexts. See bug 112958 for additional detail on the > platform involved. > > + OpenGL state detail. See bug 112958 for additional detail on the > platform involved. > > So, not exactly a duplicate of bug 106981 but the two should be linked > somehow. Not seeing how to link to this bug to bug 106981 except to > cross-post and reluctant to mark it a DUPLICATE else the additional context > data in this bug might be overlooked. It is duplicate on the level of behaviour. I don't see how a different graphics driver would make it a non-duplicate.
Except that there *can be* different user-perceptible behavior depending on the combo of OpenGL use state and graphics sub-system for a given display. See bug 112958 for an example - different video presentation behavior when using OpenGL and dragging the *playing video* from one display/graphics stack to another and back. I agree that the probability of different behavior is low between among CPU embedded graphics sub-systems (Intel vs. AMD vs. whatever). But as soon as there is an external GPU graphics sub-system in the mix that is in effect an independent stack typically driving dedicated displays, user-perceptible LO behavior can be broken *differently*. Its the usual and annoying platform fragmentation the app developers have had to deal with since forever. Probably the player's Repeat (Loop) function *is* broken in a universal way but I am cautious in preemptively ruling out the various graphics stacks as breaking it in different ways after experiencing bug 112958.
I think to investigate, you could install this 32-bit build (it installs separately): http://dev-builds.libreoffice.org/daily/master/Win-x86@42/current/ If repeat works in the 32-bit build, I would close this as duplicate of bug 106981. Then after bug 106981 gets a fix some day, you could test it and if it is not fixed for you, your own report can be opened again.
Installed libo-master~2017-11-04_23.19.31_LibreOfficeDev_6.0.0.0.alpha1_Win_x86.msi and tested Impress video player repeat function. Repeat function performed as expected. Re-tested LO 5.4.4.2 x64 and repeat function not changed, so still not repeating. Not quite an apples to apples comparison since LO 5.4.4.2 x64 vs LO 6.x but maybe close enough to declare this bug a duplicate of bug 106981 per Buovjaga. FYI - but other video playback behavior changed affecting bug 112958, most likely because of a NVIDIA driver update. *** This bug has been marked as a duplicate of bug 106981 ***