summaryrefslogtreecommitdiffstats
path: root/video/out
Commit message (Collapse)AuthorAgeFilesLines
* Various spelling fixesMarcin Kurczewski2015-06-182-9/+9
| | | | Signed-off-by: wm4 <wm4@nowhere>
* win32: use atomics for COM interface refcountwm42015-06-141-4/+5
|
* vo_drm: fixed crashes with --profile=pseudo-guiMarcin Kurczewski2015-06-131-1/+1
|
* vo_opengl: fix a small memory leak when loading user shaderswm42015-06-091-1/+1
| | | | | When gl_shader_cache was destroyed, existing user shader entries leaked the file path string.
* vo_opengl: fix dangling pointers with vo_cmdlinewm42015-06-091-0/+24
| | | | | | | | | | | | gl_video_set_options() does not acquire ownership of the opts parameter or its contents. In case of vo_cmdline, opts will point to temporary memory. This memory will be free'd at a later point, and p->opts will point to free'd memory on the next reinitialization. The fix is pretty ugly, but it's a quick bug fix. This can probably be removed once VO sub-options are exposed as properties. Fixes #2035.
* gl_osd: fix license headerwm42015-06-081-0/+5
| | | | | | | All vo_gl.c related code has been GPL+LGPL dual-licensed. The OSD code is no exception and is also derived from vo_gl.c. Thus it should have the same license (although I think technically speaking sub-licensing it by removing one of the licenses is ok).
* vo: clarify conditionwm42015-06-081-1/+1
| | | | | This is (at least currently) redundant, but makes the code more explicit. (This was discussed on IRC.)
* vo: restore frame-drop logic for high-fps clipsAvi Halachmi (:avih)2015-06-071-0/+22
| | | | | | | | | Commits 92b27be and f4ce99d removed high-fps logic to to a bug. That bug was a missing parenthesis around everything after duration >= 0 && ... at the removed code. This patch restores the removed code, fixes the bug and then refactors the code a bit.
* Revert "opengl: drop less frames when clip and display have similar fps"wm42015-06-071-9/+1
| | | | | | | This reverts commit f1746741dee6000b7fd139e7a10f72aba0674b3b. Together with the other revert, this fixes #2023 (the reason being broken framedrop handling - it was dropping frames when it shouldn't).
* Revert "vo: improve frame drop logic on high playback rate"wm42015-06-071-11/+3
| | | | This reverts commit ffcad1a72b9a3bf5a7ac5ddcbfa71ec19b6faf9b.
* vo_vdpau: add a NULL check, verify image dimensionswm42015-06-061-1/+2
| | | | | | | | read_output_surface() could fail and return NULL. Also, make sure we don't set the image to a size larger than the allocated size. Normally this shouldn't happen, but in theory it could in corner cases; this is for robustness.
* vo_vdpau: limit output surfaces to allowed maximum dimensionswm42015-06-051-4/+12
| | | | | | We can't do much in this case, but at least we can not call the vdpau API functions with too large sizes. Apparently the API considers this undefined behavior, and random stuff might happen.
* vo_vdpau: directly get surface size from surface for screenshotswm42015-06-051-6/+11
| | | | | | | The previous code was not wrong, but I'd claim this makes the code more robust. If a situation could happen in which the passed surface size is incorrect, we could have passed a too small image, and VdpOutputSurfaceGetBitsNative could have randomly overwritten memory.
* vo_vdpau: shorten 2 variable nameswm42015-06-051-10/+9
| | | | Why should I be required to type so much?
* filter_kernels: distinguish between regular/EWA robidouxNiklas Haas2015-06-051-2/+4
| | | | | This is because it turns out the regular robidoux is pretty useful for tscale etc.
* vo_vdpau: check maximum video sizewm42015-06-041-0/+19
| | | | | | | | | Check the maximum size of video surfaces, and refuse initialization if the video is too large for them. Maybe we could do something more sophisticated, like inserting a software scaler. On the other hand, this would have a very questionable benefit, as it would be guaranteed to be too slow.
* win32: fix window resize logicwm42015-05-311-2/+3
| | | | | | Reconfiguring with the same video size should never cause the window to resize back to the video size (if the user changed its size). This was broken and it resized anyway.
* vo_opengl: output slightly more debugging info on backend probingwm42015-05-301-0/+2
|
* vo: move up vo_wayland in autoprobe listwm42015-05-301-3/+3
| | | | | When running on Wayland, and vo_opengl is not available or rejected for some reason, it's better to use vo_wayland instead of e.g. vo_x11.
* vo_drm: fix not using BUF_COUNTMarcin Kurczewski2015-05-291-5/+4
|
* vo_drm: fix centering with regard to strideMarcin Kurczewski2015-05-291-13/+16
|
* vo_opengl: avoid broken shader if hwdec fails to provide textureswm42015-05-281-1/+4
| | | | | | | | | | If gl_hwdec_driver.map_image fails, all textures will be set to 0. This in turn makes pass_prepare_src_tex() skip generation of the texture uniforms, which leads to a shader compilation error, as e.g. texture0 is not defined but expected to exist and accessed. Set the textures to an invalid non-0 ID instead. OpenGL can deal with it.
* vdpau: retrieve mixer parameters directly from the hw surfacewm42015-05-281-4/+1
| | | | | | | | | | | | Always configure the vdpau mixer based on the current surface sent to it. Before this, we just hardcoded the chroma type, and the surface size was essentially a guess. Calling VdpVideoSurfaceGetParameters() on every surface is a bit suspicious, but it appears it's a cheap function (just requiring some locks and a table lookup). This way we avoid creating another complicated mechanism to carry around the actual surface parameters with a mp_image/AVFrame.
* vo_drm: Expose mode ID option to usersMarcin Kurczewski2015-05-281-10/+19
|
* vo_drm: Fix resolution not restored after exitingMarcin Kurczewski2015-05-281-1/+1
|
* vo_drm: Fix stride problem for certain devicesMarcin Kurczewski2015-05-281-1/+1
|
* vo_opengl: rename use_full_range to use_normalized_rangewm42015-05-271-8/+8
| | | | | As suggested by haasn. The term "full range" makes it sound like it has to do with TV vs. PC range, which is not the case at all.
* vo_opengl: fix source-shader + XYZ inputNiklas Haas2015-05-271-2/+5
|
* vo_opengl: CMS no longer implies linear scalingNiklas Haas2015-05-271-4/+1
| | | | | | | | | | | They're completely orthogonal concepts, merged in the past due to convenience and ease of implementing it in the old #ifdef hell renderer. Especially after the CMS stuff was generalized by 634b4a, this was a trivial change to implement and also means color management will be much higher quality when enabled with vo=opengl (which had quantization issues in the past due to the 8 bit FBO format and upscaling), since it can be done in a single pass now.
* vo_opengl: icc-profile overrides icc-profile-autoNiklas Haas2015-05-271-1/+2
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: add support for custom shadersNiklas Haas2015-05-277-53/+264
|
* cocoa: don't load hardcoded icon if running from bundleStefano Pigozzi2015-05-251-0/+3
| | | Makes ricers happy.
* vo_null: add framerate emulationwm42015-05-241-4/+34
|
* vo_opengl: switch to new OpenGL backend API for icc-profile-autoNiklas Haas2015-05-221-1/+1
| | | | The current code just segfaults.
* vo_opengl: vda: make it work anywherewm42015-05-212-5/+35
| | | | | | | | A rather dumb hack to copy the problematic rectangle textures (mandated by VDA) into 2D ones. (This isn't done yet for OpenGL 3.0+. We need to make sure the performance isn't reduced too much by it.)
* video: do not align source position to 2wm42015-05-212-11/+11
| | | | | vo_direct3d still seems to require this (tested on Windows 8.1 with Intel graphics). Do it in vo_direct3d instead of messing with all VOs.
* vo_opengl: remove npot optionwm42015-05-211-16/+0
| | | | Completely useless.
* vo_xv: make number of buffers configurablewm42015-05-201-3/+8
|
* x11: never forcefully terminate xdg-screensaver processwm42015-05-182-9/+8
| | | | | | It sometimes happens on exit, and it's probably a bad idea. If the process hangs on exit (possibly due to stupid hardcoded timeouts it's doing), mpv will also hang now, unfortunately.
* x11: attempt to make initial fullscreening more reliablewm42015-05-151-0/+3
| | | | | | | | | | | | | | It appears some WMs have a problem with out method of setting initial fullscreen mode. We assume that if the window's _NET_WM_STATE includes _NET_WM_STATE_FULLSCREEN before mapping the window, the WM will show it as fullscreen at mapped. EWMH doesn't say anything that this should work, although one could argue that it's implied. In any case, since it's not standard behavior without at least some doubt, it's probably a good idea to try the "old" method as well. Fortunately, it should be idempotent. See #1937, #1920.
* vo: remove suspicious linewm42015-05-151-1/+1
| | | | | pts can never be 0 or negative. If there is no frame, some code below catches this case by checking hasframe.
* Remove trailing whitespacesMichael Vetter2015-05-151-1/+1
|
* vo_opengl: hardcode rquested GL version in backendswm42015-05-146-26/+9
| | | | | The requested version field didn't make much sense anymore, and was even partially ignored by some backends.
* x11: use new OpenGL backend APIwm42015-05-143-24/+34
|
* vo_opengl: create new API for OpenGL VO backendswm42015-05-143-23/+106
| | | | | | | | | | An attempt to get rid of the weird mix of callbacks that take either struct vo or MPGLCopntext as parameter. This is not perfect, and the API will probably change a bit until all other code is ported to it. the main question is how to separate struct vo completely from the windowing code, which actually needs vo for very little. In the end, the legacy callbacks will be dropped.
* vo_opengl: change user options for requesting GLESwm42015-05-146-36/+9
| | | | | | | | Instead of having separate backends, make use of GLES a flag. This reduces the number of backends and the resulting annoyances. Also, nobody cares about using GLES, so there's no backward compatibility either.
* vo_opengl: merge GL backend creation/initializationwm42015-05-131-28/+20
| | | | | The final goal is to remove the nonsense separation between the 3 backend init/vo_init/GL context creation calls.
* vo_opengl: remove mpgl_lock callswm42015-05-133-63/+7
| | | | Awkward stuff not needed anymore.
* cocoa: redo synchronizationwm42015-05-133-169/+156
| | | | | | | | | | | | | | | | | | | | | Before this change, Cocoa state was accessed from both the VO and the Cocoa main thread. This was probably not a good idea. There was some locking as well as implicit synchronization using the dispatch mechanism, but it wasn't watertight. Change this completely. Now Cocoa things are always accessed from the main thread only. The old mutex falls away, as well as the vo_cocoa_set_current_context() function, which implicitly used the lock to coordinate VO accesses. With the new code, the VO thread generally has to wait for the main thread, while the main thread never waits for the VO and rarely accesses it. Fortunately, this is rather straight forward, and most of this is achieved by making vo_cocoa_control() run on the main thread. The logic of the code does generally not change. Some aspects are trickier. Apparently we can't access the NSOpenGLContext from the VO thread, because this object is not thread- safe. We use some CGLContextObj functions instead, such as for making the context current and swapping the buffers.
* vo_opengl: remove some more Cocoa resize leftoverswm42015-05-134-31/+0
|
* vda: add support for nv12 image formatsStefano Pigozzi2015-05-131-20/+99
| | | | | | | | | The hardware always decodes to nv12 so using this image format causes less cpu usage than uyvy (which we are currently using, since Apple examples and other free software use that). The reduction in cpu usage can add up to quite a bit, especially for 4k or high fps video. This needs an accompaning commit in libavcodec.
* vo: avoid burning CPU when pausedwm42015-05-131-1/+2
| | | | | | Some code always calls vo_event(), even with event==0, which leads to immediate wakeup, which in turn causes the function to be called again. This would burn CPU, which was especially noticeable when paused.
* cocoa: make live-resizing as fast as beforewm42015-05-123-9/+14
| | | | | | | | | | | Interrupt video timing. This means the Cocoa event loop does not have to up to 2 video frame durations until redrawing the frame finally has finished. We abuse the VO event flags for this. Eventually this should use wait_vo() or so in the video timing wait function, but for now the interaction this would require with the code of other VOs/backends would cause too much of a mess.
* cocoa: handle live-resizing differentlywm42015-05-123-42/+41
| | | | | | | | | | | | | | | | | | Instead of requiring a complicated mechanism to share the entire OpenGL and renderer state between VO and Cocoa thread just to do the redrawing during live-resize on the Cocoa thread, let the Cocoa thread wait on the VO thread. This wil allow some major simplifications and cleanups in the future. One problem with this is that it can enter a deadlock whenever the VO tries to sync with the Cocoa thread. To deal with this, the Cocoa thread waits with a timeout. This can probably be improved later, though in general this situation can always happen, unless the Cocoa thread waits in a reentrant way. Some other details aren't completely clean either. For example, pending_events should be accessed atomically. This will also be fixed later.
* vo: use pthread_cond_timedwait() for video timingwm42015-05-121-6/+17
| | | | | | | | | | | | | | | | Will be used to make video waiting interruptible with Cocoa (see the following commit). One worry was that this could cause hangs if the system clock jumps backwards. Normally we don't support such behavior, because it's almost impossible to handle it reasonably. E.g. we would have to change the default clock type for condition variables, which in turn would require a custom function for creating condition variables, or so. If the OS even supports different clocks. But it turns out that this is no issue, because other events seem to wakeup the wait call anyway, and mpv internal absolute times use a monotonic clock.
* vo_opengl_cb: add support for interpolationwm42015-05-121-5/+51
| | | | | | | | | | | | | | | | | This uses the OpenGL frame interpolation code, which before could be used by vo_opengl only. Some effort was made to make it behave like vo_opengl, for the better or the worse. As a consequence, there is a minor duplication of code and mechanism. Hopefully this can all be wiped as soon as the VO frame queue/timing mechanism is cleaned up. This also attempts to use mpv_opengl_cb_report_flip() (as called by the API user) to determine the vsync interval. This might need refinement as well. (In general, we simply expect the API user to work in vsync-blocking manner.)
* vo_opengl_cb: add a "block" framedrop mode and make it defaultwm42015-05-121-5/+27
| | | | | | | | | (I have no idea why there are different modes.) Instead of risking to drop frames too early, give it some margin. Since there are situations this could deadlock, wait with a timeout. This can happen if e.g. the API user is refusing to render anything, or if uninitialization is happening.
* vo_opengl_cb: actually set requested optionswm42015-05-121-0/+1
| | | | Quite an oversight.
* vo: always call draw_image_timed() if availablewm42015-05-121-1/+1
| | | | | | | Gives the VOs more flexibility. gl_video.c already ignores the timing info if no interpolation is active, so this requires no further changes.
* threads: use utility+POSIX functions instead of weird wrapperswm42015-05-111-2/+4
| | | | | | | There is not much of a reason to have these wrappers around. Use POSIX standard functions directly, and use a separate utility function to take care of the timespec calculations. (Course POSIX for using this weird format for time values.)
* cocoa: remove unused declarationwm42015-05-111-3/+0
|
* cocoa: add missing break statements in switchwm42015-05-111-0/+2
| | | | | The first one (for VOCTRL_GET_DISPLAY_FPS) could have led to undefined behavior if the FPS was unknown. The second is for general symmetry.
* cocoa: remove unused macrowm42015-05-111-1/+0
|
* path: make mp_path_join accept normal C stringswm42015-05-092-2/+2
| | | | | Instead of bstr. Most callers of this function do not need bstr. The bstr version of this function is now mp_path_join_bstr().
* vo_drm: allow changing video rectangle settingswm42015-05-081-0/+6
| | | | | | | | | Now among other things panscan can be changed during playback. Unfortunately, it flickers. The issue is that reconfig() clears the framebuffer. Removing the clearing shows that the "unused" parts of the picture are not cleared - even though OSD could render there. As such, this is a separate issue.
* vo_drm: don't mutate the current frame when clamping for panscanwm42015-05-081-3/+4
| | | | | | When running with --panscan=1, this could crash - because the current frame was reduced in size each time the image was redrawn, which would result in a failed assertion the second time it's drawn.
* cocoa: remove an unused parameterwm42015-05-063-3/+3
|
* cocoa: lock cocoa main thread on uninitwm42015-05-061-1/+9
| | | | | | | | | | | | | | | | | | This should fix some crashes due to dangling pointers. The problem was that with_cocoa_lock_on_main_thread() is asynchronous. It will not wait until it is finished. In the uninit case, this means the VO could be deallocated and destroyed while cocoa was still running uninit code. So simply wait until it is done by using dispatch_sync(). There were concerns that this could introduce a deadlock by the main thread trying to wait for something on the VO thread. But from what I can see, this never happens, and even if it does, it would crash anyway since the VO is already gone. One remaining worry is the video_resize_redraw_callback. From what I can see, it still can mess things up, and will need a more elaborate fix.
* vo_opengl: change default FBO formatwm42015-05-051-1/+1
| | | | | | | | Reduces (but likely does not remove) the danger of rounding intermediate values down to 8 bit. This is important for cscale, or any other processing that might store raw YUV values in framebuffers. Fixes #1918.
* vo_opengl: gl_lcms: fix cache dir creation with path expansionwm42015-05-031-9/+9
| | | | | | Path expansion (like "~/dir/" in config file) was used inconsistently, so the cache directory wasn't always created correctly. Fix this by moving the path expansion from load_file() to its callers.
*