summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* video/out: fix screenshot image formatswm42015-04-073-3/+3
| | | | | | | Use variants without alpha. I skipped vo_sdl, because format selection seems a bit more complicated here, and nobody cares about vo_sdl anymore.
* vdpau: don't use a transparent image format for screenshotswm42015-04-071-1/+1
| | | | Fixes #1779.
* screenshots: select best image format the encoder supportswm42015-04-061-24/+34
| | | | | | | | | | | | | | | | | | This matters for png screenshots. We used to hardcode rgb24, but libavformat's png encoder can do much more. Use the image format list provided by the encoder, and select the best format from it (according to the source format). As a consequence, rgb48 (i.e. 16 bit per component) will be selected if the source format is e.g. 10 bit yuv. This happens in accordance to FFmpeg's avcodec_find_best_pix_fmt_of_list() function, which assumes that 16 bit rgb should be preferred for 10 bit yuv. This also causes it to print this message in this case: [ffmpeg] swscaler: full chroma interpolation for destination format 'rgb48be' not yet implemented I'm not 100% sure whether this is a problem.
* vaapi: fight with Intel's broken video decoding GL interopwm42015-04-051-24/+81
| | | | | | | | | | | | | | | | | | | | | | | | Use texture-from-pixmap instead of vaapi's "native" GLX support. Apparently the latter is unused by other projects. Possibly it's broken due that, and Intel's inability to provide anything non-broken in relation to video. The new code basically uses the X11 output method on a in-memory pixmap, and maps this pixmap as texture using standard GLX mechanisms. This requires a lot of X11 and GLX boilerplate, so the code grows. (I don't know why libva's GLX interop doesn't just do the same under the hood, instead of bothering the world with their broken/unmaintained "old" method, whatever it did. I suspect that Intel programmers are just genuine sadists.) This change was suggested in issue #1765. The old GLX support is removed, as it's redundant and broken anyway. One remaining issue is that the first vaPutSurface() call fails with an unknown error. It returns -1, which is pretty strange, because vaapi error codes are normally positive. It happened with the old GLX code too, but does not happen with vo_vaapi. I couldn't find out why.
* vf_format: add gamma override optionNiklas Haas2015-04-041-0/+4
|
* vo_opengl: make csp options consistent with vf_formatNiklas Haas2015-04-041-20/+2
|
* csputils: add some missing colorspacesNiklas Haas2015-04-043-12/+92
| | | | | With target-prim and target-trc it makes sense to include some common colorspaces that aren't strictly speaking used for video.
* vo_opengl: minor cleanup of gamma-related functionsNiklas Haas2015-04-041-5/+4
|
* vo_opengl: blend-subtitles in non-linear lightNiklas Haas2015-04-041-35/+42
|
* vo_opengl: make jinc presets resizableNiklas Haas2015-04-041-6/+6
| | | | No real reason this is disabled with the new configuration API.
* vo_opengl: add scale-wparam optionNiklas Haas2015-04-041-8/+12
| | | | This lets us tune the window parameter
* filter_kernels: add haasnsoftNiklas Haas2015-04-041-0/+4
| | | | | | | This is a peculiar filter I stumbled upon while playing around with windows, it removes aliasing almost completely while not ringing at all. The downside is that it's quite blurry, but at high resolutions it's not so noticeable.
* filter_kernels: remove hermite windowNiklas Haas2015-04-041-1/+0
| | | | Will have to find a source before re-adding.
* filter_kernels: add bartlett, blackman and welch windowsNiklas Haas2015-04-041-1/+17
|
* vo_opengl: refactor scaler configurationNiklas Haas2015-04-044-129/+179
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
* vo_opengl: separate kernel and windowNiklas Haas2015-04-044-130/+192
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes the core much more elegant, reusable, reconfigurable and also allows us to more easily add aliases for specific configurations. Furthermore, this lets us apply a generic blur factor / window function to arbitrary filters, so we can finally "mix and match" in order to fine-tune windowing functions. A few notes are in order: 1. The current system for configuring scalers is ugly and rapidly getting unwieldy. I modified the man page to make it a bit more bearable, but long-term we have to do something about it; especially since.. 2. There's currently no way to affect the blur factor or parameters of the window functions themselves. For example, I can't actually fine-tune the kaiser window's param1, since there's simply no way to do so in the current API - even though filter_kernels.c supports it just fine! 3. This removes some lesser used filters (especially those which are purely window functions to begin with). If anybody asks, you can get eg. the old behavior of scale=hanning by using scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is just as terrible as that sounds - which is why nobody should have been using them in the first place). 4. This changes the semantics of the "triangle" scaler slightly - it now has an arbitrary radius. This can possibly produce weird results for people who were previously using scale-down=triangle, especially if in combination with scale-radius (for the usual upscaling). The correct fix for this is to use scale-down=bilinear_slow instead, which is an alias for triangle at radius 1. In regards to the last point, in future I want to make it so that filters have a filter-specific "preferred radius" (for the ones that are arbitrarily tunable), once the configuration system for filters has been redesigned (in particular in a way that will let us separate scale and scale-down cleanly). That way, "triangle" can simply have the preferred radius of 1 by default, while still being tunable. (Rather than the default radius being hard-coded to 3 always)
* vf_format: allow forcing aspect ratiowm42015-04-031-0/+4
| | | | | Makes vf_dsize completely useless. Unfortunately, even our "official" encoding profiles still use it.
* vf_format: allow forcing display sizewm42015-04-031-0/+7
|
* vo_opengl: remove chroma-location suboptionwm42015-04-031-9/+2
| | | | Terribly obscure, and vf_format can do this for all VOs.
* vf_format: allow forcing rotation flagswm42015-04-031-0/+7
|
* vf_format: allow forcing stereo mode parameterswm42015-04-031-0/+8
|
* video: cleanup stereo mode parsingwm42015-04-023-21/+20
| | | | | | | | | Use OPT_CHOICE_C() instead of the custom parser. The functionality is pretty much equivalent. (On a side note, it seems --video-stereo-mode can't be removed, because it controls whether to "reduce" stereo video to mono, which is also the default. In fact I'm not sure how this should be handled at all.)
* vdpau: fix preemption handlingDan Oscarsson2015-03-311-0/+23
| | | | Signed-off-by: wm4 <wm4@nowhere>
* video/out: remove unused colorspace reportingwm42015-03-317-58/+1
| | | | | | | | Rarely used and essentially useless. The only VO for which this was implemented correctly and for which this did anything was vo_xv, but you shouldn't use vo_xv anyway (plus it support BT.601 only, plus a vendor specific extension for BT.709, whose presence this function essentially reported - use xvinfo instead).
* video: move colorspace overrides to vf_format, simplifywm42015-03-315-50/+75
| | | | | | | | | | | | | | | | | | | Remove the colorspace-related top-level options, add them to vf_format. They are rather obscure and not needed often, so it's better to get them out of the way. In particular, this gets rid of the semi-complicated logic in command.c (most of which was needed for OSD display and the direct feedback from the VO). It removes the duplicated color-related name mappings. This removes the ability to write the colormatrix and related properties. Since filters can be changed at runtime, there's no loss of functionality, except that you can't cycle automatically through the color constants anymore (but who needs to do this). This also changes the type of the mp_csp_names and related variables, so they can directly be used with OPT_CHOICE. This probably ended up a bit awkward, for the sake of not adding a new option type which would have used the previous format.
* vf_format: don't crash if nonsense parameters are passedwm42015-03-311-3/+23
| | | | | | | It was "by design" possible to make mpv crash if the parameters didn't make enough sense, like "format=rgb24:yuv420p". While forcing the format has some minor (rather questionable) use for debugging, allowing it to crash is just stupid.
* vf_format: by default, pass through video without changewm42015-03-311-22/+17
| | | | | | Instead of forcing a useless format (packed YUV??) by default. Also cleanup.
* csputils: unify names for colorspace/etc. nameswm42015-03-311-23/+23
|
* RPI supportwm42015-03-2911-1/+865
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This requires FFmpeg git master for accelerated hardware decoding. Keep in mind that FFmpeg must be compiled with --enable-mmal. Libav will also work. Most things work. Screenshots don't work with accelerated/opaque decoding (except using full window screenshot mode). Subtitles are very slow - even simple but huge overlays can cause frame drops. This always uses fullscreen mode. It uses dispmanx and mmal directly, and there are no window managers or anything on this level. vo_opengl also kind of works, but is pretty useless and slow. It can't use opaque hardware decoding (copy back can be used by forcing the option --vd=lavc:h264_mmal). Keep in mind that the dispmanx backend is preferred over the X11 ones in case you're trying on X11; but X11 is even more useless on RPI. This doesn't correctly reject extended h264 profiles and thus doesn't fallback to software decoding. The hw supports only up to the high profile, and will e.g. return garbage for Hi10P video. This sets a precedent of enabling hw decoding by default, but only if RPI support is compiled (which most hopefully it will be disabled on desktop Linux platforms). While it's more or less required to use hw decoding on the weak RPI, it causes more problems than it solves on real platforms (Linux has the Intel GPU problem, OSX still has some cases with broken decoding.) So I can live with this compromise of having different defaults depending on the platform. Raspberry Pi 2 is required. This wasn't tested on the original RPI, though at least decoding itself seems to work (but full playback was not tested).
* vo_opengl: treat non-blended subtitles as sRGBNiklas Haas2015-03-271-32/+44
| | | | | | | | Currently, the code just skipped CMS completely. This commit treats them as sRGB by default, instead. This also refactors much of the color management code to make it more generalized and re-usable.
* vo_opengl: add FBOTEX_FUZZY aliasNiklas Haas2015-03-262-6/+5
| | | | Minor reusability factor
* vo_opengl: simplify sampler preludeNiklas Haas2015-03-261-46/+44
| | | | | This moves common re-definitions to a custom function and also shortens the names to make stuff less verbose in general.
* vo_opengl: reset surfaces on equalizer updatesNiklas Haas2015-03-261-0/+1
| | | | | This makes the VO more responsive to equalizer changes (eg. brightness) when interpolation is used.
* vo_opengl: increase shader cache sizeNiklas Haas2015-03-261-1/+1
| | | | | | | This is a minor precaution, because in some cases the number of shader programs can already hit 10. (chroma merging + separated cscale/scale + + sub blending (interpolated) + sub blending (non-interpolated) + output (interpolated) + output (non-interpolated) + OSD)
* vo_opengl: draw subtitles directly onto the videoNiklas Haas2015-03-264-60/+89
| | | | | | | | | | | | | | | | This has a number of user-visible changes: 1. A new flag blend-subtitles (default on for opengl-hq) to control this behavior. 2. The OSD itself will not be color managed or affected by gamma controls. To get subtitle CMS/gamma, blend-subtitles must be used. 3. When enabled, this will make subtitles be cleanly interpolated by :interpolation, and also dithered etc. (just like the normal output). Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: set cscale=spline36 as default for opengl-hqNiklas Haas2015-03-251-1/+1
| | | | | | | Bilinear scaling is not a suitable default for something named "hq"; the whole reason this was done in the past was because cscale used to be obscenely slow. This is no longer the case, with cscale being nearly free.
* vo_opengl: correct OSD PTS when using interpolationNiklas Haas2015-03-251-1/+22
|
* vf_vapoursynth: handle approximate EOF drainingwm42015-03-251-9/+28
| | | | | | | | | | | | | Handling this perfectly with VapourSynth is probably not possible: you either need to tell it the total number of input frames in advance, or deliver an infinite stream. With playback, EOF can happen at an unpredictable point, for which the VapourSynth API has no mechanism at all. We handle EOF by returning an error to the filter, which will the filter return all pending frame callbacks. We still can try to handle it approximately: if the filter requests a frame past EOF, then send it an error. This seems to work relatively well with filters which don't request future frames.
* vo_opengl: minor simplificationwm42015-03-251-17/+12
| | | | We don't need alternative function names in the GL loader anymore.
* vo_opengl: check extensions properlywm42015-03-251-1/+9
| | | | | | | | | With the previous commit, we have no need anymore to check a part of an extension string (for ignoring a prefix). So check the extension string properly, instead of just using the broken old strstr() method, which could accidentally ignore prefixes or suffixes. Do this by extending the check to whether the extension name is properly delimited by spaces or string start/end.
* vo_opengl: cleanup swap_control extension loadingwm42015-03-252-6/+15
| | | | | | | | | | | | | | | | Instead of somehow looking for the substring "_swap_control" and trying to several arbitrary function names, do it cleanly. The old approach has the problem that it's not very exact, and may even load a pointer to a function which doesn't exist. (Some GL implementations like Mesa return function pointers even the functions which don't exist, and calling them crashes.) I couldn't find any evidence that glXSwapInterval, wglSwapIntervalSGI, or wglSwapInterval actually exist, so don't include them. They were carried over from MPlayer times. To make diagnostics easier, print a warning in verbose mode if the function could not be loaded.
* vo_opengl: drop support for old framebuffer extensionwm42015-03-251-15/+0
| | | | | | | | Drop support for GL_EXT_framebuffer_object. It has 2 problems: semantics might be slightly different from the "proper" GL_ARB_framebuffer_object extension (but is likely completely untested), and also our extension loader is too dumb to load the same group of function pointers represented by different extensions only once.
* vo_wayland: fix null dereferenceJari Vetoniemi2015-03-231-1/+1
| | | | | If compositor sends configure event before back_buffer is allocated, it will cause null dereference.
* vo_opengl: do not block on waylandJari Vetoniemi2015-03-235-0/+31
| | | | | | | | | When not receiving frame callbacks, we should not draw anything to avoid blocking the OpenGL renderer. We do this by extending gl context api, by introducing new optional function 'is_active', that indicates whether OpenGL renderers should draw or not. This fixes issue #249.
* vo_wayland: define opaque regionJari Vetoniemi2015-03-231-0/+9
| | | | | This allows compositor to optimize rendering, as it will know mpv is not transparent.
* vo_wayland: share frame callbacks.Jari Vetoniemi2015-03-234-39/+58
| | | | | | | | Define frame callback logic in wayland_common.c As this should be used by opengl renderer as well. Preferably drawing should be skipped entierly when no frame callbacks are received. However, for now only swap buffers is skipped.
* mp_image: reject 0-sized imageswm42015-03-231-2/+1
| | | | | | Like FFmpeg/Libav do. It seems not all code can actually deal with this situation, so it's better to shift the special-cases to code which needs it (possibly OSD code; screenshots of 0x0 windows would just fail).
* vo_opengl: fix XYZ input gammaNiklas Haas2015-03-231-1/+1
| | | | | This seems to have been a mistranslation from the original code, which multiplied the gamma by 2.6 (*not* the color itself).
* vo_vdpau: remove some minor code duplicationwm42015-03-231-13/+7
| | | | | The way-too-big API call for clearing the screen can be easily shared between two completely different codepaths.
* vo_vdpau: check vdpau API return valuewm42015-03-231-0/+1
|
* vdpau: remove dead assignmentwm42015-03-231-2/+1
| | | | | | I guess we don't really care whether this particular function succeeds. If it fails, it must be completely broken anyway and it would not matter much to us.
* vo_opengl: remove dead assignmentwm42015-03-231-3/+3
|
* vo_opengl_cb: don't render OSD while VO is not createdwm42015-03-234-15/+25
| | | | | | | | | | | Unlike other VOs, this rendered OSD even while no VO was created (because the renderer lives as long as the API user wants). Change this, and refactor the code so that the OSD object is accessible only while the VO is created. (There is a short time where the OSD can still be accessed even after VO destruction - this is not a race condition, though it's inelegant and unfortunately unavoidable.)
* vo_opengl: move OSD rendering to separate functionwm42015-03-231-39/+41
| | | | | Also reindent the few lines that call into the actual renderer to remove the "draw_osd" goto.
* vo_opengl: fix video equalizer gamma controlswm42015-03-221-1/+4
| | | | It was ignored.
* vo_opengl: fix background color optionwm42015-03-211-7/+5
| | | | | | gl_video_set_options() didn't update it, so the default value set on initialization was used. Fix by always setting the clear color before the clear command; it's slightly easier to follow too.
* vo_opengl: fix bicubic_fast scalerwm42015-03-211-1/+1
|
* vd_lavc: less confusing message when hardware decoding won't workwm42015-03-201-2/+3
| | | | | | Codecs for hardware acceleration are not blacklisted, but whitelisted. Also, if this emssage is printed, the codec might not have any hardware acceleration support in the first place.
* player: better handling of video with no timestampswm42015-03-201-1/+7
| | | | | | | | | | | Trying to handle such video is almost worthless, but it was requested by at least 2 users. If there are no timestamps, enable byte seeking by setting ts_resets_possible. Use the video FPS (wherever it comes from) and the audio samplerate for timing. The latter was already done by making the first packet emit DTS=0; remove this again and do it "properly" in a higher level.
* vo_xv: remove pointless castwm42015-03-201-2/+1
|
* vf_expand: fix memory leak on memory allocation failurewm42015-03-201-1/+3
| | | | Isn't it ironic.
* mp_image: do not assume trailing stride padding existswm42015-03-201-4/+4
| | | |