Unexpected quasi-pause when switching desktops
The Wanderer <[email protected]> Fri, 26 Aug 2022 13:21:52 -0400
| Newsgroups | gmane.comp.video.mplayer.user |
|---|---|
| Organization | This space intentionally left blank. |
| Message-ID | <[email protected]> |
I've just noticed an unexpected behavior in MPlayer, which I'm fairly sure didn't always happen in previous versions, but short of attempting a random-stab bisect (which I'd expect to be difficult, given the interactions with external code, from FFmpeg on out) I'm not sure where to start in trying to track it down. The specific version I'm working with is MPlayer SVN-r38366-11 (C) 2000-2022 MPlayer Team and it was built on July 14th of this year. The environment is Linux, with -vo vdpau and -ao alsa. My environment also includes the e16 window manager, using the "areas" feature (the lesser-used of two different methods of providing virtual desktops), and an easily-toggled button on every window which determines whether that window is "sticky" and follows you between desktops instead of remaining behind when you change desktops. I initiated playback of a series of three videos from the command line, and enabled the "sticky" behavior on that window. The first two videos played back fine, and the third started fine as well. At the start of the third video, I used the 'o' key to cycle through the onscreen display modes until the elapsed time and total estimated playback time were both visible. A few minutes into the third video, I switched to an empty desktop, disabled the "sticky" behavior, and switched away, intending to listen to the audio and let the video part play on its own in the background. Rather to my surprise, within about a second after I switched to another desktop (and brought another window into focus in the process), audio playback stopped. I switched back, and found that video and audio playback alike had halted; the video was not updating, the OSD's playback time was not advancing, and everything else seemed hung, much as happens when playback is paused via the spacebar. I pressed the left arrow key to seek backwards and the right to seek forwards again, and playback resumed from right before the hung point; I waited, and it passed the point where it had hung without issues. I switched desktops again, and the problem repeated itself, hanging at a new point. This behavior seems to repeat consistently, regardless of what point the video is at when I switch away. I checked the terminal where I'd launched the playback from, and there were no message logged at the time of the playback halting. I reproduced the problem by resuming playback again (via the seek method), leaving the video window on another desktop, and switching directly to the desktop with that terminal; that enabled me to see that the "current timestamp" for both the audio and video streams, as displayed in the terminal window, continued advancing for a moment after the audio stopped playing but then remained frozen until further input. Shortly after that point I exited the playback, having not found any further ways to get information out of it. The very next thing I've done is to write this mail. Aside from potentially running with verbosity flags, or building with debugging symbols and running inside a debugger, and trying to reproduce the behavior again, do you have any suggestions for what might be going on here or how I can try to track it down? For that matter, do you think the added information from verbosity flags would be likely to shed any light on the subject? Given that the terminal didn't show any sign that the program thought anything was wrong at that point, I'm uncertain whether the effort would even be worth making. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw _______________________________________________ MPlayer-users mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users
signature.asc
(application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEJCOqsZEc2qVC44pUBKk1jTQoMmsFAmMJATYACgkQBKk1jTQo MmuxFA/+OvdXDgUyK4LTIGDTfnRVXoVlSHD1pb1U9ebFgOJ+i8oZ8xsEZXU8KadH eQDeqSLjLZhV/qLteeHjcHeWhQOIfbPDhmFOmhMqNAhOvABvnKkouU+LYIEA0Wat ZnV40VKGN7v+Erpw+gKCCQ0dn47SRQxvuxlAxSMNSePODNZYnU5LLnJltbCsWhQr TVPpDxFZrKw4AZv3RJkIMJYBY82rEBXQUWsCxjop6g2nlTyApO+4BgnqmEXUtzG5 uI3uz0bUv5h+iOAkIfYy/5mxsJV+IAMUhJfl3nKkM1sJoDSYX7/N5vsklxsJQeVM U33/D3nKDbGDsyzD9+HPY3hevYBPr37dT6VCQJQOIPMmJurJBvfHKotEQTPZAkzK AN8QEx30YnDXxTtgdxqECbvq0Rfg6G20sdaoMsnSu87j9e7vMWo7N56pttS084fd RrOdZyRg4qp7LXwCtypQHbnCPk/8UCpVii2chl0kOxGJvg9qMMlVFVWHJqxYPmW6 BhPisbJZ8UGf0GGk5Ctk1HZFFRlN5oxioAa7oAj4RmNS8l0HhH5HtYJ+8IObXgVz OYoQeNY5ayOSSD+pMnIej9ScVoob0pcHcMhFsnpmp3xnh2mEuia/2N+87HgXEUCP BNRes8shu0orukS05MH6ANkIzxmgyDiZRARqqqTmWg8v0gnG4+A= =M4+V -----END PGP SIGNATURE-----