summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
| | | | | | | | | | | | | Nvidia's vdpau implementation is pretty good, but other factors make it much less attractive for use as default VO. For example, Mesa often has low quality drivers (mess up things with the presentation queue and the vdpau API time source). Intel ruins things completely, and we're likely to run on emulation via OpenGL. Compositing has unknown effects (to me anyway), but appears to reduce the vdpau advantages. One important reason to prefer vo_vdpau was that it could do proper framedropping. Framedropping got fixed for the other VOs, so this reason is going away.
* video: take refresh rate changes into accountwm42014-08-173-28/+37
| | | | | | | | | | | | | | | This works only on X11, and only if the refresh rate changes due to the window being moved to another screen (detected by us). It doesn't include system screen reconfiguration yet. This calls VOCTRL_GET_DISPLAY_FPS on every frame, which makes me uneasy. It means extra thread communication with the win32 and Cocoa backends. On the other hand, a frame doesn't happen _that_ often, and the communication should still be pretty cheap and fast, so it's probably ok. Also needs some extra fuzz for vo_vdpau.c, because that does everything differently.
* x11: fix memory leakswm42014-08-171-3/+9
| | | | Oh, we have to free this stuff. OK.
* build: drop check for XF86keysym.hwm42014-08-161-6/+1
| | | | | | This is always included in the Xorg development headers. Strictly speaking it's not necessarily available with other X implementations, but these are hopefully all dead.
* x11: use xrandr to retrieve display refresh ratewm42014-08-163-25/+78
| | | | | | | | | | | | | | | | | Drop use of the ancient XF86VM, and use the slightly less ancient Xrandr extension to retrieve the refresh rate. Xrandr has the advantage that it supports multiple monitors (at least the modern version of it). For now, we don't attempt any dynamic reconfiguration. We don't request and listen to Xrandr events, and we don't notify the VO code of changes in the refresh rate. (The later works by assuming that X coordinates map directly to Xrandr coordinates, which probably is wrong with compositing window manager, at least if these use complicated transformations. But I know of no API to handle this.) It would be nice to drop use of the Xinerama extension too, but unfortunately, at least one EWMH feature uses Xinerama screen numbers, and I don't know how that maps to Xrandr outputs.
* vo_wayland: fix redrawing logicwm42014-08-161-8/+8
| | | | | | I must have broken it some time ago. The error case dealing with an unavailable backbuffer was broken, and didn't handle memory management correctly.
* video: add --display-fps switch to control framedrop FPSwm42014-08-161-3/+7
| | | | | | Since the display FPS is currently detected on X11 only (and even there it's known to be wrong on certain setups), it seems like a good idea to make this user-configurable.
* vo_opengl: optional support for using GLX_SGI_video_syncwm42014-08-151-1/+19
| | | | | | | | | I'm not sure about the merit, though it does print nice numbers if debug output is enabled. Basically, this tries to achieve similar results as the glFinish() business, but again it entirely depends on the drivers whether this does anything meaningful, or whether it's actively harmful.
* gl_common: add SGI_video_sync extensionwm42014-08-152-0/+11
|
* vo_opengl: if glfinish is used, also call it after swapppingwm42014-08-151-0/+3
| | | | | | It seems that at least on nvidia systems with composting disabled, we can get it to block deterministically on the actual vsync event, which should improve framedropping.
* video: add VO framedropping modewm42014-08-154-17/+115
| | | | | | | | | | | | | | | | | | | | | | | | This mostly uses the same idea as with vo_vdpau.c, but much simplified. On X11, it tries to get the display framerate with XF86VM, and limits the frequency of new video frames against it. Note that this is an old extension, and is confirmed not to work correctly with multi-monitor setups. But we're using it because it was already around (it is also used by vo_vdpau). This attempts to predict the next vsync event by using the time of the last frame and the display FPS. Even if that goes completely wrong, the results are still relatively good. On other systems, or if the X11 code doesn't return a display FPS, a framerate of 1000 is assumed. This is infinite for all practical purposes, and means that only frames which are definitely too late are dropped. This probably has worse results, but is still useful. "--framedrop=yes" is basically replaced with "--framedrop=decoder". The old framedropping mode is kept around, and should perhaps be improved. Dropping on the decoder level is still useful if decoding itself is too slow.
* vo: eliminate a redundant variablewm42014-08-151-10/+5
| | | | | Originally, I probably had plans to allow NULL images to handle things like the last frame case, but that idea was dropped later.
* vo: remove unused libavutil includewm42014-08-141-2/+0
|
* vo: fix mingw compilationwm42014-08-141-0/+2
|
* wayland: pointer interface is created after themeAlexander Preisinger2014-08-131-13/+8
| | | | | | | | Just always load the theme. It gets freed properly and dosn't bother anyone. Fixes #1012. CC: @mpv-player/stable
* vdpau: correctly mark invalid mixer as such on vdp_video_mixer_create() failureAlessandro Ghedini2014-08-131-0/+3
| | | | | Otherwise vdp_video_mixer_destroy() would later fail when called on an invalid video mixer handle. With mesa r600 vdpau driver, this would cause a segfault.
* vo_vdpau: fix screenshots with anamorphic videowm42014-08-131-1/+1
| | | | | | Fixes #1007. CC: @mpv-player/stable
* x11: vdpau GLX interop needs X11 threadswm42014-08-131-0/+2
| | | | | | | | | | Xlib is not thread-safe. Or actually it is, but it's an incomprehensible hack that was added later, and which needs to be acitvated manually (this makes no sense). And it appears that the vdpau accesses X from the decoder thread if GLX interop is used (and not in any other situations - this doesn't make too much sense either). So, just call the magic function that enables Xlib thread-safety.
* video: fix and simplify video format changes and last frame displaywm42014-08-122-70/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | The previous commit broke these things, and fixing them is separate in this commit in order to reduce the volume of changes. Move the image queue from the VO to the playback core. The image queue is a remnant of the old way how vdpau was implemented, and increasingly became more and more an artifact. In the end, it did only one thing: computing the duration of the current frame. This was done by taking the PTS difference between the current and the future frame. We keep this, but by moving it out of the VO, we don't have to special-case format changes anymore. This simplifies the code a lot. Since we need the queue to compute the duration only, a queue size larger than 2 makes no sense, and we can hardcode that. Also change how the last frame is handled. The last frame is a bit of a problem, because video timing works by showing one frame after another, which makes it a special case. Make the VO provide a function to notify us when the frame is done, instead. The frame duration is used for that. This is not perfect. For example, changing playback speed during the last frame doesn't update the end time. Pausing will not stop the clock that times the last frame. But I don't think this matters for such a corner case.
* video: move display and timing to a separate threadwm42014-08-1211-122/+481
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The VO is run inside its own thread. It also does most of video timing. The playloop hands the image data and a realtime timestamp to the VO, and the VO does the rest. In particular, this allows the playloop to do other things, instead of blocking for video redraw. But if anything accesses the VO during video timing, it will block. This also fixes vo_sdl.c event handling; but that is only a side-effect, since reimplementing the broken way would require more effort. Also drop --softsleep. In theory, this option helps if the kernel's sleeping mechanism is too inaccurate for video timing. In practice, I haven't ever encountered a situation where it helps, and it just burns CPU cycles. On the other hand it's probably actively harmful, because it prevents the libavcodec decoder threads from doing real work. Side note: Originally, I intended that multiple frames can be queued to the VO. But this is not done, due to problems with OSD and other certain features. OSD in particular is simply designed in a way that it can be neither timed nor copied, so you do have to render it into the video frame before you can draw the next frame. (Subtitles have no such restriction. sd_lavc was even updated to fix this.) It seems the right solution to queuing multiple VO frames is rendering on VO-backed framebu