summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vf_vapoursynth: add debug message when returning error from GetFramewm42014-10-131-0/+1
| | | | | Some filters still (or will) behave badly on these errors, so explicitly log when it happens.
* 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.)
* vf_vapoursynth: don't error if invoke() doesn't return a clipwm42014-10-121-3/+2
| | | | | Not all functions are for creating filters. Consider for example LoadPlugin.
* vf_vapoursynth: resolve paths relative to home/configwm42014-10-121-0/+3
| | | | | This affects the script filename passed to the filter. Resolve "~" (and some other variants) as described in the "Paths" section of mpv.rst.
* gl_x11: distinguish missing GLX and too old GLX versionswm42014-10-121-3/+5
| | | | | | This probably led to confusing output. CC: @mpv-player/stable
* vf_vapoursynth: add standalone Lua scriptingwm42014-10-122-1/+262
|
* vf_vapoursynth: abstract scripting backendwm42014-10-121-28/+87
| | | | | | In theory, vsscript should be doing it, but it's not there yet, neither did there seem to be any interest in making it flexible enough to handle more than 1 scripting language.
* 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.
* vf_vapoursynth: return dummy frames if frames are requested during initwm42014-10-111-1/+12
| | | | | | An attempt at fixing #1168. I see black frames flashing, so it's certainly not perfect.
* vf_vapoursynth: factor stuffwm42014-10-111-13/+25
|
* vf_vapoursynth: when seeking, recreate only if it's already createdwm42014-10-111-1/+2
|
* 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.
* vf_vapoursynth: fail gracefully if filter init requests frameswm42014-10-111-0/+10
| | | | | | | | | | | | | | | | | Some VS filters will requests frames from their parent filters while they're initialized. Thy do this in a blocking manner, and initialization will not succeed until the frame request is satisfied. This deadlocked mpv, because we can feed frames to the filter only after initialization is finished. Return an error instead of deadlocking. Note that we (probably) can handle frames being requested during init fine, as long as the requests don't block initialization. But we can distinguish this situation, and a simple test seems to indicate VS usually doesn't do this. See #1168.
* 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.)
* vf_lavfi: proper rounding for lavfi->mpv aspect ratiowm42014-10-091-2/+3
| | | | Or so I think. Not like it matters anyway.
* 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.
* vf_lavfi: fix compilation failurewm42014-10-081-1/+0
| | | | | | Apparently this fails to compile with clang6. Patch by someone else. CC: @mpv-player/stable
* 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
|
* vf_stereo3d: fix "auto" input format with libavAlessandro Ghedini2014-10-041-1/+1
|
* 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 it was before moving the VO to a thread. CC: @mpv-player/stable
* x11: fix --wid=0wm42014-10-021-0/+1
| | | | | | | | | | Another fallout resulting from the changes whether or not to wait for mapping the window. In this case, it obviously makes no sense to wait for mapping, because the root window is always mapped. Mapping will never happen, and it would wait forever. Fixes #1139. CC: @mpv-player/stable
* vo_vdpau: don't try to create surfaces of size 0wm42014-10-012-11/+11
| | | | | | | | | | | | | | | | | | | | | | At least on kwin, we decide to proceed without waiting for the window being mapped (due to the frame exts hack, see commit 8c002b79). But that leaves us with a window size of 0x0, which causes VdpOutputSurfaceCreate to fail. This prints some warnings, although vo_vdpau recovers later and this has no other bad consequences. Do the following things to deal with this: - set the "known" window size to the suggested window size before the window is even created - allow calling XGetGeometry on the window even if the window is not mapped yet (this should work just fine) - make the output surface minimum size 1x1 Strictly speaking, only one of these would be required to make the warning disappear, but they're all valid changes and increase robustness and correctness. At no point we use a window size of 0x0 as magic value for "unset" or unknown size, so keeping it unset has no purpose anyway. CC: @mpv-player/stable
* w32_common: quit event loop on destroyJames Ross-Gowan2014-09-301-6/+11
| | | | | | | | | | | | When embedding, if the parent window is destroyed, it will cause mpv's window to be destroyed as well. Since WM_USER wakeups are sent to the window, destroying the window will prevent wakeups and cause uninit to hang. Fix this by quitting the event loop on WM_DESTROY. Events should only be processed for the lifetime of the window, from CreateWindowEx to WM_DESTROY. After the event loop is finished, mp_dispatch_queue_process can handle any remaining requests.
* vd_lavc: fix a small memory leak on init errorwm42014-09-292-8/+5
| | | | | The private context wasn't free'd when codec init failed. Restructure the code so that it can't happen.
* x11: always wait for mapped when using --widwm42014-09-291-2/+3
| | | | | | | Might help with embedding with mozplugger. I can't confirm whether it fixes the issue. See #1090.
* client API, X11: change default keyboard input handling againwm42014-09-281-12/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | Commit 64b7811c tried to do the "right thing" with respect to whether keyboard input should be enabled or not. It turns out that X11 does something stupid by design. All modern toolkits work around this native X11 behavior, but embedding breaks these workarounds. The only way to handle this correctly is the XEmbed protocol. It needs to be supported by the toolkit, and probably also some mpv support. But Qt has inconsistent support for it. In Qt 4, a X11 specific embedding widget was needed. Qt 5.0 doesn't support it at all. Qt 5.1 apparently supports it via QWindow, but if it really does, I couldn't get it to work. So add a hack instead. The new --input-x11-keyboard option controls whether mpv should enable keyboard input on the X11 window or not. In the command line player, it's enabled by default, but in libmpv it's disabled. This hack has the same problem as all previous embedding had: move the mouse outside of the window, and you don't get keyboard input anymore. Likewise, mpv will steal all keyboard input from the parent application as long as the mouse is inside of the mpv window. Also see issue #1090.
* Fix build with libavfilter disabledwm42014-09-281-1/+1
| | | | Although I'm not sure why we even support this.
* video: change automatic rotation and 3D filter insertionwm42014-09-272-11/+111
| | | | | | | | | | | | | | | | | | | | | We inserted these filters with fixed parameters, which was ok. But this also didn't change image parameters for the filters down the filter chain and the VO. For example, if rotation by 90° was requested by the file, we would insert a filter and rotate the video, but the VO would still receive image parameters that direct rotation by 90°. This wasn't a problem, but it could become one. Fix this by letting the filters automatically pick up the image params. The image params are reset on application. (We could probably also always try to apply and reset image params in a filter, instead of having special "auto" parameters. This would probably work, and video.c would insert a "rotate=0" filter. But I'm afraid this would be confusing and the current solution is cosmetically slightly nicer.) Unfortunately, the vf_stereo3d.c change turned out a big mess, but once the "internal" filter is fully replaced with libavfilter, most of this can be radically simplified.
* vf_lavfi: make chaining from other filters more flexiblewm42014-09-273-26/+45
| | | | | | | | | Some filters exists only to create a specific lavfi graph. Allow these filters to reset the graph exactly on reconfig, and allow them to modify some image parameters too. Also make vf_lw_update_graph() behave like vf_lw_set_graph() - they had a subtitle difference with filter==NULL. Useful for the following commit.
* Remove mpbswap.hwm42014-09-252-4/+4
| | | | | | This was once central, but now it's almost unused. Only vf_divtc still uses it for extremely weird and incomprehensible reasons. The use in stream.c is trivial. Replace these, and remove mpbswap.h.
* video: remove BITMAPINFOHEADER from internal demuxer APIwm42014-09-251-14/+7
| | | | | | | | | | MPlayer traditionally did this because it made sense: the most important formats (avi, asf/wmv) used Microsoft formats, and many important decoders (win32 binary codecs) also did. But the world has changed, and I've always wanted to get rid of this thing from the codebase. demux_mkv.c internally still uses it, because, guess what, Matroska has a VfW muxing mode, which uses these data structures natively.
* vf_vapoursynth: make it possible to get filter output incrementallywm42014-09-231-27/+77
| | | | | | | | | | | | | | | | | Until now, we always required the playback core to decode a new frame to get more output from the filter. That seems to be completely unnecessary, because filtered results may arrive before that. Add a filter_out callback, and restructure the code such that it can return any filtered frames, or block if it hasn't read at least one frame. In the worst case, it still can happen that bursts of input requests and output requests happen. (This commit tries to reduce burst-like behavior, but it's not entirely possible due to the indeterministic nature of VS threading.) This is a similar change as with 95bb0bb6.
* video: fix redrawing when pausing after framedropwm42014-09-211-1/+1
| | | | | | | When pausing after a frame was just dropped, we're logically at the dropped frame, and thus should redraw the dropped frame. This was implemented, but didn't work after unpausing for the second time, because of a minor logic bug.
* video: fix some vo_direct3d crashes due to FFmpeg nonsensewm42014-09-211-1/+2
| | | | | | | | | | | | For incomprehensible reasons, AV_PIX_FMT_GRAY8 (and some others) have a palette. This literally makes no sense and this issue has bitten us before, but it is how it is. This also caused a crash with vo_direct3d: this mapped a texture as IMGFMT_Y8 (i.e. AV_PIX_FMT_GRAY8), and when copying this, it tried to copy the non-existent palette. Fixes #1113.
* vo_vdpau: better integration with the generic framedrop codewm42014-09-204-16/+29
| | | | | | | | | | | | | | | | | | | | vo_vdpau uses its own framedrop code, mostly for historic reasons. It has some tricky heuristics, of which I'm not sure how they work, or if they have any effect at all, but in any case, I want to keep this code for now. One day it might get fully ported to the vo.c framedrop code, or just removed. But improve its interaction with the user-visible framedrop controls. Make --framedrop actually enable and disable the vo_vdpau framedrop code, and increment the number of dropped frames correctly. The code path for other VOs should be equivalent. The vo_vdpau behavior should, except for the improvements mentioned above, be mostly equivalent as well. One minor change is that frames "shown" during preemption are always count as dropped. Remove the statement from the manpage that vo_vdpau is the default; this hasn't been the case for a while.
* vo_vdpau: fix confusion around vsync_intervalwm4