Jump to content

Active video has small gap on side and bottom of screen


Recommended Posts

arrbee99
Posted

Wow, thats some serious memory. Forgot about that. So yes seems fine, though I mostly use Android stuff, with more occasional use for Theater, hence testing has been less than rigorous...

PrincessClevage
Posted (edited)

@ Can you try this version as an alternate:

https://www.dropbox.com/s/5ays1lha4mmfi0o/theater1.zip?dl=0

 

At the moment you won't be able to drag the window and move it. I just want to know if you can see the video OSD or not. Thanks.

OSD still not showing and some artifacts when camera view is panning Edited by PrincessClevage
Guest asrequested
Posted (edited)

@ Can you try this version as an alternate:

https://www.dropbox.com/s/5ays1lha4mmfi0o/theater1.zip?dl=0

 

At the moment you won't be able to drag the window and move it. I just want to know if you can see the video OSD or not. Thanks.

 

Same result. No overlay and it messes with my display when in fulllscreen. Also, the remote control doesn't work. I can still resize the window when playing, and if I do that, the overlay then shows.

Edited by Doofus
Posted (edited)

No problem for me, no artefact or overlay issue after two tv shows yesterday

Edited by nicko84
Posted

Same result. No overlay and it messes with my display when in fulllscreen. Also, the remote control doesn't work. I can still resize the window when playing, and if I do that, the overlay then shows.

 

Does the overlay show when not fullscreen?

Guest asrequested
Posted

Does the overlay show when not fullscreen?

 

Yes. If I play something when it's windowed, it works just fine. The overlay is there and it doesn't mess my display up. But as soon as I make it full screen while playing, it fritzes. Meaning the picture flickers a bit, the mouse disappears for a few seconds and the controls are gone.

Guest asrequested
Posted

A quick note for anyone testing this build. If you test playing an MPEG2 video, you won't have any hardware acceleration. mpv has disabled that as the default action. It can easily be re-enabled, so don't think there is something wrong :)

Posted

Yes. If I play something when it's windowed, it works just fine. The overlay is there and it doesn't mess my display up. But as soon as I make it full screen while playing, it fritzes. Meaning the picture flickers a bit, the mouse disappears for a few seconds and the controls are gone.

 

The difference is it's using true full screen mode instead of mimicking it by positioning the window. This seems to suggest a limitation of not allowing the semi-transparent UI on top of the video. Have you enabled anything in your graphics drivers, the app video settings, or mpv.conf that might be causing this? It's as if the video is in exclusive mode and we can't put anything on top of it.

Posted

For instance, you're not using this flag, are you?

--ontop
Makes the player window stay on top of other windows.

On Windows, if combined with fullscreen mode, this causes mpv to be treated as exclusive fullscreen window that bypasses the Desktop Window Manager.
Guest asrequested
Posted

The difference is it's using true full screen mode instead of mimicking it by positioning the window. This seems to suggest a limitation of not allowing the semi-transparent UI on top of the video. Have you enabled anything in your graphics drivers, the app video settings, or mpv.conf that might be causing this? It's as if the video is in exclusive mode and we can't put anything on top of it.

 

My GPU settings are all at default, and I tried playing with no mpv.conf at all, and ran it at default. I have a feeling it's because I'm running in HDR10, which requires a full frame. Gimme a minute and I'll test that...

Guest asrequested
Posted

I stand corrected. It's because I'm using the opengl api. That's bad! If anyone wants to use cuda or nvdec, they won't be able to. They require the opengl api to be enabled, and that's all I use. 

Posted

how exactly are you doing that?

Posted

I'm wondering if we ought to proceed with this change anyway for the greater good. You can easily change one line in main.js to have it use the window positioning rather than true fullscreen mode. Just until we can auto-detect that you're using opengl and then switch it anyway.

Guest asrequested
Posted

I'm wondering if we ought to proceed with this change anyway for the greater good. You can easily change one line in main.js to have it use the window positioning rather than true fullscreen mode. Just until we can auto-detect that you're using opengl and then switch it anyway.

 

hmmmm.....that will break the use of cuda and nvdec, and in some cases, nvdec-copy and cuda-copy. I can squeeze by with crappy d3d for a little while, but there are people using cuda deinterlacing, so it'll break that, too. You'll need to fix this pretty quickly, if you move forward with this. There will be complaints.

Posted

It would only apply to those using a custom mpv build though right?

 

Interesting question, if you're saying it requires a full frame, then if the window is not truly full screen are you sure you're actually getting what you want?

 

Another thing we could do is have it come out of full screen mode when the osd is open.

Guest asrequested
Posted

It would only apply to those using a custom mpv build though right?

 

Interesting question, if you're saying it requires a full frame, then if the window is not truly full screen are you sure you're actually getting what you want?

 

Another thing we could do is have it come out of full screen mode when the osd is open.

 

No, this will negate any use of cuda and nvdec. The auto function always goes to the d3d api. I just ran some tests. Using api=auto, and choosing cuda-copy or nvdec-copy, playing some of my media, hwa was disabled. On Windows, we would pretty much have to use d3d11va or DXVA2. You may get complaints about deinterlacing. I can work around it, but others...??

 

I mentioned full frame in reference to HDR10 in windows. I ruled that out. It's not part of the problem. As long as it covers the screen, I'm happy.

 

I don't think that will work. I think you're going to have to change several other things to make it work for everyone. You'll need to change deinterlace=yes, to the yadif config, for one. And remove nvdec-copy. Cuda-copy might be ok....??

Guest asrequested
Posted

I want to stress that I want to use the opengl api

PrincessClevage
Posted (edited)

I have remove all entries from mpv.conf and also changed hwa to auto and still no osd when pressing down on the remote like usual. I should note that the true full screen mode seems to display HDR colour in a much better manner (perhaps ET had never display correct HDR as it was never in true full screen mode?)

Edited by PrincessClevage
Guest asrequested
Posted

Try putting this in your mpv.conf

gpu-api=auto
PrincessClevage
Posted

Try putting this in your mpv.conf

gpu-api=auto
removed all lines except for gpu-api=auto and still no osd
Guest asrequested
Posted

removed all lines except for gpu-api=auto and still no osd

 

That's weird. Try this

gpu-api=auto
hwdec=auto
Guest asrequested
Posted

How have you configured the settings in Theater?

PrincessClevage
Posted (edited)

How have you configured the settings in Theater?

mpv.conf in C:\Users\Username\AppData\Roaming\Emby-Theater\system\x64\mpv

And also here

C:\Users\Username\AppData\Roaming\mpv

Edited by PrincessClevage

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...