summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vdpau: fix uninit when init failswm42015-11-012-5/+2
| | | | | | | | | | The uninit() function was called twice if the uninit() function failed (once by init(), once by vd_lavc.c code), which caused crashes due to double-free. (This failure is a corner case, and all other hwdec backends appear to handle this case gracefully.) I do not think this code should be able to deal with uninit() being called other than once. Guarantee that it's called exactly once.
* vo_opengl: win32: fix cross-compilationwm42015-11-011-1/+1
| | | | MXE uses an all-lowercase convention for MS headers.
* vo_opengl: win32: always request MMCSS for DWMwm42015-11-011-0/+5
| | | | | | | | | | | | | | | | | | Quoting MSDN: "Notifies the Desktop Window Manager (DWM) to opt in to or out of Multimedia Class Schedule Service (MMCSS) scheduling while the calling process is alive.". Whatever this means. (An application can change the scheduling priority of the window manager?) Does this improve anything? I have no idea. Certainly this is a program that does multimedia and graphics, so we seem to be a good match for this. Is it bad if we enable this even while playback is inactive or paused? I have no idea either. Is there a magic cargo cult function that will mark our renderer thread as multimedia thing? I have no idea. (We use a function to enable MMCSS for our audio thread in ao_wasapi.)
* vo_opengl: win32: try to enable DwmFlush by defaultwm42015-11-012-9/+46
| | | | | | | | | | | | | | Enable it by default, but not unconditionally. Add an "auto" mode, which disable DwmFlush if the compositor is (probably) inactive. Let's see how this goes. Since I accidentally enabled DwmFlush always by default (more or less) in a previous commit touching this code, this is probably mostly just cargo-culting, and it's uncertain whether it does anything. Note that I still got bad vsync behavior when fullscreening mpv, and making another window visible on the same screen. This happens even if forcing DWM.
* vo: fix no-audio mode with interpolation enabled/display-sync disabledwm42015-11-011-1/+1
| | | | | | | Commit acd5816a broke this. It was stopping playback occasionally. Another case where the non-display-sync interpolation mode (in->vsync_timed==true) is causing a lot of subtle issues and will be removed soon.
* video: fix playback of pal8wm42015-11-011-1/+2
| | | | | | | | | | | PAL8 is the only format that is RGB, has only 1 component, is byte- aligned. It was accidentally detected by the GBRP case as planar RGB. (It would have been ok if it were gray; what ruins it is that it's actually paletted, and the color values do not correspond to colors (but palette entries). Pseudo-pal formats are ok; in fact AV_PIX_FMT_GRAY is rightfully marked as MP_IMGFLAG_YUV_P.
* vo_direct3d: fix operationwm42015-10-313-10/+3
| | | | | | | | | Regression since commit 93db4233. I think the bit that was forgotten here was to remove the vo_w32_config() return value completely. The VO failed to init because that function always returned 0. This commit removes these bits and fixes the VO. Fixes #2434.
* vo_opengl: add vsync-fences optionwm42015-10-303-0/+32
| | | | | | | | | | | | | | | | | | | | | | Yet another relatively useless option that tries to make OpenGL's sync behavior somewhat sane. The results are not too encouraging. With a value of 1, vsync jitter is gone on nVidia, but there are frame drops (less than with glfinish). With 2, I get the usual vsync jitter _and_ frame drops. There's still some hope that it might prevent too deep queuing with some GPUs, I guess. The timeout for the wait call is 1 second. The value is pretty arbitrary; it should just not be too high to freeze the process (if the GPU is un-nice), and not too low to trigger the timeout in normal cases, even if the GPU load is very high. So I guess 1 second is ok as a timeout. The idea to use fences this way to control the queue depth was stolen from RetroArch: https://github.com/libretro/RetroArch/blob/df01279cf318e7ec90ace039d60515296e3de908/gfx/drivers/gl.c#L1856
* vo_opengl: cosmetics: flip the order of 2 functionswm42015-10-301-16/+16
| | | | | draw_frame() is called first, then flip_page(). Order them in the order they're called.
* vo_drm: uninstall signal handlers after quittingrr-2015-10-301-0/+2
|
* vo_drm: handle possible errors from sigactionrr-2015-10-301-6/+17
|
* vo_drm: check if signal already usedrr-2015-10-301-5/+23
|
* video: fix framedrop accounting in display-sync modewm42015-10-301-0/+1
| | | | | | | | | | | | | | Commit a1315c76 broke this slightly. Frame drops got counted multiple times, and also vo.c was actually trying to "render" the dropped frame over and over again (normally not a problem, since frames are always queued "tightly" in display-sync mode, but could have caused 100% CPU usage in some rare corner cases). Do not repeat already dropped frames, but still treat new frames with num_vsyncs==0 as dropped frames. Also, strictly count dropped frames in the VO. This means we don't count "soft" dropped frames anymore (frames that are shown, but for fewer vsyncs than intended). This will be adjusted in the next commit.
* vo_opengl: cache frames only in display-sync modewm42015-10-301-1/+3
| | | | | | | vo_frame.num_vsyncs can be != 1 in some cases in normal sync mode too. This is not a very exact fix, but in exchange it's robust. (These vo_frame flags are way too tricky in combination with redrawing and such.)
* vo_opengl: do not attempt to cache frames in FBO in dumb-modewm42015-10-301-1/+1
| | | | | | | | | | There were occasional shader compilation and rendering failures if FBOs were unavailable. This is caused by the FBO caching code getting active, even though FBOs are unavailable (i.e. dumb-mode). Boken by commit 97fc4f. Fixes #2432.
* vd_lavc: fix declarationswm42015-10-301-6/+6
| | | | | | | Fixes linker failure. How did this ever work? Apparently it did most of the time, but apparently we just got the first case where it didn't. Fixes #2433.
* vo: take normal drop path when dropping in display-sync modewm42015-10-291-4/+3
| | | | I hope there wasn't a deeper reason for exiting early.
* vo_drm: show osd in audio only modePaul B Mahol2015-10-291-8/+13
| | | | Signed-off-by: Paul B Mahol <onemda@gmail.com>
* Replace deprecated av_free_packet() callswm42015-10-281-1/+1
| | | | | | av_free_packet() got finally deprecated. Use av_packet_unref() instead, which has almost the same semantics, has existed for a while, and is available in all FFmpeg and Libav versions we support.
* vo: kill non-working missed frame detectionwm42015-10-271-6/+0
| | | | | | | | | | | | | | | This was not very reliable. In the normal vo_opengl case, this didn't deal well enough with vsync jitter. Vsync timings can jitter quite extremely, up to a whole vsync duration, in which case the "missed" frame counter keeps growing, even though nothing is wrong. This behavior also messes up the A/V difference calculation, but as long as it's within tolerance, it won't provoke extra frame dropping/repeating. Real misses are harder to detect, and I might add such detection later. In the vo_opengl_cb case, this was additionally broken due to the asynchronity between renderer and VO threads.
* vd_lavc: make software decoding fallback an optionRodger Combs2015-10-251-1/+5
|
* vo_opengl: remove source shader leftoverBin Jin2015-10-242-3/+0
| | | | The source shader was removed after deband was introduced.
* vo_opengl: always cache to an FBO when not interpolatingNiklas Haas2015-10-231-4/+29
| | | | | | This speeds up redraws considerably (improving eg. <60 Hz material on a 60 Hz monitor with display-sync active, or redraws while paused), but slightly slows down the worst case (eg. video FPS = display FPS).
* vo: expose frame->num_vsyncs to the VO backendNiklas Haas2015-10-231-1/+0
| | | | | It's not clear why this was originally hidden, but the information is useful for allowing the VO backend to make decisions about caching.
* w32_common: disable IMEJames Ross-Gowan2015-10-231-9/+16
| | | | | | | | | | The IME is not useful for key-bindings. Handle the base ASCII chars instead and don't show the IME window. For the sake of libmpv users, the IME should only be disabled on mpv's GUI thread and not application- wide. No IME on the GUI thread should also mean that VK_PROCESSKEY will never have to be handled, so the logic for that can be removed as well.
* vo_opengl: wayland: use a more standard symbolwm42015-10-231-1/+2
| | | | | They're the same, but EGL_CONTEXT_MAJOR_VERSION_KHR technically is an extension, while EGL_CONTEXT_CLIENT_VERSION is the standardized alias.
* vo_opengl: vaapi: fix compilation failure on older systemswm42015-10-231-1/+2
| | | | | | | Older systems have certain EGL extension definitions missing. We redefine them to make the build system easier, and because it's trivial. But we forgot to define the EGL_LINUX_DMA_BUF_EXT identifier. (I hope it's the only missing one.)
* vo_opengl_cb: fix passing through some video equalizer propertieswm42015-10-231-2/+7
| | | | | | | | | | | | | | | | | | | | | | The equalizer code as it exists in vo_opengl works perfectly fine. The situation in vo_opengl_cb is pretty different. The playback thread can't communicate with the renderer thread synchronously (essentially to give the API user more flexibility). So the equalizer communication has to be done in an asynchronous way too. There were two problems. First, the eq capabilities can change with the pixel format, and the renderer initializes them on config only. This means equalizers were disabled on the first config run, and options like --video-output-levels or --brightness would not work. So we just initialize the caps with a known superset. The player will not correctly indicate when setting an eq doesn't work, but we're fine with it, as it is a relatively cosmetic issue. Second, it copied back the eq settings in the "wrong" moment (what for?), which overwrote the settings in some cases. Third, the eq was not reset correctly on vo init. This is needed to make it behave the same as vo_opengl.
* vo_opengl: make the default debanding settings less excessiveNiklas Haas2015-10-211-2/+2
| | | | | | | | | It's great that the new algorithm supports multiple placebo iterations and all, but it's really not necessary and hurts performance in the general case for the sake of the 0.1% that actually pause the screen and look for minute differences. Signed-off-by: wm4 <wm4@nowhere>
* Revert "vo_wayland: define opaque region"Ricardo Vieira2015-10-201-9/+0
| | | | | | This reverts commit c10fb4ce9fcd3dbbf69741eb8499c4cfabbf5412. This is already done in vo_wayland.c:resize,324 doing it here makes the window bigger before the video resizes showing a black area while dragging the border.
* vd_lavc: attempt to fallback from hwdec before anything is decodedwm42015-10-191-4/+4
| | | | | | | | | | The previous commit moved the av_frame_unref() after the got_picture check. This accidentally also deferred the software fallback reinitialization to until a software picture was decoded (instead of the exact time of the fallback), which is not ideal. Just rely on the fact that calling av_frame_unref() on a frame is ok even if nothing was decoded.
* vd_lavc: continue decoding properly after decoding failurewm42015-10-191-3/+7
| | | | | | | | | | Commit 12cd48a8 started setting the hwdec_failed field even if hwdec was not active, and because it also checked this field even if hwdec was not active, broke decoding forever. Fix this, and also avoid a memory leak or API misuse by releasing the decoded picture. Passing an unreleased frame to the decoder has as far as I know no defined effects.
* vo_opengl: support all kinds of GBRP formatswm42015-10-183-13/+15
| | | | | | | | Adds support for AV_PIX_FMT_GBRP9, AV_PIX_FMT_GBRP10, AV_PIX_FMT_GBRP12, AV_PIX_FMT_GBRP14, AV_PIX_FMT_GBRP16, AV_PIX_FMT_GBRAP, and AV_PIX_FMT_GBRAP16. (Not that it matters, because nobody uses these anyway.)
* vaapi: drop non-existing FourCCwm42015-10-172-5/+0
| | | | | | | This VA_FOURCC isn't even defined by latest drivers, so I'm just assuming it doesn't exist and never existed. For planar 4:2:0, VA_FOURCC_YV12 is normally preferred, and there's even a VA_FOURCC_IYUV for 4:2:0 with unswapped planes.
* build: bump required libva versionwm42015-10-171-6/+0
| | | | | | | | 0.34 and 0.35 don't have the buffer API, such as vaAcquireBufferHandle. This is only needed for the EGL interop, but why bother staying compatible for such old things (0.36 was released over a year ago). We also can drop some minor compatibility ifdeffery.
* vo_opengl_cb: fix pausing and seeking if interpolation is enabledwm42015-10-141-1/+20
| | | | | | | | | | | | | | | When seeking, the current frame will have the wrong timestamp, until the seek is done and a new frame from the seek target is shown. We still use the "old" frame for redrawing during seeks. This frame has to be explicitly marked with still=true in order not to confuse the interpolation queue. If this is not done, it will ignore frames until a frame with approximately the same timestamp as the "old" frame is reached. (Does this mean interpolation handles timestamp resets incorrectly? I have no idea.) Of course we also have to clear possibly queued frames on seeks. Also, in pausing, explicitly let the frame redraw.
* vo_opengl: x11egl: fix confused error status codeswm42015-10-121-2/+2
| | | | This is all kinds of wonderfully stupid.
* vo_opengl: x11egl: reject nvidia drivers when autoprobingwm42015-10-121-0/+6
| | | | | | | | | Newer nVidia drivers support EGL, but they seem to work badly, apparently don't support some needed features or not in a form we want (such as swap control), and vdpau interop is not available. Disable it by default, because I'm tired of explaining this issue. Can be reverted as soon as nVidia release working drivers.
* vd_lavc: work around libavcodec nonsense causing hwdec init failurewm42015-10-121-0/+3
| | | | | | | | | | | | | | | | The libavcodec h264 decoder contains some idiotic code with unknown purpose (no sample or explanation known that necessitates its existence), that causes the AVCodecContext.get_format callback to be invoked at a time when hwaccels can't be initialized. By definition, the get_format callback is supposed to initialize hwaccels (another idiotic thing now part of the API, but different story). This causes hwdec initialization sometimes to fail (WolfensteinTwitch.mp4): the first get_format callback will mark it as failed, so the second get_format (the "proper" normal one) will not bother restoring the state, and hwdec init fails. While this should be fixed in libavcodec (good luck with that), it's quite easy to workaround.
* vd_lavc: refuse to initialize vaapi with unknown profileswm42015-10-111-3/+1
| | | | | | Bad idea, although I'm not sure how harmful it actually was. Although this is common code, only the vaapi hwaccel still uses it.
* cocoa: set application policy before creating windowwm42015-10-111-5/+4
| | | | | | | | | | | | This fixes a regression since commit f4d62da8. The original code run vo_cocoa_config_window() once without creating the window, which had the effect that the last part of the function was run at least once before the actual window was created. Fix the regression by moving it to before the window is created. The regression itself is hard to describe. One test case: start mpv from a fullscreened terminal window. It should switch to another desktop, with the mpv window visible. This didn't happen anymore.
* vo: log deviation from ideal vsync intervalwm42015-10-081-0/+5
|
* vo_xv: fix crash with --widwm42015-10-071-1/+1
| | | | | | Fixes #2386. Reminder that you should not use this crap-VO.
* video: fix base for --no-correct-ptswm42015-10-062-9/+10
| | | | | | | | | | Use the first encountered packet PTS/DTS as base, instead of the last one. This does not add the amount of frames buffered in the codec to the PTS offset, and thus is better. Also, don't add the frame time if there was no decoded frame yet. The first frame should obviously have the timestamp of the first packet (going by this heuristic).
* video: increase maximum number of buffered AVI pts sampleswm42015-10-061-1/+1
| | | | | | | While b-frame reordering limits the maximum required number to around 16, the number of additionally buffered frames can be much higher. Guess when this actually matters? (For the libavcodec MMAL wrapper.)
* video: don't sort AVI pts sampleswm42015-10-061-14/+10
| | | | | It's obviously not needed, and only an artifact of the old PTS determination code.
* video: remove user-controllable PTS sorting (--pts-association-mode)wm42015-10-062-57/+5
| | | | | | | | | Useless. Sometimes it might be useful to make some extremely broken files work, but on the other hand --no-correct-pts is sufficient for these cases. While we still need some of the code for AVI, the "auto" mode in particular inflated the size of the code.
* video: disable framedrop if avi-style timestamps are usedwm42015-10-061-0/+3
| | | | | | | | | | | | This can't be handled correctly at all. Other cases when the decoder might drop a frame (such as completely failing to decode a frame) will shift timestamps by a frame, and it can't be avoided. While we could maybe find a better way to handle this with libavcodec's main decoders, this seems to be much harder if it should work with certain HW decoders, which don't passthrough the DTS field (such as MMAL). Another problem are .avi files with b-frames. So just leave it as it is.
* video: remove codec delay estimationwm42015-10-033-15/+2
| | | | | | | | | | This was used only by the timestamp sorting code, which is a fallback for avi files (as well as avi-muxed mkv files). This was supposed to prevent accumulating timestamps in case the decoder consumes more packets than it outputs frames (i.e. frames are dropped). This didn't work very well (timestamps could be off by a large amount), the estimation of the delay was fragile, and the interdependencies with the decoder were annoying, so kill it.
* video: cosmetics: remove trailing whitespacewm42015-10-031-1/+1
|
* video/out: remove an unused parameterwm42015-10-0325-43/+40
| | | | | | | | | | | This parameter has been unused for years (the last flag was removed in commit d658b115). Get rid of it. This affects the general VO API, as well as the vo_opengl backend API, so it touches a lot of files. The VOFLAGs are still used to control OpenGL context creation, so move them to the OpenGL backend code.
* vo: change some defines to enumswm42015-10-021-9/+13
| | | | Why not.
* vo_opengl: drop old backend APIwm42015-10-023-87/+26
|
* vo_opengl: rpi: switch to new internal APIwm42015-10-023-39/+35
|
* win32: cleanup: remove some unneeded thingswm42015-10-024-17/+10
|
* vo_opengl: w32: switch to new internal APIwm42015-10-024-27/+36
|
* vo_opengl: refactor DwmFlush crapwm42015-10-023-42/+45
| | | | | Get it out of the way in the common code. MPGLContext.dwm_flush_opt can be removed as well as soon as the option system gets overhauled.
* vo_opengl: remove leftover variable from vaglx in vaeglEmmanuel Gil Peyrot2015-10-021-1/+0
| | | | This was preventing compilation on systems without X11 headers.
* vo: fix compilation failure when vaapi is enabled and x11 disabledEmmanuel Gil Peyrot2015-10-021-1/+1
| | | | | This was previously trying to use the video_output_vaapi symbol despite vo_vaapi.c being guarded by the vaapi-x11 option.
* vo_opengl: wayland: switch to new internal APIwm42015-10-016-54/+44
|
* vo_opengl: cocoa: switch to new internal APIwm42015-10-016-31/+37
|
* vo_opengl: make sw suboption work without explicit backend selectionwm42015-10-013-2/+3
| | | | | | | You needed to select a GL backend with the backend suboption. This was confusing. Fixes #2361.
* vo_opengl: debanding requires GLSL 1.30wm42015-10-011-0/+4
| | | | | | We have to disable it, or shader compilation will fail. Fixes #2362.
* x11: separate window creation and configurationwm42015-09-308-36/+56
| | | | | | | | | | | | | | |