Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong display resolution #6304

Closed
erasmux opened this issue Nov 9, 2018 · 6 comments
Closed

Wrong display resolution #6304

erasmux opened this issue Nov 9, 2018 · 6 comments
Labels
meta:no-bug priority:invalid:broken broken file/hardware/drivers/etc

Comments

@erasmux
Copy link

erasmux commented Nov 9, 2018

mpv version and platform

Windows 7 x64
mpv-x86_64-20181103-git-880c59d (first example also verified with mpv-x86_64-20181002)

Reproduction steps

Run mpv on specific video files (i.e. sample files attached below) with default config and no additional steps.

Expected behavior

The display resolution should match the resolution of the video stream. Screenshots taken should be of the exact resolution of the input video.

Actual behavior

The display resolution is almost the same but a few pixels off either in the width or the height.

For the test.mkv the actual video size is 1920x1040 (as confirmed by ffmpeg/ffprobe, mediainfo and the pixel width/height in the mpv log). The display resolution in the mpv log is 1928x1040 and so is the inside of the mpv player window and the screenshots mpv produces.

For the test2.mkv the actual video size is 1280x688. The display resolution in the mpv log is 1273x688. The mpv player windows size and the screenshots size is 1280x691 (a third different resolution?!).

Is there some logical explanation for this? Is this a mpv bug?

Log file

https://0x0.st/slNp.txt (for test.mkv)
https://0x0.st/slNO.txt (for test2.mkv)

Sample files

test.mkv
test2.mkv

@haasn
Copy link
Member

haasn commented Nov 9, 2018

Can reproduce. Will investigate.

@haasn
Copy link
Member

haasn commented Nov 9, 2018

Sample file 1 has a tagged PAR of 241:240. Given this, mpv is doing the correct thing.

Similarly, sample file 2 has a tagged PAR of 1273:1280. The only thing that's weird here is that mpv logs 1273x688 as the display resolution, when I would have expected 1280x691 here as well. Fortunately, both the VO and the screenshot code seem to be doing the right thing here, so I'm closing this as not a bug.

@haasn haasn closed this as completed Nov 9, 2018
@haasn haasn added meta:no-bug priority:invalid:broken broken file/hardware/drivers/etc labels Nov 9, 2018
@haasn
Copy link
Member

haasn commented Nov 9, 2018

I should perhaps point out that if these are not your files and you don't want to bother retagging them, you can work around this by using --video-aspect=no to ignore the aspect ratio tags.

@erasmux
Copy link
Author

erasmux commented Nov 9, 2018

@haasn
Thanks for looking into this, I see what you mean about the PAR so mpv adjustment of the display resolution seems correct.

What about taking screenshots? At least for my usage, I want a screenshot of the video source frame and not of the mpv display.
Could it be related to this: #5619

Btw the --video-aspect=no is indeed helpful for my case, so thanks. This also works around the screenshot issue (if indeed it is an issue).

@haasn
Copy link
Member

haasn commented Nov 9, 2018

Yes, it is indeed very much related to that issue. In particular, that issue demonstrates that this is the preferred behavior. Anamorphic video is a thing and screenshots of anamorphic sources being scaled is what the normal user expects.

If you have a specific reason for wanting the ability to take "raw" screenshots of the source pixels of an anamorphic video, without affecting the way that anamorphic video is displayed on-screen, it might be worth adding some sort of option to the screenshot command which enables you to bypass aspect ratio correction for the screenshot. But this seems like a rather obscure use case so one could argue you'd be better off using e.g. ffmpeg or vo_image to grab frames in this case, or simply setting --video-aspect=no.

@erasmux
Copy link
Author

erasmux commented Nov 9, 2018

Yes, I am talking about taking "raw" screenshots of the source pixels. But I think you are right, a more natural tool for such extractions would be ffmpeg and such. I "abuse" mpv for this only out of convenience, as I can select the frame visually and generate a screenshot with a single stroke. For this the --video-aspect=no flag seems like a clean solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta:no-bug priority:invalid:broken broken file/hardware/drivers/etc
Projects
None yet
Development

No branches or pull requests

2 participants