summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* 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_lavfi: fix compilation failurewm42014-10-111-1/+0
| | | | | | Apparently this fails to compile with clang6. Patch by someone else. CC: @mpv-player/stable
* vf_stereo3d: fix "auto" input format with libavAlessandro Ghedini2014-10-111-1/+1
|
* video: return responsibility of video redraw back to playloopwm42014-10-112-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-111-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-112-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_intervalwm42014-09-201-10/+9
| | | | | | | vc->vsync_interval and vsync_interval should be the same value, but actually vc->vsync_interval was updated after vsync_interval was initialized. This was probably not intended. Fix this by removing the duplicate local variable. There were probably no bad effects.
* wayland: use reported rete and delayAlexander Preisinger2014-09-191-2/+27
| | | | | If native-keyrepeat is true then we set the rate and delay reported by the compositor.
* vf_lavfi: fetch output frames incrementallywm42014-09-181-22/+24
| | | | | | | Uses the new mechanism introduced in the previous commit. Depending on the actual filter, this distributes CPU load more evenly over time, although it probably doesn't matter.
* video/filter: allow better dataflowwm42014-09-182-2/+20
| | | | | | | | | Consider a filter which turns 1 frame into 2 frames (such as an deinterlacer). Until now, we forced filters to produce all output frames at once. This was done for simplicity. Change the filter API such that a filter can produce frames incrementally.
* video: wake up core as soon as possiblewm42014-09-161-0/+1
| | | | | | | | There's no reason to let the core wait until the frame is done displaying. In practice, the core normally didn't need this additional wakeup, and the VO was quick enough to fetch the new frame, before the core even attempted to queue a new frame. But it wasn't entirely clean, and the correct wakeup handling might matter in some cases.
* vo_wayland: remove unnecessary checkAlexander Preisinger2014-09-161-19/+10
| | | | | buffer_pool_get_front now returns always a valid buffer. No need for corner cases.
* wayland/buffer: use buffer macros consistentlyAlexander Preisinger2014-09-161-3/+3
|
* x11: if the WM supports _NET_FRAME_EXTENTS, don't wait for mapwm42014-09-152-3/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Some window managers can prevent mapping of a window as a feature. i3 can put new windows on a certain workspace (with "assign"), so if mpv is started on a different workspace, the window will never be mapped. mpv currently waits until the window is mapped (blocking almost all of the player), in order to avoid race conditions regarding the window size. We don't want to remove this, but on the other hand we also don't want to block the player forever in these situations. So what we need is a way to know when the window manager is "done" with processing the map request. Unfortunately, there doesn't seem to be a standard way for this. So, instead we could do some arbitrary communication with the WM, that may act as "barrier" after map request and the "immediate" mapping of the window. If the window is not mapped after this barrier, it means the window manager decided to delay the mapping indefinitely. Use the _NET_REQUEST_FRAME_EXTENTS message as such a barrier. WMs supporting this message must set the _NET_FRAME_EXTENTS property on the mpv window, and we receive a PropertyNotify event. If that happens, we always continue and cancel waiting for the MapNotify event. I don't know if this is sane or if there's a better mechanism. Also, this works only for WMs which support this message, which are not many. But at least it appears to work on i3. It may reintroduce flickering on fullscreen with other WMs, though.
* sanitizer: avoid divide-by-zero instancesBen Boeckel2014-09-141-1/+1
| | | | | | | | Merges pull request #1094, with some minor changes. mpv expects IEEE, and IEEE allows divisions by 0 for floats, so these shouldn't actually be a problem, but do it anyway for the sake of clang. Signed-off-by: wm4 <wm4@nowhere>
* x11: remove unused functionwm42014-09-142-9/+1
|
* wayland_common: fix changing videos when fullscreenAlexander Preisinger2014-09-102-15/+3
| | | | I broke it again.
* vo_wayland: pixel perfect buffersAlexander Preisinger2014-09-105-342/+500
| | | | | | | | | | | | | | | 1. Separate buffer and temporary file handling from the vo to make maintenance and reading code easier 2. Skip resizing as much as possible if back buffer is still busy. 3. Detach and mark osd buffers for deletion if we want to redraw them and they are still busy. This could be a possible case for the video buffers as well. Maybe better than double buffering. All the above steps made it possible to have resizing without any artifacts even for subtitles. Also fixes dozen of bugs only I knew, like broken subtitles for rgb565 buffers. I can now sleep at night again.
* win32: don't request window size larger than the screenwm42014-09-101-3/+34
| | | | | | | | | | | | | | | | | An attempt at fixing #1070. Apparently something goes wrong if the video size is equal to the screen size. Since the window decorations add to the window size, it must actually be larger than the screen. Actually I don't know what exactly is going wrong, but since this commit also slightly improves the behavior otherwise, it's a win anyway. Try to keep the window size strictly below screen size, even accounting for window decorations. Size it down and center the window so that it fits (by either touching the left/right or top/bottom screen borders). I haven't found any information on what is the maximum allowed size and position of a window so that it doesn't collide with the task bar, so assume that we can use the entire screen, minus 1 pixel to avoid triggering fullscreen semantics (if that is even possible).
* win32: copy event flags after running VOCTRLswm42014-09-071-5/+2
| | | | | | | | | reinit_window_state() will set VO_EVENT_RESIZE when it runs, so we don't need to set it manually depending on the VOCTRL. Probably avoids duplicated resize events. I don't expect this actually fixes anything, but might help spotting other bugs easier (if there are any).
* vo_corevideo: remove this VOStefano Pigozzi2014-09-062-576/+0
| | | | | | | This was kept in the codebase because it is slightly faster than --vo=opengl on really old Intel cards (from the GMA era). Time to kill it, and let it rest. Fixes #1061
* vo_sdl: fix typowm42014-09-051-1/+1
|
* malloc+memset(0) to callocBruno George de Moraes2014-09-052-7/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* build: handle insane libavcodec API bullshitwm42014-09-051-11/+25
| | | | | | | | | | | | | | | | | | | | | The oldest supported FFmpeg release doesn't provide av_vdpau_alloc_context(). With these versions, the application has no other choice than to hard code the size of AVVDPAUContext. (On the other hand, there's av_alloc_vdpaucontext(), which does the same thing, but is FFmpeg specific - not sure if it was available early enough, so I'm not touching it.) Newer FFmpeg and Libav releases require you to call this function, for ABI compatibility reasons. It's the typcal lakc of foresight that make FFmpeg APIs terrible. mpv successfully pretended that this crap didn't exist (ABI compat. is near impossible to reach anyway) - but it appears newer developments in Libav change the function from initializing the struct with all-zeros to something else, and mpv vdpau decoding would stop working as soon as this new work is relewased. So, add a configure test (sigh). CC: @mpv-player/stable
* video: rename VOCTRL_GET_WINDOW_SIZEwm42014-09-055-10/+12
| | | | Make it clear that this accesses the un-fullscreened window size.
* wayland: print some useful outptu infoAlexander Preisinger2014-09-032-15/+21
| | | | | Prints output informations, useful for finding out if we detect the right mode and for debugging.
* wayland: only save current mode of outputsAlexander Preisinger2014-09-031-1/+2
| | | | Other ones are not needed.
* x11: add rewind and forward keysKenneth Zhou2014-09-031-2/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* video: adjust some Matroska 3D formatswm42014-08-311-2/+2
| | | | | | | There is no proper and exact spec (Matroska tradition), so we probably have to rely on guessing for this. Also see issue #1045.
* x11: when using --wid, inherit event flags from parent windowwm42014-08-311-5/+10
| | | | | | | | | | | | | | | | | | | When embedding a X window, it's hard to control whether it receives mouse/keyboard input or not. It seems the X protocol itself makes this hard (basically due to the outdated design mismatching with modern toolkits), and we have to take care of these things explicitly. Simply do this by manually querying and using the parent window event flags. This restores some MPlayer behavior (it doesn't add back exactly the same code, but it's very similar). This probably has some potential to interfere with libmpv embedding, so bump the client API minor. CC: @mpv-player/stable (if applied, client-api-changes.rst has to be adjusted to include the 0.5.2 release)
* csputils: adjust commentwm42014-08-302-3/+5
| | | | | Make it clear that the value is linked to the StereoMode element. You can't change this without adjusting demux_mkv.c.
* video: initial Matroska 3D supportwm42014-08-306-1/+44
| | | | | | | | | | | | | | | | | | | | | This inserts an automatic conversion filter if a Matroska file is marked as 3D (StereoMode element). The basic idea is similar to video rotation and colorspace handling: the 3D mode is added as a property to the video params. Depending on this property, a video filter can be inserted. As of this commit, extending mp_image_params is actually completely unnecessary - but the idea is that it will make it easier to integrate with VOs supporting stereo 3D mogrification. Although vo_opengl does support some stereo rendering, it didn't support the mode my sample file used, so I'll leave that part for later. Not that most mappings from Matroska mode to vf_stereo3d mode are probably wrong, and some are missing. Assuming that Matroska modes, and vf_stereo3d in modes, and out modes are all the same might be an oversimplification - we'll see. See issue #1045.
* vf_softpulldown: handle null mpi_image correctlyshdown2014-08-301-3/+3
| | | | Check if mpi is NULL before accessing mpi->fields.
* gl_wayland: fix crash after eglInitialze failedAlexander Preisinger2014-08-301-6/+8
| | | | | Only execute most of the opengl termination procedure if we actually have an egl context.
* vo_opengl: remove macro operator from shaderBin Jin2014-08-292-21/+7
| | | | Removes '##' operator from OpenGL shader code.
* Move compat/ and bstr/ directory contents somewhere elsewm42014-08-2915-20/+12
| | | | | | | | | bstr.c doesn't really deserve its own directory, and compat had just a few files, most of which may as well be in osdep. There isn't really any justification for these extra directories, so get rid of them. The compat/libav.h was empty - just delete it. We changed our approach to API compatibility, and will likely not need it anymore.
* vo_opengl: don't pass (char*)NULL as %s printf argumentwm42014-08-281-2/+3
| | | | | | glGetString(GL_SHADING_LANGUAGE_VERSION) can return NULL; I suppose this happens on legacy OpenGL, while all the other fields are guaranteed to exist.
* vo_opengl: fix shaderwm42014-08-281-7/+9
| | | | | | | | | | | | Regression since commit f14722a4. For some reason, this worked on nvidia, but rightfully failed on mesa. At least in C, the ## operator indeed needs two macro arguments, and you can't just concatenate with non-arguments. This change will most likely fix it. CC: @bjin
* vo_opengl: add parameter to gaussian filterBin Jin2014-08-261-2/+7
| | | | | | | | | | Add a new parameter 'p' to gaussian filter. The new formula used a different base taken from fmtconv plugin, so that the new parameter is exactly same as the one used in Avisynth and Vapoursynth. The new default value is 2 / log(2) * 10, with the default value it conforms to the original kernel taken from vector-agg.
* vo_opengl: add radius options for filtersBin Jin2014-08-264-1/+17
| | | | | | | Add two new options, make it possible for user to set the radius for some of the filters with no fixed radius. Also add three new filters with the new radius parameter supported.
* vo_opengl: add cparam1 and cparam2 optionsBin Jin2014-08-263-21/+42
| | | | | | Although cscale is rarely used, it's possible that params of cscale are accidentally set to lparam1 a