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

stats.lua when watching 3D. Different problems with gpu.next vs gpu #12462

Open
netExtra opened this issue Sep 21, 2023 · 11 comments
Open

stats.lua when watching 3D. Different problems with gpu.next vs gpu #12462

netExtra opened this issue Sep 21, 2023 · 11 comments

Comments

@netExtra
Copy link

netExtra commented Sep 21, 2023

Important Information

When watching 3D each frame is divided into 2 sub-frames (up/down or side/side). See attached photos.

vo=gpu
When using vo=gpu, each sub-frame has a copy of stats.lua which means then when 3D is enabled they effectively join together to become one stats.lua output. But the scaled resolution is incorrect. For 1080p it correctly reports each division as being 1920x540 but when they are joined into one frame this should now read 1920x1080.

vo=gpu-next
When using vo=gpu-next, there is only one stats display across both sub-frames. Effective treating the display as one screen. As such it correctly reports the scaled resolution as 1920x1080. But when 3d is enabled and both sub-screens join into one screen the stats become unreadable.

  • mpv version - Any MPV version
  • Windows Version - Windows 10
  • Source of the mpv binary - Any mpv version

Screenshot below shows:

  • stats.lua when vo=gpu
gpu stats lua

Screenshot below shows:

  • stats.lua when vo=gpu-next
gpu-next stats lua

Reproduction steps

Described in section Important Information

Expected behavior / Prefered behaviour

vo=gpu-next
Same as vo=gpu currently works but with fixed scaled resolution. I would prefer this because the anti-aliasing works soo much better when using identical shaders in mpv.

vo=gpu
Since enabling 3D is outside the scope or control of mpv, the easiest option may be to set the scaled resolution when vo=gpu to the total screen size as it is currently done in vo=gpu-next.

Actual behavior

vo=gpu: 2 sub frames each with stats.lua. But incorrect scale resolution when 2 sub-frames joined in 3D. See attached photo above.

vo=gpu-next: 1 stats.lua report which becomes a mess when watching in 3D. Unfortunately it is not possible to replicated how bad it looks in 3D in a 2D photo but FWIW I've attached a screenshot.

3D output in 2D

Log file

Is this required?

@netExtra
Copy link
Author

Just need some help on where to look to "try" and fix this. I couldn't locate the relevant code.

@netExtra
Copy link
Author

Sorry but any help or pointers so I can look into this myself?

@haasn
Copy link
Member

haasn commented Oct 19, 2023

I suppose the first thing to figure out would be whether this should be handled by mpv or by libplacebo. Does vo_gpu generate the OSD twice (once per eye), or does it generate the OSD once (at halved resolution) and paint it twice?

@netExtra
Copy link
Author

netExtra commented Oct 19, 2023

I suppose the first thing to figure out would be whether this should be handled by mpv or by libplacebo. Does vo_gpu generate the OSD twice (once per eye), or does it generate the OSD once (at halved resolution) and paint it twice?

Well the fact that it reports the halved resolution for each eye would suggest the latter. But who knows? That's my first problem. I just want to know where this output is being generated. Something is calling stats.lua then formating that information differently for vo_gpu. This is a little strange because I would have assumed the same code would have been reused for gpu-next.

@haasn
Copy link
Member

haasn commented Oct 19, 2023

A quick glance at mpgl_osd_generate reveals a lot of code related to stereo3D support.

Presumably that code needs to be lifted out of vo_gpu and into some common place where both VOs can access it. Or maybe even the common OSD code.

@netExtra
Copy link
Author

netExtra commented Oct 20, 2023

A quick glance at mpgl_osd_generate reveals a lot of code related to stereo3D support.

Presumably that code needs to be lifted out of vo_gpu and into some common place where both VOs can access it. Or maybe even the common OSD code.

TBH I wasn't expecting it to look like this. I just naively assumed that stats.lua was being called. Couldn't be more wrong.

@netExtra
Copy link
Author

netExtra commented Nov 23, 2023

A quick glance at mpgl_osd_generate reveals a lot of code related to stereo3D support.

Presumably that code needs to be lifted out of vo_gpu and into some common place where both VOs can access it. Or maybe even the common OSD code.

Hi. I saw the comment about changes to stats.lua and I was hoping this was one of them :) Will it be possible to include this change so that the vo=gpu-next output matches the the soon to be retired vo=gpu output for 3D?
Thanks.

@netExtra
Copy link
Author

netExtra commented Dec 2, 2023

Will the recent changes to stats.lua make it easier for the gpu-next stats output to match the vo=gpu stats output when viewed in 3D?

@llyyr
Copy link
Contributor

llyyr commented Dec 2, 2023

No, and if any PR does that then it'll probably ping this issue.

@netExtra
Copy link
Author

netExtra commented Dec 2, 2023

Thanks for the update. I guess I will just have to put up with not being able to use stats in 3D or switch back to vo=gpu which kind of defeats the purpose of having gpu-next.

@netExtra
Copy link
Author

netExtra commented Mar 3, 2024

Will gpu-next get updated to match the 3D stats format of vo=gpu? Asking for a friend :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants