summaryrefslogtreecommitdiffstats
path: root/video/out
Commit message (Collapse)AuthorAgeFilesLines
* vo_direct3d: fix texture-memory sub-option, extend itwm42014-11-181-5/+13
| | | | | | | | | | This sub-option was turned into a flag when the sub-option parser was changed to the generic one (probably accidentally). Turn it into a proper choice-option. Also, adjust what the options do. Though none of this probably makes much sense; the default should work, and if it doesn't, the GPU/driver is probably beyond help.
* vo_opengl: allow setting different filters for downscalingwm42014-11-142-2/+6
|
* ao_lavc, vo_lavc: Fix crashes in case of multiple init attempts.Rudolf Polzer2014-11-121-6/+16
| | | | | | | | | | | | When initialization failed, vo_lavc may cause an irrecoverable state in the ffmpeg-related structs. Therefore, we reject additional initialization attempts at least until we know a better way to clean up the mess. ao_lavc currently cannot be initialized more than once, yet it's good to do consistent changes there as well. Also, clean up uninit-after-failure handling to be less spammy.
* encode: don't segfault when bailing out due to resolution changewm42014-11-111-1/+1
| | | | Somehow this code expects lastimg is always set.
* vo_opengl: don't reset user-set gamma when using vo_cmdlinewm42014-11-111-0/+3
|
* video/out: minor simplification to event query functionwm42014-11-092-6/+5
| | | | The "clear" parameter is confusing and useless.
* w32_common: open window menu on Alt+SpaceJames Ross-Gowan2014-11-081-0/+10
| | | | | | Since mpv doesn't call TranslateMessage, this must be done manually. Should fix #1254
* Revert "w32_common: don't override alt+space"wm42014-11-081-16/+8
| | | | | | | | This reverts commit d859549424174179768fcd0310c75823a5ff7cb1. Going to apply the alternative fix through PR #1256, which came just some seconds after pushing the reverted commit. The reverted commit was reported as not actually working.
* w32_common: don't override alt+spacewm42014-11-081-8/+16
| | | | | | Apparently, stealing this from the WM is bad form, just like with F10. Fixes #1254.
* vo_opengl: initialize renderer after setting sizewm42014-11-072-2/+4
| | | | | | | | | | | This silences the warning: video/out/gl_video.c:1091:51: runtime error: division by zero when running with clang -fsanitize=undefined. Division by zero is legal according to IEEE, but I guess clang doesn't care about standard. While triggering this warning isn't actually avoided in all cases, it's avoided in the common case and also makes people shut up about it.
* vo/x11: implement VOCTRL_GET_DISPLAY_NAMES with xrandr names (e.g., "LVDS1")Kevin Mitchell2014-11-073-2/+23
| | | | | | | | XRRGetOutputInfo contains a "name" element which corresponds to to the display names given to the user by the "xrandr" command line utility. Copy it into the xrandr_display struct for each display. On VOCTRL_GET_DISPLAY_NAMES, send a copy of the names of the displays spanned by the mpv window on.
* vo_wayland: drop redundant "const"wm42014-11-071-1/+1
|
* vo_vaapi: fix broken error checkswm42014-11-071-2/+2
|
* vo_wayland: don't use endian-specific defineswm42014-11-051-18/+22
| | | | | | | | | | | | Instead, use the native-endian alias, and switch the wayland format depending on the target platform's endian. This drops support for swapped-endian formats, but I think that is ok. Not only are the affected formats rather ancient and backwards, but using swapped formats probably does not make any sense for performance either. Untested.
* vo_opengl: minimal EGL on X11 supportwm42014-11-043-0/+171
| | | | | | Pretty useless and only good for testing. Does not include any form of GLES support.
* x11: rely on the Atom cachewm42014-11-032-15/+9
| | | | | XInternAtom() has a 64 entry hash table to avoid network accesses. Rely on this cache, instead of caching these manually.
* command: add window-minimized property (X11 only)wm42014-11-023-1/+28
| | | | | | More or less requested by #1237. Should be simple to extend this to other backends.
* command: make window-scale property observablewm42014-11-0211-0/+45
| | | | | | | | | | | | Add a generic mechanism to the VO to relay "extra" events from VO to player. Use it to notify the core of window resizes, which in turn will be used to mark all affected properties ("window-scale" in this case) as changed. (I refrained from hacking this as internal command into input_ctx, or to poll the state change, etc. - but in the end, maybe it would be best to actually pass the client API context directly to the places where events can happen.)
* cocoa: fix fullscreen delay when pausedStefano Pigozzi2014-11-011-2/+2
| | | | | | NSDisableScreenUpdates came to hunt me in the end and when mpv was paused, it did wait for a frame that never came (because of interaction with the live resizing code)!
* build: remove bundle support from wafStefano Pigozzi2014-11-011-0/+1
| | | | Use TOOLS/osxbundle.py instead. It's just better and less hacky.
* vo_opengl: draw OSD twice in 3D mode casewm42014-10-292-7/+52
| | | | | | | | | | | | | Apparently this is needed for correct 3D mode subtitles. In general, it seems you need to duplicate the whole "GUI", so it's done for all OSD elements. This doesn't handle the "duplication" of the mouse pointer. Instead, the mouse can be used for the top/left field only. Also, it's possible that we should "compress" the OSD in the direction it's duplicated, but I don't know about that. Fixes #1124, at least partially.
* cocoa: fix small leakStefano Pigozzi2014-10-271-0/+1
|
* libmpv: cocoa: fix view leak on uninitStefano Pigozzi2014-10-271-4/+6
| | | | | The code was lacking a -removeFromSuperview call which resulted in a leak on our part if the parent view in the client was not released.
* x11: fix display FPS detection for interlaced modeswm42014-10-271-1/+6
| | | | | | | | | In interlaced modes, we output fields, not complete frames, so the framerate doubles. The method to calculate this was borrowed from xrandr code. Hopefully fixes #1224.
* vo_direct3d: support nv12/nv21 directlywm42014-10-261-0/+8
|
* cocoa: perform VOCTRL_SET_UNFS_WINDOW_SIZE asyncronouslyStefano Pigozzi2014-10-241-3/+6
| | | | | | | | Apparently if resizing a NSWindow from a secondary thread Cocoa will automatically protect itself using NSViewHierarchyLock and in our case, cause a deadlock. Fixes #1210
* Set thread name for debuggingwm42014-10-192-0/+6
| | | | | | | | | | Especially with other components (libavcodec, OSX stuff), the thread list can get quite populated. Setting the thread name helps when debugging. Since this is not portable, we check the OS variants in waf configure. old-configure just gets a special-case for glibc, since doing a full check here would probably be a waste of effort.
* cocoa: reintroduce async resizeStefano Pigozzi2014-10-187-9/+71
| | | | | | | After removing synchronous libdispatch calls, this looks like it doesn't deadlock anymore. I also experimented with pthread_mutex_trylock liek wm4 suggested, but it leads to some annoying black flickering. I will fallback to that only if some new deadlocks are discovered.
* Revert "cocoa: perform init and uninit synchronously"Stefano Pigozzi2014-10-181-1/+3
| | | | This reverts commit a0ac8b6331d345748d415cf71affbe7a90e336a6.
* win32: clear window handle on destructionwm42014-10-171-0/+1
| | | | | | As I understand, otherwise, the code will try to destroy the same window again in the cleanup part of the gui_thread(), which makes no sense and is potentially dangerous.
* win32: get rid of mp_stat in the normal source codewm42014-10-171-1/+1
| | | | | | | | | | | mp_stat() instead of stat() was used in the normal code (i.e. even on Unix), because MinGW-w64 has an unbelievable macro-mess in place, which prevents solving this elegantly. Add some dirty workarounds to hide mp_stat() from the normal code properly. This now requires replacing all functions that use the struct stat type. This includes fstat, lstat, fstatat, and possibly others. (mpv currently uses stat and fstat only.)
* cocoa: allow mouse events to bubble up with no-input-cursorStefano Pigozzi2014-10-173-24/+114
| | | | | Previously we didn't report events to the core, but still prevented the events to travel on the responder chain.
* vo_opengl: fix wrong commentswm42014-10-161-2/+2
| | | | | | The previous commit was actually incorrect, and the change had absolutely no effect. The two formats are (fortunately) the same. I'm probably too tired.
* vo_opengl: fix theoretical format mismatch issuewm42014-10-161-4/+4
| | | | | | | | | This would have been wrong for hw decoders which pass us NV12 or NV21. The format the GL shader filter chain gets is stored in p->image_desc, while p->image_format still contains the "real" input format (which in case of hw decoding is an opsque hw accel format). Since no hw decoder did this, this is really just a theoretical fix and doesn't fix any actual bugs.
* cocoa: perform init and uninit synchronouslyStefano Pigozzi2014-10-161-3/+1
| | | | | This is slightly safer and without the resize redraw, should not cause any deadlock.
* x11: don't wait for asynchronous X resizing with window-scalewm42014-10-131-3/+4
| | | | | | | | | | | | | | | Instead of letting the window-scale property return the old value until X11 actually executed the resize, just set the new assumed internal window size immediately. This avoids a "lag" between setting and reading the window-scale property, like OSD controls typically do. Remove the additional calls from vo_x11_highlevel_resize() - they're pointless and slightly wrong, and resize events will take care of updating these things correctly anyway. Fixes #1176. ("window-scale" works via VOCTRL_[S|G]ET_UNFS_WINDOW_SIZE.)
* gl_x11: distinguish missing GLX and too old GLX versionswm42014-10-121-3/+5
| | | | | | This probably led to confusing output. CC: @mpv-player/stable
* libmpv/cocoa: allow clients to use mpv event systemStefano Pigozzi2014-10-122-25/+28
| | | | | | | | | | This allows mpv's view to take key and send events to mpv's core. To set key status correctly, clients must call -[NSWindow selectNextKeyView:] during reconfig on the main thread. All is 'documented' in the cocoabasic example. If someone knows a better way to handle giving key to the embedded view, let me know!
* cocoa: remove usage of Objective-C categoriesStefano Pigozzi2014-10-124-88/+37
| | | | | Objective-C categories need special linker flags from the user when statically linking (-ObjC LDFLAG), so make everyone's life simpler and remove them.
* x11: don't wait until window is destroyedwm42014-10-111-5/+0
| | | | | | | | | | This can hang if the window was destroyed externally (or that's what I suspect happens), and we somehow didn't receive the DestroyNotify event. I'm not sure why we wouldn't receive this event (since it should just be in the xlib event queue), but on the other hand there's no real need to wait for window destruction. This essentially reverts 97fc74e2.
* Add some missing "const"swm42014-10-101-1/+1
| | | | | | | The one in msg.c was mistakenly removed with commit e99a37f6. I didn't actually test the change in ao_sndio.c (but obviously "ap" shouldn't be static).
* cocoa: post keydown and keyup events without event monitorStefano Pigozzi2014-10-093-0/+14
| | | | | Our code worked under the assumption that the event monitor is always active and we did remove the keydown and keyup overrides from our cocoa view.
* cocoa: fix 'uninitalized' accessStefano Pigozzi2014-10-091-9/+7
| | | | | I think this doesn't make a difference, since in Objective-C nil responds as a NullObject, but better not depend on this crappy language feature.
* x11: fix inverted conditionwm42014-10-091-2/+3
| | | | | | | Worryingly wrong. Fixes #1162. Also fix another issue (window title was set anyway), which was why I didn't notice this and testing it seemed to be fine.
* client API: rename --input-x11-keyboard to --input-vo-keyboardwm42014-10-091-1/+1
| | | | | Apparently we need this for Cocoa too. (The option was X11 specific in the hope that only X11 would need this hack.)
* cocoa: allow to embed into an arbitrary NSViewStefano Pigozzi2014-10-085-18/+33
| | | | | Basically add if guards on all the problematic features. I'm still thinking about a better way to handle this, but for the time being, this will do.
* x11: disable various features when embedding the windowwm42014-10-071-3/+5
|
* cocoa: try to fix sizing bugs on retina displaysStefano Pigozzi2014-10-061-2/+2
| | | | untested, no hardware.
* cocoa: fix mouse autohideStefano Pigozzi2014-10-051-1/+1
| | | | broken in 547b62f
* cocoa: remove a debug commentoStefano Pigozzi2014-10-051-1/+1
| | | | fixup previous commit
* cocoa: separate video view and events viewStefano Pigozzi2014-10-056-18/+90
|
* cocoa: fix fullscreen with bundleStefano Pigozzi2014-10-051-1/+1
|
* cocoa: readd some function callsStefano Pigozzi2014-10-051-1/+3
|
* cocoa: actually reset the event flagsStefano Pigozzi2014-10-051-0/+1
|
* cocoa: remove some useless flagsStefano Pigozzi2014-10-051-19/+10
|
* cocoa: disable some features when embedding in another windowStefano Pigozzi2014-10-051-23/+25
| | | | ontop, fullscreen and window title change to be precise
* cocoa: remove --fs-missioncontrolStefano Pigozzi2014-10-053-59/+4
| | | | | | | This is the first of a series of commits that will change the Cocoa way in a way that is easily embeddable inside parent views. To reach that point common code must avoid referencing the parent NSWindow since that could be the host application's window.
* cocoa: fix some pointer casts to be 32bit safeStefano Pigozzi2014-10-051-1/+1
| | | | credits: wm4
* cocoa/libmpv: allow to embed mpv GL view in another windowStefano Pigozzi2014-10-053-30/+81
| | | | | | | | | | | | | | | | | | | This is just temporary code but is a good base for future work (and baby steps are required for these changes). The 'final destination' is embedding the video view into any NSView but that requires some more work (the mechanism will be the same: pass the view's pointer casted to int64_t through -wid). For instance we will need to remove as much usage of the window instance as possible, and use nil guards where not possible. For this reason I will remove stuff like the mission control fullscreen feature (it's a cute feature but annoying to support and quite limited, go make your GUIs), and a way to lookup the current screen directly from the NSView absolute coordinates (this is needed for ICC detection mostly, and reporting back the screen to mpv's core). Moreover the current view.m will need to be separated into 2 views: the actual video view that will be embedded, and a parent view that will not be embedded and will be responsibile for tracking events.
* cocoa: simplify the config code and run it on the main threadStefano Pigozzi2014-10-051-9/+1
| | | | | | This could be dangerous because we initialize the window asynchronously and return immediately from config, but since the OpenGL context is already created, this seems to work correctly and doesn't cause weird deadlock cases.
* options: add --no-keepaspect-windowwm42014-10-042-3/+3
| | | | Seems silly, but was requested.
* cocoa: don't reset presentation options on uninitStefano Pigozzi2014-10-041-1/+0
| | | | | | This doesn't look to be needed anymore. Fullscreening with both the NSView and the NSWindow API works correctly. I guess this was forgotten in from older code which changed presentation options directly for going fullscreen.
* cocoa: only call resize for view changing frameStefano Pigozzi2014-10-042-5/+2
|
* cocoa: remove pointless drawRectStefano Pigozzi2014-10-041-7/+0
| | | | | | Apparently it causes deadlocks, and at the moment it does nothing. Fixes #778
* cocoa: make fullscreening look like an atomic operationStefano Pigozzi2014-10-041-0/+16
| | | | | | | | | | | At the moment when you fullscreen mpv there is a very small time interval where the fullscreen windows is semi-transparent. Apparently whem moving the view to another parent it's better to make Cocoa not draw anything globally. An Apple engineer said it, so it must be correct: http://www.cocoabuilder.com/archive/cocoa/142020-preventing-flicker-on-moving-nsview-to-different-superview.html I know I will regret this in the future.
* cocoa: make resizing wake the vo threadStefano Pigozzi2014-10-041-0/+1
|
* cocoa: remove dead codeStefano Pigozzi2014-10-042-19/+0
|
* x11: stupid workaround for XMonadwm42014-10-041-1/+5
| | | | | | | | --x11-netwm=yes now forces NetWM fullscreen, while --x11-netwm=auto (detect whether NetWM fullsctreen support is available) is the old behavior and still the default. See #888.
* cocoa: move to a simpler threading modelStefano Pigozzi2014-10-047-114/+37
| | | | | | | | | | | | | | Unfortunately using dispatch_sync for synchronization turned out to be really bad for us. It caused a wide array of race conditions, deadlocks, etc. Moving to a very simple mutex. It's not clear to me how to do liveresizing with this, for now it just flickers with is unacceptable (maybe I'll draw black instead). This should fix all the threading cocoa bugs. Reopen if it's not the case! Fixes #751 Fixes #1129
* video: return responsibility of video redraw back to playloopwm42014-10-032-3/+20
| | | | | | | | | | | | | | | | | | | | | | | | When the VO was moved it its own thread, responsibility for redrawing was given to the VO thread itself. So if there was a condition that indicated that redrawing was required, like expose events or certain VOCTRLs, the VO thread was redrawing itself. This worked fine, but there are some corner cases where this works rather badly. E.g. if I fullscreen the player and hit panscan controls with mpv's default autorepeat rate, playback stops. This happens because the VO redraws itself after every panscan change command. Running each (repeated) command takes so long due to redrawing and (involuntary) waiting on vsync, that it never leaves the input processing loop while the key is held down. I suspect that in my case, redrawing in fullscreen mode just gets slow enough that it takes 2 vsyncs instead of 1 on average, and the processing time gets larger than the autorepeat delay. Fix this by taking redraw control from the VO, and instead let the playloop issue a "real" redraw command to the VO if needed. This basically reverts redraw handling to what i