summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* vo_opengl: remove cscale-down suboptionwm42015-01-202-6/+6
| | | | For an explanation see the additions to the manpage.
* vo: restore framedropwm42015-01-201-1/+1
| | | | Fix inverted condition in commit 234d6329.
* video: fix waiting for last frame/format reconfigwm42015-01-191-0/+1
| | | | | | | | | | | We still need to send the VO a duration in these cases. Disabling framedrop has logically absolutely nothing to do with these cases; it was overlooked in commit 918b06c4. So we always send the frame duration (or a guess for it), and check whether framedropping is actually enabled in the VO code. (It would be cleaner to send framedrop as a flag, but I don't care about that right now.)
* vo_opengl: remove 1D texture usagewm42015-01-184-52/+32
| | | | | | | Broke operation with GLSL. Since 1D texture usage was apparently (and mysteriously) good for speed, it might be added back, but it's unknown how to do so in a clean way.
* x11: fix initial state for --on-all-workspaceswm42015-01-171-0/+6
|
* cocoa: fix fullscreen handlingwm42015-01-171-2/+3
| | | | Fixes #1483, if it even compiles.
* x11: add --on-all-workspaces option and propertywm42015-01-162-2/+13
| | | | Fixes #1469.
* x11: minor cleanupwm42015-01-161-18/+4
| | | | No reason for these functions to exist separately...
* command: unify handling of fullscreen and other VO flagswm42015-01-165-0/+7
| | | | | | | | The "ontop" and "border" properties already used a common mp_property_vo_flag() function, and the corresponding VOCTRLs used the same conventions. "fullscreen" is pretty similar, but was handled slightly similar. Change how VOCTRL_FULLSCREEN behaves, and use the same helper function for "fullscreen" as the other flags.
* player: add --autofit-smaller optionwm42015-01-161-5/+9
| | | | | | | | Fixes #1472. (Maybe these options should have been named --autofit-max and --autofit-min, but since --autofit-larger already exists, use --autofit-smaller for symmetry.)
* cocoa: don't set application icon in libmpvStefano Pigozzi2015-01-161-2/+4
|
* player: respect --untimed on last framewm42015-01-161-2/+1
| | | | | | | | | | | | | | The last video frame is another case that has a separate code path, although it's pretty similar to the one in commit 73e5aa87. Fix this in a different way, which also takes care of the last frame case, although without context the code becomes slightly more tricky. As further cleanup, move the decision about framedropping itself to the same place, so the check in vo.c becomes much simpler. The check for the vo->driver->encode flag, which is remvoed completely, was redundant too. Fixes #1480.
* vo_opengl: get rid of approx-gamma and make it the default as per BT.1886Niklas Haas2015-01-163-56/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | After finding out more about how video mastering is done in the real world it dawned upon me why the "hack" we figured out in #534 looks so much better. Since mastering studios have historically been using only CRTs, the practice adopted for backwards compatibility was to simulate CRT responses even on modern digital monitors, a practice so ubiquitous that the ITU-R formalized it in R-Rec BT.1886 to be precisely gamma 2.40. As such, we finally have enough proof to get rid of the option altogether and just always do that. The value 1.961 is a rounded version of my experimentally obtained approximation of the BT.709 curve, which resulted in a value of around 1.9610336. This is the closest average match to the source brightness while preserving the nonlinear response of the BT.1886 ideal monitor. For playback in dark environments, it's expected that the gamma shift should be reproduced by a user controlled setting, up to a maximum of 1.224 (2.4/1.961) for a pitch black environment. More information: https://developer.apple.com/library/mac/technotes/tn2257/_index.html
* vo_opengl: add ewa_lanczos upscaler (aka jinc)Niklas Haas2015-01-154-29/+151
| | | | | This is the polar (elliptic weighted average) version of lanczos. This introduces a general new form of polar filters.
* vo_opengl_cb: initial screenshot supportwm42015-01-151-0/+10
| | | | | | | | | | | Support for taking screenshots when doing hardware decoding needs to be added later. This takes the last image queued to the VO, which is logically the image the player thinks is on screen (so e.g. subtitles will match). forget_frames() does not clear this, because seeking does not remove the current image from the screen (until the next one is drawn).
* image_writer: check for conversion errorswm42015-01-153-11/+17
| | | | | This can happen when e.g. a VO returns a screenshot in an unsupported format.
* vf: make message less confusingwm42015-01-131-1/+1
| | | | | Well, probably still not very good, but now at least accounts for the case the decoder or a filter outputs nonsense values.
* mp_image: reject invalid display aspect ratiowm42015-01-131-1/+1
| | | | | | | | | | Having any of these set to 0 makes no sense. I think some code might still be using 0/0 aspect ratio to signal unset aspect ratio, but I didn't find it. If there is still code like this, it should be fixed instead. Fixes #1467.
* wayland: implement key modifierswm42015-01-121-18/+24
| | | | Includes shift, ctrl, alt, meta.
*