summaryrefslogtreecommitdiffstats
path: root/video/out
Commit message (Collapse)AuthorAgeFilesLines
* vo: different hack for VOs which need to mangle mouse inputwm42014-07-275-40/+11
| | | | | | | | Follow up on commit 760548da. Mouse handling is a bit confusing, because there are at least 3 coordinate systems associated with it, and it should be cleaned up. But that is hard, so just apply a hack which gets the currently-annoying issue (VO backends needing access to the VO) out of the way.
* win32: remove minor non-sensewm42014-07-261-1/+0
| | | | This is done in the wrong thread. Was harmless and had no effect at all.
* win32: move window handling to a separate threadwm42014-07-261-60/+174
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The windows message loop now runs in a separate thread. Rendering, such as with Direct3D or OpenGL, still happens in the main thread. In particular, this should prevent the video from freezing if the window is dragged. (The reason was that the message dispatcher won't return while the dragging is active, so mpv couldn't update the video at all.) This is pretty "rough" and just hacked in, and there's no API yet to make this easier for other backends. It will be cleaned up later once we're sure that it works, or when we know how exactly it should work. One oddity is that OpenGL is actually completely managed in the renderer thread, while e.g. Cocoa (which has its own threading code) creates the context in the GUI thread, and then lets the renderer thread access it. One strange issue is that we now have to stop WM_CLOSE from actually closing the window. Instead, we wait until the playloop handles the close command, and requests the VO to shutdown. This is done mainly because closing the window apparently destroys it, and then WM_USER can't be handled anymore - which means the playloop has no way to wakeup the GUI thread. It seems you can't really win here... maybe there's a better way to have a thread receive messages with and without a window, but I didn't find one yet. Dragging the window (by clicking into the middle of it) behaves strangely in wine, but didn't before the change. Reason unknown.
* vo: hack to avoid threading issues with mouse inputwm42014-07-265-1/+7
| | | | | | VO backends which are or will run in their own thread have a problem with vo_mouse_movement() calling vo_control(). Restrict this to VOs which actually need this.
* win32: use gcc TLS instead of WM_NCCREATE tricks for window contextwm42014-07-261-10/+9
| | | | | | | | | | | | win32 does not provide a proper per-window context pointer. Although it does allow passing a user-chosen value to WM_CREATE/WM_NCCREATE, this is not enough - the first message doesn't even have to be WM_NCCREATE. This gets us in trouble later on, so go the easy route and just use a TLS variable. __thread is gcc specific, but Windows is a very "special" platform anyway. We support only MinGW and Cygwin on it, so who cares. (C11 standardizes __thread as _Thread_local; we can use that later.)
* win32: make a flag explicitwm42014-07-261-1/+1
| | | | | | | | This shouldn't change anything. But it's worth making this explicit, since it's very subtle and unintuitive: if the X parameter is the magic value CW_USEDEFAULT, then the Y parameter is used as nCmdShow parameter to ShowWindow(). And in our case, this is SW_HIDE (0), because we want to create a hidden window.
* win32: simplify some --wid embedding codewm42014-07-261-26/+9
| | | | | | | | | | | This looked a bit overcomplicated. We don't care about the window position (it should always be 0/0, unless the parent program moved it, which it shouldn't). We don't care about the global on-screen position. Also, we will just retrieve a WM_SIZE message if our window is resized, and we don't need to update it manually. The only thing we have to do is making sure our window fills the parent window completely.
* win32: don't use CS_OWNDCwm42014-07-262-46/+64
| | | | | | | | | | | | | CS_OWNDC will make GetDC() always return the same HDC. This might become a problem when OpenGL rendering and window management are on different threads. Although I'm not too sure about this; our code never requests a HDC outside of the OpenGL backend, and it depends on whether win32 will internally request DCs. But in any case, this seems to be cleaner. Move the GL pixelformat setup code to gl_w32.c, where it's actually needed. This also fixes that SetPixelFormat() should be called only once, and not every time video params change.
* win32: remove worthless doxygen commentswm42014-07-261-39/+4
| | | | | | These mostly describe self-explanatory things, and fail to explain actually tricky things. Which means you just waste your time reading this, and have to figure it out from the code anyway.
* win32: make private struct private, refactorwm42014-07-264-221/+201
| | | | | | | | | | | | | | | | Preparation for moving win32 windowing to a separate thread. The codesize is reduced a bit, because some small functions are inlined, which reduces noise. The main change is that now most functions use the private struct directly, instead of accessing it indirectly through vo->w32. Accesses to vo are minimalized. The final goal is adding some sort of new windowing backend API. It would be cleaner to use that as context pointer for all functions (like struct vo was previously used), but since this is work in progress, we just go with this commit.
* cocoa: don't send messages to uninitialized gl contextsStefano Pigozzi2014-07-191-1/+6
| | | | | | | This should fix some crashes where we sent makeCurrentContext to a context that was being freed from another thread. /cc @mpv-player/stable
* cocoa: fix regression preventing window resizeStefano Pigozzi2014-07-151-1/+3
| | | | | I introduced this bug in b5bbb49. Sorry! This could fix #943 and #930 even though I can't reproduce those specific bugs.
* cocoa: fix compilation on OS X 10.8Stefano Pigozzi2014-07-141-0/+5
|
* Remove some mp_msg calls with no trailing \nwm42014-07-131-2/+4
| | | | | | | The final goal is all mp_msg calls produce complete lines. We want this because otherwise, race conditions could corrupt the terminal output, and it's inconvenient for the client API too. This commit works towards this goal. There's still code that has this not fixed yet, though.
* video/out: use strcmp() instead of strcasecmp() for equalizerswm42014-07-103-16/+16
| | | | This makes it more consistent with the more important VOs.
* cocoa: simplify logic that returns used bits per colorStefano Pigozzi2014-07-081-9/+1
|
* cocoa: move CGL context creation to gl_cocoaStefano Pigozzi2014-07-083-124/+118
| | | | | | This approach is similar to what other vo_opengl backends do. It can also be used in the future to create another cocoa backend that renders offscreen with IOSurfaces or FBOs.
* x11: avoid obscure behavior when --wid is partially garbagewm42014-07-041-1/+1
| | | | | | | | | | | Cast away the "extra" bits (since apparently Window/XID is always 32 bit unsigned). This is not striclty needed, because you're not supposed to pass garbage to --wid, just because the upper bits are possibly not interpreted. But if you do so, this change increases consistency in behavior and removes a strange behavior that was thought to be a bug. Also see github issue #906.
* x11: clear window only on initial mapwm42014-07-021-1/+2
| | | | | | | | | | | | | | | | | | | Apparently clearing on every map can cause problems with vdpau when switching virtual desktops and such. This was observed with at least XMonad and nvidia-340.17. It's not observed on some other setups without XMonad. It's not clear why this happens. Normally, the window background is not saved, so clearing should have no additional affect. It's a complete mystery. Possible, the use of legacy X drawing commands (used to clear the window) interferes with vdpau operation in non-trivial ways. Work this around by clearing on initial map only. This probably only hides the underlying issue, but good enough. Closes #897. CC: @mpv-player/stable
* Audit and replace all ctype.h useswm42014-07-013-6/+5
| | | | | | | | | | | | | | | | Something like "char *s = ...; isdigit(s[0]);" triggers undefined behavior, because char can be signed, and thus s[0] can be a negative value. The is*() functions require unsigned char _or_ EOF. EOF is a special value outside of unsigned char range, thus the argument to the is*() functions can't be a char. This undefined behavior can actually trigger crashes if the implementation of these functions e.g. uses lookup tables, which are then indexed with out-of-range values. Replace all <ctype.h> uses with our own custom mp_is*() functions added with misc/ctype.h. As a bonus, these functions are locale-independent. (Although currently, we _require_ C locale for other reasons.)
* vo_opengl: Make approx-gamma affect OSD/subNiklas Haas2014-06-222-4/+8
| | | | | | Close #837 Signed-off-by: wm4 <wm4@nowhere>
* video: Refactor rendering intent for DCP XYZ and :srgbNiklas Haas2014-06-221-2/+9
| | | | | | Notably, we now conform to SMPTE 428-1-2006 when decoding XYZ12 input, and we can support rendering intents other than colorimetric when converting between BT.709 and BT.2020, like with :srgb or :icc-profile.
* video: Better support for XYZ inputNiklas Haas2014-06-221-10/+30
| | | | | | | | | With this change, XYZ input is directly converted to the output colorspace wherever possible, and to the colorspace specified by the tags and/or --primaries option, otherwise. This commit also restructures some of the CMS code in gl_video.c to hopefully make it clearer which decision is being done where and why.
* video: Generate an accurate CMS matrix instead of hard-codingNiklas Haas2014-06-223-46/+62
| | | | | | | | | This also avoids an extra matrix multiplication when using :srgb, making that path both more efficient and also eliminating more hard-coded values. In addition, the previously hard-coded XYZ to RGB matrix will be dynamically generated.
* video: Support BT.2020 constant luminance systemNiklas Haas2014-06-222-10/+56
| | | | Signed-off-by: wm4 <wm4@nowhere>
* video: Add support for non-BT.709 primariesNiklas Haas2014-06-223-16/+55
| | | | | | | This add support for reading primary information from lavc, categorized into BT.601-525, BT.601-625, BT.709 and BT.2020; and passes it on to the vo. In vo_opengl, we always generate the 3dlut against the wider BT.2020 and transform our source into this colorspace in the shader.
* video: Add BT.2020-NCL colorspace and transfer functionNiklas Haas2014-06-221-9/+14
| | | | Source: http://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2020-0-201208-I!!PDF-E.pdf
* vo_xv: de-ancient some help messageswm42014-06-211-10/+2
| | | | | One message pointed to a removed file, so just get rid of the messages. They were helpful in the earlier 2000s, but now they're just confusing.
* vo_vaapi: fix reference counting when using software decodingwm42014-06-201-1/+2
| | | | Recent regression.
* vo_wayland: fix clearing the screen on reconfigwm42014-06-181-12/+11
| | | | | | Do this simply by clearing the mapped buffer on every draw_image() call without an actual video frame. (Maybe this is a bit expensive, but at least not more expensive than regular video display.)
* vo_sdl: fix clearing the screen on reconfigwm42014-06-181-35/+53
| | | | | | Clear the texture on reconfig(). (We could probably also do this simpler with a flag, but this is actually less complicated - except that we move the code to "map" a texture to a separate function.)
* video/out: fix redrawing with no video frame for some VOswm42014-06-185-31/+15
| | | | | | With the change to merge osd drawing into video frame drawing, some bogus logic got in: they skipped drawing the OSD if no video frame is available. This broke --no-video --force-window mode.
* vo_opengl: fix regression with opengl:pbowm42014-06-181-4/+3
| | | | | In the pbo case, mpi was reassigned to a stack pointer, and later deallocated. Just change the code so it doesn't need to be reassigned.
* gl_video: fix refcountingwm42014-06-181-0/+1
|
* video: correct spelling: mp_image_params_equals -> mp_image_params_equalwm42014-06-172-2/+2
| | | | | The type is struct mp_image_params, so the "params" should have a "s". "equals" shouldn't, because it's plural for 2 params. Important.
* vo: make draw_image and vo_queue_image transfer image ownershipwm42014-06-1716-30/+53
| | | | Basically a cosmetic change. This is probably more intuitive.
* video: introduce failure path for image allocationswm42014-06-1714-16/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, failure to allocate image data resulted in a crash (i.e. abort() was called). This was intentional, because it's pretty silly to degrade playback, and in almost all situations, the OOM will probably kill you anyway. (And then there's the standard Linux overcommit behavior, which also will kill you at some point.) But I changed my opinion, so here we go. This change does not affect _all_ memory allocations, just image data. Now in most failure cases, the output will just be skipped. For video filters, this coincidentally means that failure is treated as EOF (because the playback core assumes EOF if nothing comes out of the video filter chain). In other situations, output might be in some way degraded, like skipping frames, not scaling OSD, and such. Functions whose return values changed semantics: mp_image_alloc mp_image_new_copy mp_image_new_ref mp_image_make_writeable mp_image_setrefp mp_image_to_av_frame_and_unref mp_image_from_av_frame mp_image_new_external_ref mp_image_new_custom_ref mp_image_pool_make_writeable mp_image_pool_get mp_image_pool_new_copy mp_vdpau_mixed_frame_create vf_alloc_out_image vf_make_out_image_writeable glGetWindowScreenshot
* gl_lcms: use thread-safe lcms API, require lcms2 2.6wm42014-06-161-27/+16
| | | | | | | | | | | | | | The error log callback was not thread-safe and not library-safe. And apparently there were some other details that made it not library-safe, such as a global lcms plugin registry. Switch the the thread-safe API provided by lcms2 starting with 2.6. Remove our approximate thread-safety hacks. Note that lcms basically provides 2 APIs now, the old functions, and the thread-safe alternatives whose names end with THR. Some functions don't change, because they already have a context of some sort. Care must be taken not to accidentally use old APIs.
* vo_opengl: simplify redraw callback OSD handlingwm42014-06-165-82/+23
| | | | | | | | | OSD used to be not thread-safe at all, so a track was used to get it redrawn. This mostly reverts commit 6a2a8880, because OSD not being thread-safe was the non-trivial part of it. Mostly untested, because this code path is used on OSX only, and I don't have OSX.
* video/out: change aspects of OSD handlingwm42014-06-1518-134/+116
| | | | | | | | | Let the VOs draw the OSD on their own, instead of making OSD drawing a separate VO driver call. Further, let it be the VOs responsibility to request subtitles with the correct PTS. We also basically allow the VO to request OSD/subtitles at any time. OSX changes untested.
* vo_vaapi: fix a crash on the init error handling pathwm42014-06-151-1/+2
| | | | No X display or libva can't be initialized -> crash.
* wayland: move subsurfaces to wayland voAlexander Preisinger2014-06-153-34/+43
| | | | | | | Subsurfaces are only used by the wayland vo. Thats why it makes sense to move all osd and subsurface specific parts to the vo_wayland.c Also destroy the subsurfaces and subcompositor properly.
* wayland: attach NULL surface on osd creationAlexander Preisinger2014-06-151-0/+3
| | | | | | | When using the EGL output the subsurfaces have no buffer attached and the size seems to be infinite. Fix this by attaching a NULL buffer. Fixes #846
* cocoa: add fallback for automatic GPU switchingStefano Pigozzi2014-06-151-1/+14
| | | | | | Not all the hardware supports kCGLPFASupportsAutomaticGraphicsSwitching (apparently all Mid-2010 and before MacBooks do not work with it), so fallback to not asking for this attribute in the GL pixel format.
* cocoa: allow automatic gpu switchingStefano Pigozzi2014-06-151-0/+3
| | | | Fixes #820
* cocoa: switch to CGL APIs for GL context creationStefano Pigozzi2014-06-151-16/+23
| | | | | CGL APIs are lower level thus giving us better control and more options for the context creation.
* gl_w32: remove unused variablewm42014-06-141-2/+0
|
* video: synchronize mpv rgb pixel format names with ffmpeg nameswm42014-06-146-66/+66
| | | | | | | | | | | This affects packed RGB formats up to 16 bits per pixel. The old mplayer names used LSB-to-MSB order, while FFmpeg (and some other libraries) use MSB-to-LSB. Nothing should change with this commit, i.e. no bit order or endian bugs should be added or fixed. In some cases, the name stays the same, even though the byte order changes, e.g. RGB8->BGR8 and BGR8->RGB8, and this affects the user-visible names too; this might cause confusion.
* Add more constwm42014-06-118-60/+56
| | | | | | | While I'm not very fond of "const", it's important for declarations (it decides whether a symbol is emitted in a read-only or read/write section). Fix all these cases, so we have writeable global data only when we really need.
* vo_caca: remove global variableswm42014-06-111-68/+84
| | | | The shit I put up with...
* options: remove global variables for swscale options; rename themwm42014-06-112-2/+2
| | | | | | Additionally to removing the global variables, this makes the options more uniform. --ssf-... becomes --sws-..., and --sws becomes --sws- scaler. For --sws-scaler, use choices instead of magic integer values.
* video: fix another cover art corner casewm42014-06-091-1/+1
| | | | | | | Playing a video and then an audio file with cover art kept displaying the last frame of the video. This was because the hasframe flag was set, perhaps due to redrawing the last video frame before the cover art image is decoded.
* x11: cleanup motif hints handlingwm42014-06-062-38/+17
| | | | | | | | It seems we can't really get rid of this. There are no other hints to remove decorations that work across all reasonable WMs, so we're stuck with the ugly motif stuff. But at least we can make the code for it less ugly.
* filter_kernels: fix nearest scalerwm42014-06-041-1/+1
| | | | | | | | | | The previous commit assumed the filter would be 1x1 (then constant weight is correct) - but our code in fact uses at least a 2x2 filter. A 1x1 filter would generally be useless, except for nearest scaling - so it didn't exist. Insteasd of adding such a 1x1 filter, just turn the nearest weight function into a scare function, which should take care of the issue.
* filter_kernels: add nearest neighbour scalinglucy2014-06-031-0/+6
| | | | | | This is useful for playing content containing pixel art that hasn't been pre-scaled, such as TASVideos' high quality encodes. The implementation is lifted from <https://code.google.com/p/glumpy/source/browse/glumpy/image/filter.py#413>.
* wayland: remove stub for unimplemented functionwm42014-06-021-15/+0
|
* vo: correctly initialize parameters in corner caseswm42014-06-011-1/+4
|
* gl_common: remove dlsym() fallbackwm42014-05-311-21/+1
| | | | See previous commits.
* gl_wayland: remove probably unneeded workaroundwm42014-05-311-2/+0
| | | | | | | | This would imply eglGetProcAddress() doesn't work correctly, but using dlsym() does. For now get rid of it - it won't work in libmpv, and we'll probably need a better workaround if it's still broken. This code was in the initial wayland commit.
* gl_x11: remove workaround for PPC OSX 10.4wm42014-05-311-7/+0
| | | | | Added in 2010 with commit 4a8486f8 (svn commit 30994). I doubt anyone still uses X11 on OSX, and we probably don't support 10.4 either.
* gl_x11: always require some GLX API functions, avoid dlsym()wm42014-05-313-20/+6
| | | | | | | | | | | | | | The functions glXGetProcAddressARB() and glXQueryExtensionsString() were loaded using dlsym(). This could fail when compiling to libmpv, because t