summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* 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 and lparam2, which might cause unexpected results.
* vo_opengl: add spline64 filter kernelBin Jin2014-08-261-0/+19
| | | | | | | | The coefficients are taken from fmtconv plugin for vapoursynth: https://github.com/vapoursynth/fmtconv/blob/master/src/fmtc/ContFirSpline64.cpp The package is licensed under WTFPL, and it's from the same author of Dither plugin for avisynth.
* vo_opengl: don't cut off feature list outputwm42014-08-251-1/+1
|
* video: avoid unnecessary frame droppingwm42014-08-231-1/+5
| | | | | | | | | If duration<0, it means the duration is unknown. Disable framedropping, because end_time makes no sense in this case. Also, strictly never drop the first frame. This fixes weird behavior with the cover-art case (for the 100th time).
* video: some debugging outputwm42014-08-221-0/+4
|
* vf_vapoursynth: add more VS frame propertiesBin Jin2014-08-221-0/+8
| | | | Add the missing frame properties in 48587e88.
* vf_vapoursynth: add display resolution supportBin Jin2014-08-221-0/+5
| | | | | | | | | | | | Add two new script environment variables 'video_in_dw' and 'video_in_dh', representing the display resolution of video. Along with video resolution, sample ratio aspect can be calculated in scripts. Currently it's impossible to change sample ratio aspect with single vapoursynth filter since '_SARNum' and '_SARDen' frame properties from output clip will be ignored. A following 'dsize' filter is necessary for this purpose.
* vaapi: try dealing with Intel's braindamaged shit driverswm42014-08-217-2/+84
| | | | | | | | | | | | | | | | | | | | | | | | So talking to a certain Intel dev, it sounded like modern VA-API drivers are reasonable thread-safe. But apparently that is not the case. Not at all. So add approximate locking around all vaapi API calls. The problem appeared once we moved decoding and display to different threads. That means the "vaapi-copy" mode was unaffected, but decoding with vo_vaapi or vo_opengl lead to random crashes. Untested on real Intel hardware. With the vdpau emulation, it seems to work fine - but actually it worked fine even before this commit, because vdpau was written and designed not by morons, but competent people (vdpau is guaranteed to be fully thread-safe). There is some probability that this commit doesn't fix things entirely. One problem is that locking might not be complete. For one, libavcodec _also_ accesses vaapi, so we have to rely on our own guesses how and when lavc uses vaapi (since we disable multithreading when doing hw decoding, our guess should be relatively good, but it's still a lavc implementation detail). One other reason that this commit might not help is Intel's amazing potential to fuckup anything that is good and holy.
* video: don't assume query_format is thread-safewm42014-08-202-0/+16
| | | | Although it's probably safe for most VOs, there's no guarantee.
* wayland: replace deprecated xkbcommon functionsAlexander Preisinger2014-08-201-3/+3
| | | | Available and stable since forever (xkbcommon 0.2).
* vo_wayland: fix formatting inconsistenciesAlexander Preisinger2014-08-201-4/+4
|
* vo_wayand: save the flip time in the frame handlerAlexander Preisinger2014-08-201-0/+10
| | | | This value is more accurate than the default value.
* video: add VOCTRL_GET_RECENT_FLIP_TIMEwm42014-08-182-1/+7
| | | | | | This could be used by VO implementations to report a recent vsync time to the generic VO code, which in turn will use it and the display FPS to estimate at which point in time the next vsync will happen.
* vo_opengl: add check-pattern suboption for testingwm42014-08-181-2/+28
| | | | | | | | | | | | | | | | This uses glXGetVideoSyncSGI() to check how many vsyncs happened since the last flip_page() call. It allows checking a pattern of vsync increments of at most 2 elements. For example, to check ~24 fps playback on a ~60 Hz monitor, this can be used: --vo=opengl:check-pattern=[3-2]:waitvsync Whether the reported results are accurate or just plain wrong may depend on the driver and if the waitvsync sub-option is used. There are no guarantees. This option is undocumented, and may be removed again in the near or distant future.
* video: dump vsync phase into stats filewm42014-08-181-2/+4
| | | | | | | For debugging (drawing fun plots with TOOLS/stats-conv.py). Also move last_flip under the correct comment: it's not protected by the lock, and can be accessed by the VO thread only.
* vaapi: we need more surfaceswm42014-08-181-1/+2
| | | | | | | Playing with high framedrop could make it run out of surfaces. In theory, we wouldn't need an additional surface, if we could just clear the vo_vaapi internal surface - but doing so would probably be a pain, so I don't care.
* wayland: dynamically report display fpsAlexander Preisinger2014-08-182-21/+60
| | | | | | | | Only reports the most recently entered output if the window is displayed on 2 or more outputs. Should be changed to the lowest fps of all outputs the window is visible. Until no one complains this will have to wait. Look for the VO framedropping for more information on this topic.
* x11: listen to xrandr eventswm42014-08-172-0/+18
| | | | | | | | | | | If the Xrandr configuration changes, re-read it. So if you change display modes or screen configuration, it will update the framedrop refresh rate accordingly. This passes the rootwin to XRRSelectInput(), which may or may not be allowed. But it works, and the documentation (which is worse than used toilet paper, great job Xorg) doesn't forbid it, or in fact say anything about what the window parameter is even used for.
* x11: fix xrandr conditional compilationwm42014-08-171-1/+1
| | | | | | Oops. Fixes #1020.
* video: make vo_opengl the default over vo_vdpauwm42014-08-171-3/+3