Skip to content

Property window-scale is incorrect after fullscreen #4323

Closed

Description

@Argon-

mpv version and platform

OSX 10.11

cplayer: mpv git-1a0c340 (C) 2000-2017 mpv/MPlayer/mplayer2 projects
cplayer:  built on Sat Apr 15 21:05:27 CEST 2017
cplayer: ffmpeg library versions:
cplayer:    libavutil       55.58.100
cplayer:    libavcodec      57.89.100
cplayer:    libavformat     57.71.100
cplayer:    libswscale      4.6.100
cplayer:    libavfilter     6.82.100
cplayer:    libswresample   2.7.100
cplayer: ffmpeg version: 3.3

Reproduction steps

  1. Query window-scale
  2. Go to fullscreen
  3. Query window-scale
  4. Wait 2 seconds
  5. Query window-scale

(See script below)

Expected behavior

window-scale from step 3 and 5 should match.

Actual behavior

window-scale in step 1 and 5 match.
Note that using mp.observe_property will only return correct window-scale values and not exhibit this problem.

Log file

Test made with this script: https://gist.github.com/Argon-/aadd9b337ca4d419b492d369ec99553b
After pressing i it will print window-scale, go to fullscreen and print window-scale again as well as start a timer that will print window-scale a third time after 2 seconds, then quit.

→ mpv --no-config --quiet --script=~/.mpv/scripts/test.lua test-panning-24fps.mp4
[test] observed: 1
Playing: test-panning-24fps.mp4
 (+) Video --vid=1 (*) (h264 1280x720 24.000fps)
VO: [opengl] 1280x720 yuv420p
[test] window-scale 1: 1.000000
[test] window-scale 2: 1.500000
[test] observed: 1.5
[test] window-scale 3: 1.000000


Exiting... (Quit)

With -v: https://gist.github.com/Argon-/e4c27a670fde61b4ac385e2a0ef6570c

Sample files

Works for me with every file tested, including pictures (don't forget keep-open in this case). I recommend a file that does not have a window-scale of 1 when normally opened and when in fullscreen, otherwise this bug is not noticeable.

Activity

  1. ArPrt93 commented on Apr 15, 2017

    @ArPrt93

    Same here on 10.12.4 and git master, actually I noticed it too the other day and I was about to open an issue.

  2. added a commit that references this issue on Apr 15, 2017
    7e6ea5b
  3. Akemi commented on Apr 15, 2017

    @Akemi
    Member

    this should fix it. will merge tomorrow for the case anyone wants to test it beforehand.

  4. added 2 commits that reference this issue on Apr 17, 2017
    a6844e5
    f7637db
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions