aboutsummaryrefslogtreecommitdiffhomepage
path: root/video
Commit message (Collapse)AuthorAge
* vd_lavc: report actually used hwdec APIGravatar wm42015-05-25
| | | | | Instead of the requested one, which can be just "auto", and which is rather useless.
* vf_dlopen: declare as deprecatedGravatar wm42015-05-25
| | | | | Mostly to see whether someone uses it, and if a better solution can be worked out. (It's simple enough to be supported forever.)
* cocoa: don't load hardcoded icon if running from bundleGravatar Stefano Pigozzi2015-05-25
| | | Makes ricers happy.
* vo_null: add framerate emulationGravatar wm42015-05-24
|
* vo_opengl: switch to new OpenGL backend API for icc-profile-autoGravatar Niklas Haas2015-05-22
| | | | The current code just segfaults.
* vo_opengl: vda: make it work anywhereGravatar wm42015-05-21
| | | | | | | | 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 2Gravatar wm42015-05-21
| | | | | 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 optionGravatar wm42015-05-21
| | | | Completely useless.
* vo_xv: make number of buffers configurableGravatar wm42015-05-20
|
* x11: never forcefully terminate xdg-screensaver processGravatar wm42015-05-18
| | | | | | 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 reliableGravatar wm42015-05-15
| | | | | | | | | | | | | | 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.
* vf_vapoursynth: reject unaligned video sizesGravatar wm42015-05-15
| | | | Leads to some nice memory corruption otherwise.
* vo: remove suspicious lineGravatar wm42015-05-15
| | | | | pts can never be 0 or negative. If there is no frame, some code below catches this case by checking hasframe.
* Remove trailing whitespacesGravatar Michael Vetter2015-05-15
|
* dxva2: support HEVCGravatar wm42015-05-14
| | | | | | | | | | | | This is pretty much copy&pasted from Libav commit a7e0380497306d9723dec8440a4c52e8bf0263cf. Note that if FFmpeg was not compiled with HEVC DXVA2 support or your video drivers do not support HEVC, the player will not fallback and just fail decoding any video. This is because libavcodec appears not to return an error in this case. The situation is made worse by the fact that MSYS2 is on an ancient MinGW-w64 release, which does not have the required headers for HEVC DXVA2 support.
* vo_opengl: hardcode rquested GL version in backendsGravatar wm42015-05-14
| | | | | The requested version field didn't make much sense anymore, and was even partially ignored by some backends.
* x11: use new OpenGL backend APIGravatar wm42015-05-14
|
* vo_opengl: create new API for OpenGL VO backendsGravatar wm42015-05-14
| | | | | | | | | | 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 GLESGravatar wm42015-05-14
| | | | | | | | 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/initializationGravatar wm42015-05-13
| | | | | 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 callsGravatar wm42015-05-13
| | | | Awkward stuff not needed anymore.
* cocoa: redo synchronizationGravatar wm42015-05-13
| | | | | | | | | | | | | | | | | | | | | 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 leftoversGravatar wm42015-05-13
|
* vda: add support for nv12 image formatsGravatar Stefano Pigozzi2015-05-13
| | | | | | | | | 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 pausedGravatar wm42015-05-13
| | | | | | 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 beforeGravatar wm42015-05-12
| | | | | | | | | | | 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 differentlyGravatar wm42015-05-12
| | | | | | | | | | | | | | | | | | 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 timingGravatar wm42015-05-12
| | | | | | | | | | | | | | | | 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 interpolationGravatar wm42015-05-12
| | | | | | | | | | | | | | | | | 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 defaultGravatar wm42015-05-12
| | | | | | | | | (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 optionsGravatar wm42015-05-12
| | | | Quite an oversight.
* vo: always call draw_image_timed() if availableGravatar wm42015-05-12
| | | | | | | 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 wrappersGravatar wm42015-05-11
| | | | | | | 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 declarationGravatar wm42015-05-11
|
* cocoa: add missing break statements in switchGravatar wm42015-05-11
| | | | | 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 macroGravatar wm42015-05-11
|
* path: make mp_path_join accept normal C stringsGravatar wm42015-05-09
| | | | | 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 settingsGravatar wm42015-05-08
| | | | | | | | | 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 panscanGravatar wm42015-05-08
| | | | | | 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 parameterGravatar wm42015-05-06
|
* cocoa: lock cocoa main thread on uninitGravatar wm42015-05-06
| | | | | | | | | | | | | | | | | | 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 formatGravatar wm42015-05-05
| | | | | | | | 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.
* sws_utils: re-use avcolorspace for sws colorspacesGravatar Niklas Haas2015-05-04
| | | | | This lets us avoid having to maintain two separate copies of the colorspace mapping functions.
* vo_opengl: gl_lcms: fix cache dir creation with path expansionGravatar wm42015-05-03
| | | | | | 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.
* cocoa: always compile OSX application code with cocoaGravatar wm42015-05-02
| | | | | | | | | | | | | | This unbreaks compiling command line player and libmpv at the same time. The problem was that doing so silently disabled the OSX application thing - but the command line player can not use the vo_opengl Cocoa backend without it. The OSX application code is basically dead in libmpv, but it's not that much code anyway. If you want a mpv binary that does not create an OSX application singleton (and creates a menu etc.), you must disable cocoa completely, as cocoa can't be used anyway in this case.
* vo_opengl: gl_lcms: create cache dirGravatar wm42015-05-02
| | | | Minor user convenience.
* vo_opengl: gl_lcms: make sure win32 unicode fopen() wrapper is enabledGravatar wm42015-05-02
|
* vo_opengl: gl_lcms: minor simplificationGravatar wm42015-05-02
|
* vo_opengl: gl_lcms: use mp_path_join()Gravatar wm42015-05-02
| | | | | | | Maybe this fixes the win32 problems a user had, or maybe not. Also, check if cache_dir is set at all. An empty string should be equivalent to "unset".
* vo_opengl: gl_lcms: make ICC loading less verboseGravatar Niklas Haas2015-05-01
| | | | | Especially with the new ICC cache rework, you get a lot of ugly output messages that don't really contain any meaningful content.
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-06 17:03:39 +0000