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

please reconsider X11 video output #2300

Closed
vitezg opened this issue Sep 9, 2015 · 12 comments
Closed

please reconsider X11 video output #2300

vitezg opened this issue Sep 9, 2015 · 12 comments

Comments

@vitezg
Copy link

vitezg commented Sep 9, 2015

Old systems may not work well with accelerated video output drivers, please consider re-adding support for --vo=x11

System in question: FUJITSU SIEMENS ESPRIMO Mobile V6555
Video: NVIDIA Corporation MCP79 [GeForce 8200M G]
OS: Debian unstable w/Linux 4.1.6

On this hardware Xorg freezes without nouveau.noaccel=1, so acceleration is out of question (opengl, opengl-hq, xv drivers). SDL (--vo=sdl) leaks memory at a high rate, the mpv process grows to 210MB with a 1280x720 4 minutes long video. The simple X11 video output used to work well, was fast enough, stable, and did not leak memory.

Thanks!

@ghost
Copy link

ghost commented Sep 9, 2015

SDL (--vo=sdl) leaks memory at a high rate, the mpv process grows to 210MB with a 1280x720 4 minutes long video.

this was a mpv bug and was fixed in 0.1. Unless there's a new bug.

@vitezg
Copy link
Author

vitezg commented Sep 9, 2015

Must be a new/different bug then:

$ mpv --version
mpv 0.10.0 (C) 2000-2015 mpv/MPlayer/mplayer2 projects
built on UNKNOWN
ffmpeg library versions:
libavutil 54.27.100
libavcodec 56.41.100
libavformat 56.36.100
libswscale 3.1.101
libavfilter 5.16.101
libswresample 1.2.100

(this is from the mpv package in Debian unstable)

@ghost
Copy link

ghost commented Sep 9, 2015

Memory usage is pretty stable here. Did you try to disable subtitles and OSD? libass "leaks" a significant amount of memory by caching everything, and with subs and OSD combined, the cache can grow up to 1 GB.

@ghost
Copy link

ghost commented Sep 9, 2015

PS: which should happen with other video outputs, including the old vo_x11, as well.

@vitezg
Copy link
Author

vitezg commented Sep 9, 2015

This bug is clearly SDL-specific, I have never seen it with --vo=x11. With x11 and osd-level=3 I could watch hour-long movies without any problems.

Just tested again with --osd-level=0, RSS grows only to ~186 MB.
(previously the osd-level was 3, the video has no subtitles)

@ghost
Copy link

ghost commented Sep 9, 2015

You were just using it with an older libass version, which didn't have this problem yet.

@mia-0
Copy link
Member

mia-0 commented Sep 9, 2015

Also, just my 2 cents:

Maybe the freezes are just something that happens on Debian? I have not used many NVIDIA GPUs with nouveau (desktop cards only. 7600 GT, 8400 GS, 9800 GT, GT 210), but they were definitely all stable enough to use with mpv. Seems like 8200 M is quite different from other GeForce 8 GPUs though, so it’s not surprising that nouveau is having trouble.

Since NVIDIA still supports GeForce 8 GPUs on recent kernel/X.org with their legacy drivers, could you not try to get over the FREEDOM and use those instead of asking us to work around broken, unsupported and (for your GPU) unmaintained drivers?

@rr-
Copy link
Member

rr- commented Sep 9, 2015

Duplicate of #2283

@lvml
Copy link

lvml commented Sep 12, 2015

I, too, have at least one computer on which I often use -vo x11 - simply because "xv" or "opengl" do not allow to display 3840x2160 sized images on the not-so-new nvidia GPU in it (for reviewing 4k recordings off my camera) while -vo x11 does.

@ParadoxSpiral
Copy link

While I personally do not need x11, I can see why it would be useful.
x11 provided a way to view video on machines with graphic card drivers that are very unlikely to ever get fixed (at least the proprietary driver).

If you do not want that kind of thing (providing a video output that is essential for a subgroup of users), then also please remove the rpi video output. Why does the rpi get special treatment? Ok, it provides an api for this (if I understood correctly), but how is that different from w/e api that x11 uses? x11 is deprecated by xv, but is that a good thing if some users will not be able to use the software afterwards, shouldn't the software strive to be as usable on as many machines as feasable? Is the inclusion really that big of a hit to mpvs code quality/complexity when most of the code is enclosed in its own .c file?
I want 100ms faster compile time and "less complexity" in the source pls, only epsilon users use rpi anways, they can use xv (oh wait they can't..).

It does not matter (to the consumer) if x11 works around horrible drivers that should be fixed.
It does not matter (to the consumer) if their binary is epsilon bigger.
It does not matter (to the consumer) if the code is more complex, they won't read it (also thx -Ox).

What matters (to the consumer) is wether or not they can use the software.
Mpv has made a concious decision to throw out some users for an unspecified amount of time.

Now this is very different from the dvd menu support thing.
Dvd menus were broken, x11 is not.
All functionalty (as in video content) works without it, some users of x11 now have no means of performant playback.
It's just another layer of compatability, and invisible (to the consumer) complexity.

But I do agree that this output should be removed, but only after the drivers have been fixed, and good luck begging nvidia/amd.

Furtheremore as I have zero relevance to mpv and have only read a few lines I might be horribly wrong about this, if so please enlighten me.

@Gusar321
Copy link
Contributor

I'll add my voice here as well, requesting that the x11 output be brought back.

X11 was the lowest common denominator output. Whatever platform you're on, whatever the GPU situation on that platform, chances are high you'll get X running somehow. Even if it's with xf86-video-vesa or xf86-video-fbdev, two drivers than don't provide any accelerated video presentation. But they get X running, and once you're there, --vo=x11 would give you video playback.

Then there are cases where there is a GPU-specific driver, but for whatever reason its video presentation is broken in some way. The x11 output allowed you to work around the broken-ness of the driver so you could still watch video. These are usually drivers where updates are very unlikely.

Both of the above groups are now alienated. So please reconsider the removal of this vo.

Dvd menus were broken, x11 is not.

Aside from not using proper graphics (transparent rectangles were used instead), the DVD menu support actually worked very well. But the code touched a number of files and made a mess in them, so its removal provided a significant cleanup. That's not the case with X11, which was, as you noted, pretty much one file.

Another and most significant difference: There hasn't been any issue opened yet requesting the return of DVD menu support. But this is now the second issue about the X11 output. If this one too gets closed, I would not at all be surprised if a third one appears at some point.

@MerlijnWajer
Copy link

I use the most recent ARM Samsung chromebooks, and can also no longer watch video because the x11 output was removed. Please reconsider. There is no free driver for my machine that provides xv or anything similar. SDL support for mpv is masked on my platform it seems. (Gentoo Hardened, armv7). The same situation also applies to my Nokia N900 - no video output is possible anymore.

@ghost ghost closed this as completed in ebb43f5 Sep 30, 2015
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants