summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* wayland: don't compute absurd window sizewm42015-01-121-3/+6
| | | | | | | | | For some reason, schedule_resize() can be called with everything set to 0. The code couldn't handle wl->window.aspect set to 0, converting NaNs to integers. Just work this around. (I have no idea what I'm doing. This is probably a corner case caused by my broken-ish wayland setup.)
* x11: explicitly query map status when waiting for map eventwm42015-01-121-0/+6
| | | | | | | | For some reason, mpv sometimes does not get a MapNotify event with GtkSocket embedding. This happens maybe 1 out of 10 times. I'm not sure how this can happen - it certainly shouldn't. Since I was not able to find the cause, and causes an apparent "deadlock", here's a lazy hack to fix the misbehavior.
* x11: support XEmbedwm42015-01-121-0/+49
| | | | | | | | | | | | Seems to work with GtkSocket and passing the gtk_socket_get_id() value via "wid" option to mpv. One caveat is that using <tab> to move input focus from mpv to GTK does not work. It seems we would have to interpret <tab> ourselves in this case. I'm not sure if we really should do this - it would probably require emulating some other typical conventions too. I'm not sure if an embedder could do something about this on the toolkit level, but in theory it would be possible, so leave it as is for now.
* vo: don't synchronize when seekingwm42015-01-121-1/+7
| | | | | | | | | Don't use vo_control() for sending VOCTRL_RESET when starting a seek. This means vo_seek_reset() won't wait until the VO actually processed VOCTRL_RESET. It happens asynchronously instead. The impact of this change should be minimal, unless the VO is somehow too busy (like blocking on vsync).
* command: change properties added in previous commitwm42015-01-101-1/+3
| | | | | | | | | | | | | Make their meaning more exact, and don't pretend that there's a reasonable definition for "bits-per-pixel". Also make unset fields unavailable. average_depth still might be inconsistent: for example, 10 bit 4:2:0 is identified as 24 bits, but RGB 4:4:4 as 12 bits. So YUV formats seemingly drop the per-component padding, while RGB formats do not. Internally it's consistent though: 10 bit YUV components are read as 16 bit, and the padding must be 0 (it's basically like an odd fixed- point representation, rather than a bitfield).
* video: Add sigmoidal upscaling to avoid ringing artifactsNiklas Haas2015-01-093-1/+56
| | | | | | | | |