Details
-
Bug
-
Resolution: Cannot Reproduce
-
P2: Important
-
None
-
5.1.0 , 5.1.1, 5.4.1, 5.5.0
-
None
-
Mac is a mid-2012 Macbook pro; OSX 10.8.5. (Nvidia graphics; makes no difference to observed behaviour whether the graphics switching power saving system setting thing is on or off).
Linux machine mentioned as comparison (which works as expected) is current Debian/unstable with Debian's qt5 packages running in a Virtualbox VM.
--
Also observed in early-2011 Macbook Pro; OS X 10.9.5, Qt 5.4.1 and early-2015 Retina Macbook Pro; OS X 10.10.5, Qt 5.5.0Mac is a mid-2012 Macbook pro; OSX 10.8.5. (Nvidia graphics; makes no difference to observed behaviour whether the graphics switching power saving system setting thing is on or off). Linux machine mentioned as comparison (which works as expected) is current Debian/unstable with Debian's qt5 packages running in a Virtualbox VM. -- Also observed in early-2011 Macbook Pro; OS X 10.9.5, Qt 5.4.1 and early-2015 Retina Macbook Pro; OS X 10.10.5, Qt 5.5.0
Description
There's a fair amount of commentary at http://qt-project.org/forums/viewthread/33099/ but my 3rd post there http://qt-project.org/forums/viewthread/33099/#144800 is probably the simplest illustration.
Basically the example in Qt's supplied examples/multimediawidgets/videowidget behaves differently between Linux and Mac with regard to whether/when end of a video stream is reported back to the app via changes to QMediaPlayer::State (and QMediaPlayer::MediaStatus). The Linux behaviour seems correct and sensible and is presumably intended (a video ends and it immediately tells you it has). The Mac is more random; sometimes it works as expected but more often the video position just sticks at a constant value and the expected state changes don't arrive until later (minimising the app or obscuring it with another window seem to be reliable ways of flushing them).
The obvious symptom in the example is that the play/pause icon displayed on the button (usually) doesn't change on the Mac when the video ends, but it always does on Linux. Adding some console logging to the example (and a slot for MediaStatus changes) makes it a bit more obvious what's happening.
Worst case these state changes can arrive when the user has started interacting with the video in other ways (scrubbing video position manually, for example) and the delayed arrival of a stop and reset of the video position to the start is most confusing.