summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vdpau: don't crash on flipped imageswm42014-08-051-5/+12
| | | | | | | | | | It seems the vdpau API does not support these. Do a semi-expensive emulation of it. On the other hand, it's not like this is a commonly-used feature. (It might be better to make --vf=flip always copy instead of flipping it via pointer tricks - but everything allows flipped images, and even decoders or libavfilter filters could output them.)
* gl_wayland: Don't try to resize the egl_window before it existsMichael Forney2014-08-041-0/+3
| | | | | | | If the compositor sends a configure event immediately after a window is created (for example, if it implements tiling window management), mpv will attempt to call wl_egl_window_resize before it has actually created the egl_window, causing a crash.
* Improve setting AVOptionswm42014-08-022-20/+9
| | | | | | | | Use OPT_KEYVALUELIST() for all places where AVOptions are directly set from mpv command line options. This allows escaping values, better diagnostics (also no more "pal"), and somehow reduces code size. Remove the old crappy option parser (av_opts.c).
* win32: fix assertion failurewm42014-08-011-12/+10
| | | | | | | | If OpenGL 3.x doesn't work, the fallback to legacy GL will call the function to create the DC again, and it will assert. Just make it not to, and also simplify the code a bit. Fixes #974.
* vda: only support the new hwaccel 1.2 API (remove old code)Stefano Pigozzi2014-08-012-151/+17
| | | | | | | | | Since the new hwaccel API is now merged in ffmpeg's stable release, we can finally remove support for the old API. I pretty much kept lu_zero's new code unchanged and just added some error printing (that we had with the old glue code) to make the life of our users less miserable.
* video/filter: add vf_bufferwm42014-07-302-0/+95
| | | | Mostly useful for debugging.
* vdpau: don't upload video images in advancewm42014-07-293-39/+11
| | | | | | | | | | | | With software decoding, images were uploaded to vdpau surfaces as they were queued to the VO. This makes it slightly more complicated (especially later on), and has no advantages - so stop doing it. The only reason why this was done explicitly was due to attempts to keep the code equivalent (instead of risking performance regressions). The original code did this naturally for certain reasons, but now that we can measure that it has no advantages and just requires extra code, we can just drop it.
* vo_x11: fix build with older Libav versionswm42014-07-281-4/+4
| | | | Why does this happen everytime...
* video: add a default color space for files with no videoNiklas Haas2014-07-281-0/+3
| | | | | | | | | | | | | | | | | | Usually mp_image_params_guess_csp takes care of finding *some* default for a video channel, but files with no video (or with extremely broken configurations) end up leaving the colorspace information as MP_CSP_PRIM_AUTO, which has no associated primaries. As a result of this, color managed OSD messages could not display because they were being color managed to match the (non-existing/absurd) video channel. With this change, such non-spaces will have BT.709 primaries as far as color management and the OSD is concerned. This fixes #961. CC: @mpv-player/stable Signed-off-by: wm4 <wm4@nowhere>
* vo: remove vo_mouse_movement() wrapperwm42014-07-278-30/+12
| | | | So that VO backends don't have to access the VO just for that.
* 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-132-20/+26
| | | | | | | 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.
* build: deal with endian messwm42014-07-102-2/+3
| | | | | | | | | | | | | | | | | | | | There is no standard mechanism for detecting endianess. Doing it at compile time in a portable way is probably hard. Doing it properly with a configure check is probably hard too. Using the endian definitions in <sys/types.h> (usually includes <endian.h>, which is not available everywhere) works under circumstances, but the previous commit broke it on OSX. Ideally all code should be endian dependent, but that is not possible due to the dependencies (such as FFmpeg, some video output APIs, some audio output APIs). Create a header osdep/endian.h, which contains various fallbacks. Note that the last fallback uses libavutil; however, it's not clear whether AV_HAVE_BIGENDIAN is a public symbol, or whether including <libavutil/bswap.h> really makes it visible. And in fact we don't want to pollute the namespace with libavutil definitions either. Thus it's only the last fallback.
* 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.
* vf_vapoursynth: reset error state on seekingwm42014-07-051-0/+1
| | | | | | | | | | | | When seeking, we violently destroy the filter, because vapoursynth has no proper API for terminating a video with unknown frame count. This looks like an error to vapoursynth, and the error is returned via the frame callbacks. The bug is that we remember this error state across reinitialization, so on the first filter call after reinitialization, we thought filtering the current frame failed. This caused a shift by 1 frame on each seek. CC: @mpv-player/stable
* dvd, bluray, cdda: add demux_disc containing all related hackswm42014-07-052-4/+0
| | | | | | | | | | | | DVD and Bluray (and to some extent cdda) require awful hacks all over the codebase to make them work. The main reason is that they act like container, but are entirely implemented on the stream layer. The raw mpeg data resulting from these streams must be "extended" with the container-like metadata transported via STREAM_CTRLs. The result were hacks all over demux.c and some higher-level parts. Add a "disc" pseudo-demuxer, and move all these hacks and special-cases to it.
* 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: Include better heuristics for guessing primariesNiklas Haas2014-06-223-4/+25
| | | | | | | These consult the vertical resolution, matching against 576 for PAL and 480/486 for NTSC. The documentation has also been updated. Signed-off-by: wm4 <wm4@nowhere>
* video: Refactor rendering intent for DCP XYZ and :srgbNiklas Haas2014-06-223-59/+98
| | | | | | 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-224-11/+67
| | | | | | | | | 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-225-129/+290
| | | | | | | | | 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-225-12/+73
| | | | Signed-off-by: wm4 <wm4@nowhere>
* options: Expose --colormatrix-primaries to the userNiklas Haas2014-06-221-0/+2
| | | | Signed-off-by: wm4 <wm4@nowhere>
* video: Add support for non-BT.709 primariesNiklas Haas2014-06-228-17/+187
| | | | | | | 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-224-16/+33
| | | | 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.
* vf_dlopen: fix the order of the arguments to mp_image_allocMarcoen Hirschberg2014-06-191-2/+2
|
* 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-177-12/+12
| | | | | 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.
* video: remove redundant functionwm42014-06-173-11/+2
| | | | mp_image_params_from_image() is now trivial and can be removed.
* 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: check image parameterswm42014-06-173-4/+38
| | | | | | | | | Make sure every video filter has valid parameters for input and output. (This also ensures we don't take possibly invalid decoder output, or feed invalid decodr/filter output to VOs.) Also, the updated image size check now (almost) works like the corresponding check in FFmpeg.
* video: introduce failure path for image allocationswm42014-06-1742-51/+175
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 c