summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vf_swapuv: remove this filterwm42015-01-272-66/+0
| | | | | | It's entirely useless. I left it in for a while, because the analog TV code had a transitional bug that could switch chroma planes, but it was fixed long ago. It's also available in libavfilter.
* vf_softpulldown: remove this filterwm42015-01-273-194/+0
| | | | | | | | Apparently it was completely broken and essentially did nothing. This was broken sometime in early mpv or mplayer2 times. Get rid of it. If you _really_ need it, wait until FFmpeg ports it from MPlayer, which will happen very soon.
* vf_pullup: remove builtin implementationwm42015-01-273-920/+10
| | | | | Now it requires libavfilter. The wrapper is left in place, so FFmpeg users will not notice any change. On Libav, the filter stops working.
* ta: rename MP_TALLOC_ELEMS to MP_TALLOC_AVAILBen Boeckel2015-01-271-2/+2
| | | | | The macro actually returns the *available* space in the array, not how much is actually filled in.
* vo_opengl: change the way unaligned chroma size is handledwm42015-01-274-11/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This deals with subsampled YUV video that has odd sizes, for example a 5x5 image with 4:2:0 subsampling. It would be easy to handle if we actually passed separate texture coordinates for each plane to the shader, but as of now the luma coordinates are implicitly rescaled to chroma one. If luma and chroma sizes don't match up, and this is not handled, you'd get a chroma shift by 1 pixel. The existing hack worked, but broke separable scaling. This was exposed by a recent commit which switched to GL_NEAREST sampling for FBOs. The rendering was accidentally scaled by 1 pixel, because the FBO size used the original video size, while textures_sizes[0] was set to the padded texture size (i.e. one pixel larger). It could be fixed by setting the padded texture size only on the first shader. But somehow that is annoying, so do something else. Don't pad textures anymore, and rescale the chroma coordinates in the shader instead. Seems like this somehow doesn't work with rectangle textures (and introduces a chroma shift), but since it's only used when doing VDA hardware decoding, and the bug occurs only with unaligned video sizes, I don't care much. Fixes #1523.
* vo: handle very long frame durations with smoothmotion enabledwm42015-01-261-1/+1
| | | | | | | | | | | | | | | With mf://, rather long frame durations are common. By default, one frame takes 1 second. This causes the if branch changed with this commit to always being taken, which in turn leads to the player not being woken up correctly. (As a consequence, it "freezes" by waiting for events that never come, and moving the mouse cursor over the window will wake it up again and advance video.) Obviously, the code should account for how long the video frame takes. The code is probably still not fully correct, but for now this fixes the issue at hand. Fixes #1521.
* vo_opengl: drop sRGB framebuffer detectionwm42015-01-262-9/+1
| | | | | We've stopped using them some time ago (we're doing things manually instead).
* video/out: cosmetics: rename VO_EVENT_ICC_PROFILE_PATH_CHANGEDwm42015-01-264-7/+7
| | | | | Remove the "PATH" bit, because VOCTRL_GET_ICC_PROFILE returns an in- memory profile, and not a path. (This was changed a while ago.)
* vo_opengl, x11: implement icc-profile-autowm42015-01-262-4/+36
| | | | | | | | | | | | | | | | | This queries the _ICC_PROFILE property on the root window. It also tries to reload the ICC when it changes, or if the mpv window changes the monitor. (If multiple monitors are covered, mpv will randomly select one of them.) The official spec is a dead link on freedesktop.org, so don't blame me for any bugs. Note that this assumes that Xinerama screen numbers match the way mpv enumerates the xrandr monitors. Although there is some chance that this matches, it most likely doesn't, and we actually have to do complicated things to map the screen numbers. If it turns out that this is required, I will fix it as soon as someone with a suitable setup for testing the fix reports it.
* vo_opengl: minor changes to ICC update codewm42015-01-262-19/+20
| | | | | | | | | | | | | | | Merge update_icc_profile() into get_and_update_icc_profile() - there's no reason anymore to keep them separate. The former is only called by the latter, and the separation of responsibilities between them is blurry a best. Query the ICC profile only if the corresponding feature is actually enabled. Additionally, change the error behavior of this code. Make loading failure non-fatal, and distinguish between runtime error and unimplemented functionality. Fix a memory leak in gl_lcms.c (although the changes in vo_opengl.c already take care of this, it's just logical and cleaner).
* vo_opengl: update a commentwm42015-01-261-2/+3
| | | | We don't use the hwdec-provided video texture for screenshots anymore.
* vo_opengl: make "mitchell" the hq default filter for downscalingwm42015-01-261-1/+2
| | | | | | | | | | | | | Seems like several people agree that it's a good filter for downscaling. Setting this option by default may also prevent people from accidentally using an unsuitable filter for downscaling by setting "scale" and without being aware of the impliciations (maybe). On the other hand, this change is not strictly backwards compatible for the same reasons. Also, allow disabling this option with scale-down="" (before this, not setting it was the only way to do this - not possible anymore if it's set by default). This is what the change in handle_scaler_opt() does.
* vo_opengl: simplify radius initializationwm42015-01-262-18/+6
| | | | | | | | | | | | | | | Somehow, the default radius for filters with variable radius was set in mp_init_filter(). gl_video.c used NAN as default value for the radius, which would make the filter use the default radius. Simplify this, and set the default radius directly in the gl_video options. It also makes the options easier to understand, because the default value listed in --vo=opengl:help actually shows the default value. Remove the function can_use_filter_kernel(), because it doesn't set a radius if none is set. The function is worthless anyway (something about making filter_kernels.c reusable to other VOs, and trying to deal with the possibility that it could provide filters not supported by vo_opengl.)
* vo_opengl: fancy-downscale affects luma-scaler onlywm42015-01-251-1/+1
|
* vo: fix redraw logicwm42015-01-251-4/+2
| | | | | | | | It actually can and does happen that you want to redraw, even if no image was queued yet. Broken by commit 28582322. Fixes #1510.
* vo_opengl: remove remnants of dropped stereo buffer supportwm42015-01-243-15/+0
|
* vo: generic redraw supportwm42015-01-242-7/+5
| | | | | | | | | | | | | | | | | | | | Usually, a VO must react to VOCTRL_REDRAW_FRAME in order to redraw the current screen correctly if video is paused (this is done to update OSD). But if it's not supported, we can just draw the current image again in the generic vo.c code. Unfortunately, this turned out pretty useless, because the VOs which would benefit from this need to redraw even if there is no image, in order to draw a black screen in --idle --force-window mode. The way redrawing is handled in the X11 common code and in vo_x11 and vo_xv is in the way, and I'm not sure what exactly vo_wayland requires. Other VOs have a non-trivial implementation of VOCTRL_REDRAW_FRAME, which (probably) makes redrawing slightly more efficient, e.g. by skipping texture upload. So for now, no VO uses this new functionality, but since it's trivial, commit it anyway. The vo_driver->untimed case is for forcibly disabling redraw for vo_lavc and vo_image always.
* vo: simplify VOs by adding generic screenshot supportwm42015-01-2414-134/+38
| | | | | | | | | | | At the time screenshot support was added, images weren't refcounted yet, so screenshots required specialized implementations in the VOs. But now we can handle these things much simpler. Also see commit 5bb24980. If there are VOs in the future which can't do this (e.g. they need to write to the image passed to vo_driver->draw_image), this still could be disabled on a per-VO basis etc., so we lose no potential performance advantages.
* cocoa: fix fallback for OpenGL 2.1 hardware [2]Stefano Pigozzi2015-01-241-7/+13
| | | | Looks like it fails on context creation, not pixfmt creation.
* cocoa: fix fallback for OpenGL 2.1 hardwareStefano Pigozzi2015-01-241-25/+25
| | | | | | This was previously done in common code but now it's left to backends. Also remove the GL4 stuff since requesting a 3_2_Core context creates a 4.1 context here (wtf).
* video: separate screenshot modeswm42015-01-2312-68/+38
| | | | | | | | | Use different VOCTRLs for "window" and normal screenshot modes. The normal one will probably be removed, and replaced by generic code in vo.c, and this commit is preparation for this. (Doing it the other way around would be slightly simpler, but I haven't decided yet about the second one, and touching every VO is needed anyway in order to remove the unneeded crap. E.g. has_osd has been unused for a long time.)
* vo: fix disabling/enabling smoothmotion at runtimewm42015-01-234-12/+10
| | | | | | | | | | | | | vo.c queried the VO at initialization whether it wants to be updated on every display frame, or every video frame. If the smoothmotion option was changed at runtime, the rendering mode in vo.c wasn't updated. Just let vo_opengl set the mode directly. Abuse the existing vo_set_flip_queue_offset() function for this. Also add a comment suggesting the use of --display-fps to the manpage, which doesn't have anything to do with the rest of this commit, but is important to make smoothmotion run well.
* vf_vavpp: add more deinterlacing algorithmswm42015-01-231-7/+22
| | | | | | These are untested due to lack of hardware. From what I've heard, the drivers are pretty buggy, so it's not clear how well this works, if at all.
* x11: remove unnecessary codewm42015-01-231-3/+0
|
* vo: allow dropping additional frames with smoothmotionwm42015-01-231-6/+6
| | | | | | | | | | | | | The logic disabled framedropping if the frame was interpolated (i.e. the render call is only done to interpolate between the previous frame, and the frame before that). It seems doing this wasn't even necessary, and broke framedrop in smoothmotion mode. In fact, this code did nothing for display with video fps below display fps. It did prevent the framedrop counter from going up, though. So change it so that dropped interpolated frames are never reported. (Doing so can give confusing results, such as dropping 1000s of frames on slow operations like video start or changing filters.)
* vo: cosmeticswm42015-01-231-22/+24
|
* vo: fix framedrop in normal casewm42015-01-231-1/+2
| | | | | vsync_timed is true if smoothmotion is used. That would mean framedrop is always disabled in the normal case.
* vo_opengl: add smoothmotion frame blendingStefano Pigozzi2015-01-237-20/+230
| | | | | | | | | | | | | | | | | | | SmoothMotion is a way to time and blend frames made popular by MadVR. It's intended behaviour is to remove stuttering caused by mismatches between the display refresh rate and the video fps, while preserving the video's original artistic qualities (no soap opera effect). It's supposed to make 24fps video playback on 60hz monitors as close as possible to a 24hz monitor. Instead of drawing a frame once once it's pts has passed the vsync time, we redraw at the display refresh rate, and if we detect the vsync is between two frames we interpolated them (depending on their position relative to the vsync). We actually interpolate as few frames as possible to avoid a blur effect as much as possible. For example, if we were to play back a 1fps video on a 60hz monitor, we would blend at most on 1 vsync for each frame (while the other 59 vsyncs would be rendered as is). Frame interpolation is always done before scaling and in linear light when possible (an ICC profile is used, or :srgb is used).
* filter_kernels: improve a commentwm42015-01-221-3/+2
| | | | It's not true anymore that the size necessarily depends on the radius.
* vo_opengl: improve terminal messages with lscale suboption errorswm42015-01-221-5/+13
| | | | Make it more apparent what the hell the user did wrong.
* vo_opengl: remove scale-sep and indirect optionsNiklas Haas2015-01-222-16/+12
| | | | | | | | | | | | These are now auto-detected sanely; and enabled whenever it would be a performance or quality gain (which is pretty much everything except bilinear/bilinear scaling). Perhaps notably, with the absence of scale_sep, there's no more way to use convolution filters on hardware without FBOs, but I don't think there's hardware in existence that doesn't have FBOs but is still fast enough to run the fallback (slow) 2D convolution filters, so I don't think it's a net loss.
* filter_kernels: get rid of sinc/lanczos aliasesNiklas Haas2015-01-221-12/+0
| | | | Just set the radius with scale-radius if it's really needed
* vo_opengl: rename all scale options to make more senseNiklas Haas2015-01-222-20/+32
| | | | | This emphasizes the fact that scale is used for *all* image upscaling, with cscale only serving a minor role for subsampled material.
* vo_opengl: switch to nearest neighbour for trivial resamplingNiklas Haas2015-01-222-3/+12
| | | | | | | | | | This is significantly faster for FBOs on most modern GPUs, although it did not result in a huge difference for the video source texture on the sizes I tested. It might be more significant for 1080p or 4K content, so it's worth revisiting this in the future. It also renames SAMPLE_BILINEAR to SAMPLE_TRIVIAL to match the semantics.
* vo_opengl: always prefer indirect scalingNiklas Haas2015-01-221-14/+5
| | | | | | This is better even for non-separable. The only exception is when using bilinear for both lscale and cscale. I've fixed the documentation/comments to make more sense.
* vo_opengl: implement naive anti-ringingNiklas Haas2015-01-223-10/+32
| | | | | | | | This is not quite the same thing as madVR's antiringing algorithm, but it essentially does something similar. Porting madVR's approach to elliptic coordinates will take some amount of thought.
* vo_opengl: unroll ewa_lanczos to avoid looping and unnecessary samplesNiklas Haas2015-01-222-10/+29
| | | | | | | This speeds up performance by a factor of something like 10%, since it omits unnecessary checks. This will also make adding anti-ringing easier.
* vo_opengl: clean up ewa_lanczos codeNiklas Haas2015-01-226-32/+60
| | | | | | This fixes compatibility with GLES 2.0 and makes the code a bit neater in general. It also properly forces indirect scaling for subsampled video regardless of the lscale setting.
* vo_opengl: guarantee correct reinitialization on setting optionswm42015-01-221-0/+1
| | | | | | At least the scale_sep_fbo could have been uninitialized or initialized incorrectly when switching between scalers (e.g. from bilinear to lanczos). Calling check_resize() should take care of this.
* vo_opengl: don't reset unused GL_PACK_... statewm42015-01-221-4/+1
|
* vo_opengl: simplify screenshot codewm42015-01-223-76/+13
| | | | | | | | | | | | | | Instead of reading back the image from textures, keep a reference to the original image, and return that. The main reason this was done this way was that originally, images weren't refcounted, and would be deallocated or overwritten as soon as the VO's draw call returned. But now there isn't really a good reason for this anymore. One possibly _could_ argue that it was better because other code could reuse the image sooner (e.g. for the cache), but on the other hand, the VO runs already on a different thread, and filtering and decoding each run on other threads too, so this argument probably wouldn't hold up.
* vo_vdpau: don't render to an output surface if it could be busywm42015-01-221-6/+6
| | | | | | There was a case when we could have rendered to an output surface while it's still used for display. Not sure why the API doesn't do this automatically.
* video: handle hwdec screenshots differentlywm42015-01-2212-97/+172
| | | | | | | | Instead of converting the hw surface to an image in the VO, provide a generic way to convet hw surfaces, and use this in the screenshot code. It's all relatively straightforward, except vdpau is being terrible. It needs a huge chunk of new code, because copying back is not simple.
* mp_image_pool: allow passing pool=NULL in more placeswm42015-01-221-2/+4
| | | | It's convenient.
* video: have a generic context struct for hwdec backendswm42015-01-2217-34/+56
| | | | | | | | | | | Before this commit, each hw backend had their own specific struct types for context, and some, like VDA, had none at all. Add a context struct (mp_hwdec_ctx) that provides a somewhat generic way to pass the hwdec context around. Some things get slightly better, some slightly more verbose. mp_hwdec_info is still around; it's still needed, but is reduced to its role of handling delayed loading of the hwdec backend.
* cocoa: remove support for systems without gl3.h headerStefano Pigozzi2015-01-222-37/+3
|
* vo_opengl: make the default radius 3.0 and simplify scaler documentationNiklas Haas2015-01-212-3/+3
| | | | | | | This also fixes the maximum range to 16.0, which was previously set to 32.0 and incorrectly documented as 8.0. 16 taps should be more than anybody will ever need, but it's the highest radius that's supported by all affected filters.
* vaapi: minor simplificationwm42015-01-214-9/+6
|
* video: remove vfcap.hwm42015-01-2121-109/+38
| | | | | | | | | | | | | | | | | And remove all uses of the VFCAP_CSP_SUPPORTED* constants. This is supposed to reduce conversions if many filters are used (with many incompatible pixel formats), and also for preferring the VO's natively supported pixel formats (as opposed to conversion). This is worthless by now. Not only do the main VOs not use software conversion, but also the way vf_lavfi and libavfilter work mostly break the way the old MPlayer mechanism worked. Other important filters like vf_vapoursynth do not support "proper" format negotation either. Part of this was already removed with the vf_scale cleanup from today. While I'm touching every single VO, also fix the query_format argument (it's not a FourCC anymore).
* video: try to keep implied alpha when using conversion filterswm42015-01-211-1/+1
| | | | | Don't just discard alpha. This probably does the right thing, in the rare situations when alpha matters at all.
* vo_direct3d: unify d3d "reset" and uninit pathswm42015-01-211-24/+21
| | | | | | | | I'm still not sure how exactly handling of "lost" devices is supposed to be handled. In theory, you only have to "reset" the device, instead of recreating _everything_. But as it is, the code for proper uninit and for handling the reset is exactly the same, so move it into a function to reduce code duplication and the danger of potential bugs.
* vo_direct3d: disable shaders if unavailablewm42015-01-211-23/+24
| | | | | | | | | | Apparently, extremely crappy graphics drivers don't allow you to use shaders. Simply disable use of shaders if this happens, and use the "old" method instead. One unexpectedly tricky thing is that you need a d3d_device to create a shader, which in turn requires a window, so the initialization order changes.
* vo_opengl: cleanups after vo_opengl_old removalwm42015-01-219-445/+73
| | | | | | | | | | | | | Don't load all the legacy functions (including ancient extensions). Slightly simplify function loader and context creation, now that legacy GL doesn't need to be handled. Remove the code for drawing OSD in legacy mode. Remove all the header hacks, which were meant for ancient OpenGL headers which didn't even support things like OpenGL 1.3. Instead, adjust the GLX check to make sure we get both OpenGL 3x and 2.1 symbols. For win32 and OSX, we assume that the user has the latest headers anyway. For wayland, we hope that things somehow go right.
* vo: never autoselect vo_nullwm42015-01-211-2/+4
| | | | Same deal as with commit d44b4ccb.
* vo_opengl: handle grayscale input better, add YA16 supportwm42015-01-217-21/+26
| | | | | | | | | | Simply clamp off the U/V components in the colormatrix, instead of doing something special in the shader. Also, since YA8/YA16 gave a plane_bits value of 16/32, and a colormatrix calculation overflowed with 32, add a component_bits field to the image format descriptor, which for YA8/YA16 returns 8/16 (the wrong value had no bad consequences otherwise).
* vf_scale: replace ancient fallback image format selectionwm42015-01-213-141/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If video output and VO don't support the same format, a conversion filter needs to be insert. Since a VO can support multiple formats, and the filter chain also can deal with multiple formats, you basically have to pick from a huge matrix of possible conversions. The old MPlayer code had a quite naive algorithm: it first checked whether any conversion from the list of preferred conversions matched, and if not, it was falling back on checking a hardcoded list of output formats (more or less sorted by quality). This had some unintended side- effects, like not using obvious "replacement" formats, selecting the wrong colorspace, selecting a bit depth that is too high or too low, and more. Use avcodec_find_best_pix_fmt_of_list() provided by FFmpeg instead. This function was made for this purpose, and should select the "best" format. Libav provides a similar function, but with a different name - there is a function with the same name in FFmpeg, but it has different semantics (I'm not sure if Libav or FFmpeg fucked up here). This also removes handling of VFCAP_CSP_SUPPORTED vs. VFCAP_CSP_SUPPORTED_BY_HW, which has no meaning anymore, except possibly for filter chains with multiple scale filters. Fixes #1494.
* vo_opengl_old: remove this VOwm42015-01-205-2322/+0
| | | | | At this point, there is probably no hardware left that doesn't do OpenGL 2.1, and at the same time is fast enough to handle video.
* vo_opengl: fix typowm42015-01-201-1/+1
|