summaryrefslogtreecommitdiffstats
path: root/video/out
Commit message (Collapse)AuthorAgeFilesLines
* mp_image: allow passing NULL to mp_image_new_custom_ref()wm42016-04-251-2/+1
| | | | | | | A minor simplification. Most callers don't need this, and there's no good reason why the caller should provide an "initializer" like this. (This function calls mp_image_new_dummy_ref(), which has no reason for an initializer either.)
* vo_opengl: always reset some GL state when leaving rendererwm42016-04-221-5/+6
| | | | | | The active texture and some pixelstore parameters are now always reset to defaults when entering and leaving the renderer. Could be important for libmpv.
* vo_opengl: fix an outdated commentwm42016-04-161-3/+1
| | | | This wasn't updated over multiple iterations.
* vo_lavc: fix build on Libavwm42016-04-151-2/+1
| | | | | OF COURSE Libav doesn't have AV_PICTURE_TYPE_NONE. Why the fuck would it?
* vo_lavc: unsupport deprecated AVFMT_RAWPICTUREwm42016-04-151-23/+12
| | | | | | | | As of ffmpeg git master, only the libavdevice decklink wrapper supports this. Everything else has dropped support. You're now supposed to use AV_CODEC_ID_WRAPPED_AVFRAME, which works a bit differently. Normal AVFrames should still work for these encoders.
* vo_lavc: send refcounted AVFrame to encoderwm42016-04-151-4/+4
| | | | | | This potentially makes it more efficient, and actually makes it simpler. Yes, AV_PICTURE_TYPE_NONE is the default for pict_type.
* lcms: include math.hwm42016-04-151-0/+1
| | | | Fixes #3053.
* vo_opengl: rpi: don't include x11 header filewm42016-04-151-1/+0
| | | | Copy & paste bug.
* vo_opengl: simplify and improve up scale=oversampleNiklas Haas2016-04-121-21/+5
| | | | | | | | | Since what we're doing is a linear blend of the four colors, we can just do it for free by using GPU sampling. This requires significantly fewer texture fetches and calculations to compute the final color, making it much more efficient. The code is also much shorter and simpler.
* vaapi: determine surface format in decoder, not in rendererwm42016-04-111-37/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, we have made the assumption that a driver will use only 1 hardware surface format. the format is dictated by the driver (you don't create surfaces with a specific format - you just pass a rt_format and get a surface that will be in a specific driver-chosen format). In particular, the renderer created a dummy surface to probe the format, and hoped the decoder would produce the same format. Due to a driver bug this required a workaround to actually get the same format as the driver did. Change this so that the format is determined in the decoder. The format is then passed down as hw_subfmt, which allows the renderer to configure itself with the correct format. If the hardware surface changes its format midstream, the renderer can be reconfigured using the normal mechanisms. This calls va_surface_init_subformat() each time after the decoder returns a surface. Since libavcodec/AVFrame has no concept of sub- formats, this is unavoidable. It creates and destroys a derived VAImage, but this shouldn't have any bad performance effects (at least I didn't notice any measurable effects). Note that vaDeriveImage() failures are silently ignored as some drivers (the vdpau wrapper) support neither vaDeriveImage, nor EGL interop. In addition, we still probe whether we can map an image in the EGL interop code. This is important as it's the only way to determine whether EGL interop is supported at all. With respect to the driver bug mentioned above, it doesn't matter which format the test surface has. In vf_vavpp, also remove the rt_format guessing business. I think the existing logic was a bit meaningless anyway. It's not even a given that vavpp produces the same rt_format for output.
* encode_lavc: Migrate to codecpar API.Rudolf Polzer2016-04-111-31/+35
|
* aspect: rework --video-unscaledNiklas Haas2016-04-101-22/+12
| | | | | | | | | | | | | | | | | | | In the past, --video-unscaled also disabled zooming and aspect ratio corrections. But this didn't make much sense in terms of being a useful option. The new behavior just sets the initial video size to be unscaled, but it's still affected by zoom commands and aspect ratio corrections. To get the old behavior back, --video-aspect=0 --video-zoom=0 need to be added as well (in the general case). Most of the time it should not make a difference though. Also, there seems to have been some additional dst_rect clamping code inside src_dst_split_scaling that didn't seem to either be necessary nor ever get triggered. (The code immediately above it already makes sure to crop the video if it's larger than the dst_rect) No idea why it was there, but I just removed it.
* aspect: remove useless debug messageswm42016-04-101-10/+2
| | | | Never needed them. This makes the code slightly more readable.
* vo_opengl: improve rotation handling (again)wm42016-04-082-44/+47
| | | | | | | | | | | | | | | | | Apply basic transformations like rotation by 90° and mirroring when sampling from the source textures. The original idea was making this part of img_tex.transform, but this didn't work: lots of code plays tricks on the transform, so manipulating it is not necessarily transparent, especially when width/height are switched. So add a new pre_transform field, which is strictly applied before the normal transform. This fixes most glitches involved with rotating the image. Cropping and rotation are now weirdly separated, even though they could be done in the same step. I think this is not much of a problem, and has the advantage that changing panscan does not trigger FBO reallocations (I think...).
* vo_opengl: log if glGetString(GL_VERSION) returns NULLwm42016-04-081-1/+3
| | | | | | Typically happens with some implementations if no context is currrent, or is otherwise broken. This is particularly relevant to the opengl_cb API, because the API user will have no other indication what went wrong.
* vo_opengl: videotoolbox: use kCVPixelBufferLock_ReadOnly for screenshotswm42016-04-071-7/+8
| | | | Why not.
* videotoolbox: change how videotoolbox format is managedwm42016-04-072-3/+20
| | | | | | | | | | | | | | | | | | | | | | | The underlying intention of this code is to make changing --videotoolbox-format at runtime work. For this reason, the format can't just be statically setup, but must be read from the option at runtime. This means the format is not fixed anymore, and we have to make sure the renderer is property reinitialized if the format changes. There is currently no way to trigger reinit on this level, which is why the mp_image_params.hw_subfmt field was introduced. One sketchy thing remains: normally, the renderer is supposed to be involved with VO format negotiation, which would ensure that the VO can take the format at all. Since the hw_subfmt is not part of this format negotiation, it's implied the get_vt_fmt() callback only returns formats supported by the renderer. This is not necessarily clear because vo_opengl checks this with converted_imgfmt separately. None of this matters in practice though, because we know all formats are always supported. (This still requires somehow triggering decoder reinit to make the change effective.)
* vo: don't reset vsync statistics on seeks etc.wm42016-04-061-9/+14
| | | | | | | | | | | | | | | | | | The sync-by-display mode relies on using the vsync statistics for timing. As a consequence discontinuities must be handled somehow. Until now we have done this by completely resetting these statistics. This can be somewhat annoying, especially if the GL driver's vsync timing is not ideal. So after e.g. a seek it could take a second until it locked back to the proper values. Change it not to reset all statistics. Some state obviously has to be reset, because it's a discontinuity. To make it worse, the driver's vsync behavior will also change on such discontinuities. To compensate, we discard the timings for the first 2 vsyncs after each discontinuity (via num_successive_vsyncs). This is probably not fully ideal, and num_total_vsync_samples handling in particular becomes a bit questionable.
* vo_opengl: fix build breakagewm42016-04-061-1/+1
|
* vo_opengl: minor simplificationwm42016-04-051-3/+2
| | | | It's the same functionally.
* vo_opengl: fix nnedi + rectangle textureswm42016-04-053-4/+4
| | | | Shader compilation error due to incompatible samplers.
* aspect: make video-zoom logarithmicNiklas Haas2016-04-031-1/+2
| | | | | | | | | | | | | The past behavior was a bit weird, especially when zooming out. There was no simple way to zoom in or out in consistent increments using keybindings alone. The new behavior preserves most of the old behavior's semantics but scales out to infinity better. It coincidentally also makes it really easy to get clean power of 2 ratios (e.g. 2x, 4x, 8x and their inverses). Fixes #3004.
* gl_lcms: choose BT.1886 gamma per-channelNiklas Haas2016-04-011-24/+35
| | | | | | | | | This makes the black point closer (chromatically) to the white point, by ensuring channels keep their consistent brightness ratios as they go down to zero. I also raised the 3DLUT version as this changes semantics and is a separate commit from the previous one.
* vo_opengl: generate 3DLUT against source and use full BT.1886Niklas Haas2016-04-017-76/+162
| | | | | | | | | | | | | | | | | | | This commit refactors the 3DLUT loading mechanism to build the 3DLUT against the original source characteristics of the file. This allows us, among other things, to use a real BT.1886 profile for the source. This also allows us to actually use perceptual mappings. Finally, this reduces errors on standard gamut displays (where the previous 3DLUT target of BT.2020 was unreasonably wide). This also improves the overall accuracy of the 3DLUT due to eliminating rounding errors where possible, and allows for more accurate use of LUT-based ICC profiles. The current code is somewhat more ugly than necessary, because the idea was to implement this commit in a working state first, and then maybe refactor the profile loading mechanism in a later commit. Fixes #2815.
* vo_opengl: draw transparency checkerboard after upscalingNiklas Haas2016-03-291-4/+10
| | | | | | | | | | | | | This also draws it after color management etc. In a nutshell, this change makes the transparency checkerboard independent of upscaling, panning, cropping etc. It will always be the same apparent size and position (relative to the window). It will also be independent of the video colorspace and such things. (Note: This might cause white imbalance issues if playing a file with a white point that does not match the display, in absolute colorimetric mode. But that's uncommon, especially in conjunction with transparent image files, so it's not a primary concern here)
* vo_opengl: always premultiply alphawm42016-03-294-5/+1
| | | | | | Until now, we've let the windowing backend decide. But since they usually require premultiplied alpha, and premultiplied alpha is easier to handle, hardcode it.
* vo_opengl: fix rotation directionwm42016-03-291-1/+1
| | | | | | The recent changes fixed rotation handling, but reversed the rotation direction. The direction is expected to be counter-clockwise, because demuxers export video rotation metadata as such.
* vo_opengl: slightly compress gl_set_debug_logger()wm42016-03-281-7/+2
| | | | No functional changes.
* vo_opengl: reduce temporary variables in gl_transform_trans()wm42016-03-281-5/+5
| | | | | Using a single gl_transform variable instead of many float ones makes it easier to see what it's doing. No functional change.
* vo_opengl: fix rotationwm42016-03-282-48/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | This has been completely broken since commit 93546f0c. But even before, rotation handling did not make too much sense. In particular, it rotated the contents of the cropped image, instead of adjusting the crop rectangle as well. The result was that things like panscan or zooming did not behave as expected with rotation applied. The same is true for vertical flipping. Flipping is triggered by negative image stride. OpenGL does not support flipping the image on upload, so it's done as part of the rendering. It can be triggered with --vf=flip, but other filters and even decoders could setup negative stride to flip the image. Fix these issues by applying transforms to texture coordinates properly, and by making rotation and flipping part of these transforms. This still doesn't work properly for separated scaling. The issue is that we'd have to adjust how the passes are done. For now, pick a very stupid solution by rotating the image to a FBO, and then scaling from that. This has the avantage that the scale logic doesn't have to be complicated for such a rare case. It could be improved later. Prescaling is apparently still broken. I don't know if chroma positioning works properly either. None of this should affect the case with no rotation.
* vo_opengl: fix row-major vs. column-major confusionwm42016-03-282-4/+7
| | | | | | | | | gl_transform_vec() assumed column-major, while everything else seemed to assumed row-major memory organization for gl_transform.m. Also, gl_transform_trans() seems to contain additional confusion. This didn't matter until now, as everything has been orthogonal, this the swapped matrix entries were always 0.
* vo_opengl: don't upload potentially uninitialized memory to GL bufferwm42016-03-281-1/+1
| | | | | | | | | If the texture count is lower than 4, entries in va.textcoord[] will remain uninitialized. While this is unlikely to be a problem (since these values are unused on the shader side too), it's not nice and might explain some things which have shown up in valgrind. Fix by always initializing the whole thing.
* vo_openg: fix debanding + rectangle-textureswm42016-03-271-1/+1
|
* vo_opengl: minor coding style adjustmentwm42016-03-241-3/+4
|
* vo_opengl: utils: some more minor shader string building optimizationwm42016-03-241-23/+35
| | | | | | | | | | | | Instead of reallocating almost all of the shader string several times per pass, build it into a fixed buffer that will be reallocated as needed. While this still uses a linear search and full comparison of the shader text, this will compare the shader's string length first before doing a full comparison as a nice side effect. (That's also why the fragment shader is compared first - it's more likely to be different for different cache entries than the vertex shader stub.)
* vo_opengl: utils: slightly optimize shader string buildingwm42016-03-231-22/+21
| | | | | Use bstr as appending buffer, which should avoid frequent reallocation and copying. The previous commit should help with this a little.
* vo_opengl_cb: fix NULL derefwm42016-03-231-1/+2
| | | | | Broken in commit d6c99c85. vo_opengl_cb.c adds the corner case that p->osd can be NULL. This make opengl-cb always crash.
* vo_opengl: fix blend-subtitles=video in some caseswm42016-03-221-0/+1
| | | | | | | | | Shader miscompilation and bad output. Regression probably since commit 93546f0c (or one of the following ones). Fixes #2982.
* vo_opengl, osd: allow osc.lua to react faster on resizeswm42016-03-213-10/+25
| | | | | | | | | Glitches when resizing are still possible, but are reduced. Other VOs could support this too, but don't need to do so. (Totally avoiding glitches would be much more effort, and probably not worth the trouble. How about you just watch the video the player is playing, instead of spending your time resizing the window.)
* vo_opengl: GLX: try to create 3.3 core profile contextwm42016-03-193-6/+26
| | | | | | | | | | | | | | | | Until now, we have tried to create a GL 3.0 context. The main reason for this is that many Mesa-based drivers did not support anything better. But some drivers (Mesa AMD) will not report a higher OpenGL version, because their compatibility mode is restricted. While later GL features are reported as extensions just fine, there doesn't seem to be a way to determine or enable higher GLSL versions. Add some more shitty hacks to try to deal with this messed up situation, and try to probe each interesting GL version separately (starting with 3.3, then 3.2 etc.). Other backends might suffer from similar problems, but these will have to deal with it on their own. Probably fixes #2938, or maybe not.
* Revert "wayland: set fs mode on every configure"Emmanuel Gil Peyrot2016-03-191-6/+5
| | | | | | | | | Prevents an infinite loop of configure event and set_fullscreen request on Weston and other compositors respecting the protocol. Fixes #2817 This reverts commit eb6b2b6e50e6e3d3db41190ad818d8b966750734.
* vo_opengl: dxva2egl: ignore alpha component in the mapped videowm42016-03-171-3/+1
| | | | | | | | | | | converted_imgfmt will be used by the renderer logic to build an appropriate shader chain. It doesn't influence the format of any textures. Thus it doesn't matter whether the hw video surface is mapped as RGB or RGBA. What matters is if the video actually contains alpha or not. Since virtually all hardware decoder do not support alpha in any way, this can be hardcoded as "no alpha". This avoids unnecessary GPU work.
* vo_opengl: fix operation without GL_ARB_texture_rgwm42016-03-171-4/+11
| | | | | | | | This also gets rid of the kind of hard to read texture swizzle setup and turns it into something dumber. Assumes that we don't create any FBOs with 2 channel formats. (Only the video source textures are handled by this commit.)
* vo_opengl: fix sharpen filterwm42016-03-163-4/+5
| | | | | | Regression since commit 93546f0c. Fixes #2956.
* vo_opengl: only open one OpenGL/DX interop handle when using dxva2Kevin Mitchell2016-03-152-18/+23
| | | | | | | | | Previously, gl->DXOpenDeviceNV was called twice using dxva2 with dxinterop. AMD drivers refused to allow this. With this commit, context_dxinterop sets its own implementation of MPGetNativeDisplay, which can return either a IDirect3DDevice9Ex or a dxinterop_device_HANDLE depending on the "name" request string. hwdec_dxva2gldx then requests both of these avoiding the need to call gl->DXOpenDeviceNV a second time.
* x11, input: move mime type drag&drop negotiation to common codewm42016-03-151-2/+52
| | | | | | | | | | | | | Drag&drop mechanisms typically support multiple types for the drop data. Move most of the logic which types are accepted and preferred to event.c, where the data is also interpreted. (Maybe sorting the types by assigning scores is over-engineered, since they're already sorted by preference, but it's actually not much more code.) Not very interesting/meaningful yet, but preparation for the next commit.
* x11: move vo->input_ctx accesses to x11->input_ctxwm42016-03-152-19/+21
| | | | | | Reduces VO access and makes the code more self-contained. (One day the windowing backend code should not access the VO anymore. We're just not quite there yet.)
* vo_opengl: add dxva2 interop to angle backendKevin Mitchell2016-03-102-0/+350
| | | | | | Like dxinterop, this uses StretchRect or RGB conversion. This is unavoidable as long as we use the dxva2 API, as there is no way to access the raw hardware decoded Direct3D9 surfaces.
* vo_opengl: use the same type for cached and current uniform valueswm42016-03-101-12/+11
| | | | Slightly improvement over the previous commit.
* vo_opengl: cache the values of the uniform variablesigv2016-03-101-20/+31
|
* vo_opengl: cache the locations of the uniform variablesigv2016-03-091-6/+13
|
* vo_opengl: decrease default superxbr-edge-strengthNiklas Haas2016-03-071-1/+1
| | | | | | The default of 1.0 was basically making half the algorithm do nothing, since it turned off all diagonal contributions. The upstream default is 0.6, and this produces a more reasonable image.
* vo_opengl: improve superxbr algorithmNiklas Haas2016-03-071-12/+11
| | | | | | | | The values were changed to reflect an upstream change in the source for the super-xBR implementation. The anti-ringing code was basically not working at all, the new algorithm _significantly_ improves the result (reduces ringing).
* vo_opengl: refactor superxbr algorithmNiklas Haas2016-03-073-133/+150
| | | | | | | | | | | | | | | | | | This is a fresh implementation from scratch that carries with it significantly less baggage and verbosity from the previous (ported) version. The actual values for the masks and such were copied from the current code. Behavior and performance should be unaffected. An important difference between the old code and the new code is that the new code always explicitly samples from the first component, rather than being able to process multiple planes at once. Since prescale-luma only affects luma, I deemed this unnecessary. May change in the future, if prescale-chroma ever gets implemented. But prescaling multiple planes would be slow to do this way. (Better would be to generalize it to differently-sized vectors)
* vo_xv, vo_x11: warn that these VOs should not be usedwm42016-03-062-0/+5
|
* vo_opengl: refactor plane-skipping optimizationsNiklas Haas2016-03-051-16/+26
| | | | | | Instead of hard-coding the logic and planes to skip, factor this out to a reusible function, and instead add the number of relevant coordinates to the texture state.
* vo_opengl: rename prescale to prescale-lumaNiklas Haas2016-03-052-13/+14
| | | | | | Since prescale now literally only affects the luma plane (and the filters are all designed for luma-only operation either way), the option has been renamed and the documentation updated to clarify this.
* vo_opengl: add macros for scaler unitsNiklas Haas2016-03-052-34/+42
| | | |