summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* 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 framebuffers, like vo_vdpau.c does. This requires VO driver support, and is out of scope of this commit. As consequence, the VO has a queue size of 1. The existing video queue is just needed to compute frame duration, and will be moved out in the next commit.
* video: don't keep multiple pointers to hwdec info structwm42014-08-116-25/+28
| | | | This makes a certain corner case simpler at a later point.
* vaapi: fix uninitialized value readwm42014-08-111-1/+1
| | | | | | Found with valgrind. This is somewhat terrifying, because the VA-API API function is supposed to fill these values, and we access them only if the API functions return success. So this shouldn't have happened.
* vf_vapoursynth: print more diagnostics on errorwm42014-08-111-3/+9
|
* vdpau: allocate surfaces by agewm42014-08-112-1/+11
| | | | | Whether this helps is probably questionable and depends on the GPU. But the vaapi code does it too.
* vo_sdl: fix redrawing issuewm42014-08-101-1/+1
| | | | | | vo_sdl.c has broken event handling and just polls. The polling time was quite low, so the playloop OSD redrawing heuristic inhibited redraws, which made the window appear frozen when paused.
* video: remove "hard" framedrop modewm42014-08-091-5/+10
| | | | | | | | | Completely useless, and could accidentally be enabled by cycling framedrop modes. Just get rid of it. But still allow triggering the old code with --vd-lavc-framedrop, in case someone asks for it. If nobody does, this new option will be removed eventually.
* vo_direct3d: allow resizing before video initwm42014-08-061-1/+1
| | | | | | | This can just happen in the time between VO creation, and the first call to vo_reconfig. It seems the recent threading changes exposed this bug. Fixes #986.
* win32: never call GetClientRect(0, ...)wm42014-08-062-2/+6
| | | | | | | | | | | | | | | | | Sometimes GetClientRect() appeared to fail during init, and since we don't check GetClientRect() calls (because they're on our own window, and logically can never fail), bogus resizes were triggered. This could cause vo_direct3d to fail initialization. The reason was that w32->window was set to 0 during early window initialization: CreateWindow*() can send messages to the new window, even though it hasn't returned yet. This means w32->window is not yet set to our window handle, and functions in WndProc may accidentally pass hwnd=0 to win32 API functions. Fix it by initializing w32->window on opportunity. This also means we always strictly expect that the WndProc is used with our own window only.
* wayland: remove redundant lineAlexander Preisinger2014-08-061-1/+0
|
* wayland: changes for nested compositorsAlexander Preisinger2014-08-061-20/+50
| | | | | Adds necessary checks for nested compositors which only have limited interfaces. Might also be useful for other minimal compositors.
* cocoa: macosx_application needs cocoa-applicationFRAU KOUJIRO2014-08-062-3/+7
|
* cocoa: move handleFilesArray: to macosx_eventsFRAU KOUJIRO2014-08-061-2/+2
|
* win32: fix buildwm42014-08-051-1/+0
|
* win32: create OpenGL context on the GUI threadwm42014-08-053-12/+40
| | | | | | | | | | | | | | | | This fixes the fullscreen issues on Intel for me. I'm baffled by it and don't understand why this suddenly works. Intel drivers being shit? Windows being shit? HWND or HDC being only 97% thread-safe instead of 98%? Me missing something subtle that is not documented anywhere? Who knows. Now instead of creating the HDC and OpenGL context on the renderer thread, they're created on the GUI thread. The renderer thread will then only call wglMakeCurrent, SwapBuffers, and OpenGL standard functions. Probably fixes github issue #968.
* win32: cleanup OpenGL context creationwm42014-08-051-37/+33
| | | | | Might handle some corner cases better. In particular, always call wglMakeCurrent() with non-NULL HDC argument.
* vdpau: don't crash on flipped imageswm42014-08-051-5/+12
| | | | | | | | | |