summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vo_rpi: set aspect ratiowm42015-11-251-5/+8
| | | | | Otherwise, the MMAL output component will letter-box the video within the specified dest_rect while keeping square pixels.
* vo_rpi: log subtitle render timewm42015-11-251-0/+4
|
* vo_rpi: add an option to disable OSDwm42015-11-251-19/+25
| | | | | | The OSD takes up an entire fullscreen dispmanx layer. Although the GPU should be able to handle it (possibly even without any disadvantages), it'll still be useful for debugging performance issues.
* vo_opengl: win32: test for exclusive modeJames Ross-Gowan2015-11-263-0/+129
| | | | | | | | | | This is a hack, but unfortunately the DwmGetCompositionTimingInfo heuristic does not work in all cases (with multiple-monitors on Windows 8.1 and even with a single monitor in Windows 10.) See the comment in mp_w32_is_in_exclusive_mode() for more details. It should go without saying that if any better method of doing this reveals itself, this hack should be dropped.
* vo_opengl: angle: don't load libGLESv2.dllJames Ross-Gowan2015-11-261-17/+1
| | | | | ANGLE has EGL_KHR_get_all_proc_addresses, so all GLES core functions can be queried with eglGetProcAddress.
* vo: remove VOCTRL_GET_RECENT_FLIP_TIMEwm42015-11-234-19/+1
| | | | | | | | | | | It doesn't have any real purpose anymore. Up until now, it was still implemented by vo_wayland, but since we changed how the frame callbacks work, even that appears to be pointless. Originally, the plan was to somehow extend this mechanism to all backends and to magically fix frame scheduling, but since we can't hope for proper mechanisms even on wayland, this idea looks way less interesting.
* dxva2: reject 10 bit HEVCwm42015-11-231-0/+4
| | | | | | | | | 10 bit HEVC would require DXVA2_ModeHEVC_VLD_Main10, and most a different surface type (judging by lavfsplitter source code, both P010 and P016 would work). Since I'm unable to test this stuff, exclude 10 bit for now. See #2516.
* win32: don't show progress indicator in idle modeJames Ross-Gowan2015-11-232-5/+13
|
* vo_opengl: fix superxbr on GLESwm42015-11-211-6/+6
| | | | Well, not that anyone does or should care.
* vo_opengl: angle: allow using D3D9 backendwm42015-11-211-22/+31
| | | | | | | | | | | | | | The D3D9 backend does not support GLES 3, which makes it pretty useless. But it still might be a legitimate replacement of vo_direct3d.c on Windows 7 machines. Note that we could just use: eglGetDisplay(EGL_D3D11_ELSE_D3D9_DISPLAY_ANGLE) But for now I'll leave the old code. Maybe this can exclude use of software rendering backends (EGL_PLATFORM_ANGLE_DEVICE_TYPE_WARP_ANGLE). Since I'm not sure, I won't touch it.
* vo_opengl: use ANGLE by default if available (except for "hq" preset)wm42015-11-213-11/+15
| | | | | | | | | Running mpv with default config will now pick up ANGLE by default. Since some think ANGLE is still not good enough for hq features, extend the "es" option to reject GLES backends, and add to to the opengl-hq preset. One consequence is that mpv will by default use libswscale to convert 10 bit video to 8 bit, before it reaches the VO.
* vo_opengl: enable dumb-mode automatically if possiblewm42015-11-191-6/+44
| | | | | | | | | | | | | | | I decided that I actually can't stand how vo_opengl unnecessarily puts the video through 3 shader stages (instead of 1). Thus, what was meant to be a fallback for weak OpenGL implementations, the dumb-mode, now becomes default if the user settings allow it. The code required to check for the settings isn't so wild, so I guess it's manageable. I still hope that one day, our rendering logic can generate ideal shader stages for this case too. Note that in theory, dumb-mode could be reenabled at runtime due to a color management 3D LUT being set, so a separate dumb_mode field is required. The dumb-mode option can't just be overwritten.
* vo_opengl: support 3D textures on ANGLEwm42015-11-192-3/+13
| | | | | | | Unfortunately, color management can still not work, because no GLES version specified so far support fixed-point 16 bit textures. Maybe we could use integer textures, but these don't support filtering. Using float textures would be another possibility.
* vo_opengl: switch FBO format on GLESwm42015-11-191-5/+11
| | | | | GL_RGB10_A2 is the best fixed-point format we can get on GLES/ANGLE for now. (Unless we somehow switch to non-normalized integer textures.)
* vo_opengl: make 1D textures completely optionalwm42015-11-192-5/+6
| | | | | | | | Polar scalers use 1D textures, because they're slightly faster on some GPUs than 2D textures. But 2D textures work too, so add support for them. Allows using these scalers with ANGLE.
* vo_opengl: fix some more GLES shader issueswm42015-11-191-6/+6
| | | | | | Just like commit f9a2fc59. There are probably some more such cases. The vec2 constructor calls are probably fine, but don't bother with confusing inconsistencies.
* vo_opengl: create FBOs in a more GLES conformant waywm42015-11-191-2/+40
| | | | | | | | | | | | | | | While desktop GL's glTexImage2D() essentially accepts anything, GLES is much stricter. The combination of allowed formats/types/internal formats is exactly specified. The GLES 3.0.4 specification lists them in table 3.2. (The ANGLE API validation code references this table.) The table could probably be extended into a general declarative table about GL formats covering other uses, but this would be a big non-trivial project, so don't bother and accept a minor degree of duplication with other tables. Note that the format and type do (or should) not matter here, because no image data is transferred to the GPU.
* vo_opengl: better check for float texture supportwm42015-11-191-7/+8
| | | | | | We don't only need float textures for advanced scaling - we also need them to be filterable with GL_LINEAR. On GLES, this is not supported until GLES 3.1, but some implementation expose them with extensions.
* vo_opengl: check shader string before sscanfing itKevin Mitchell2015-11-191-1/+1
|
* vo_opengl: add missing log newlineKevin Mitchell2015-11-191-1/+1
|
* vo_opengl: add RGBA8 framebuffer format, enable non-dumb mode for ES 3.0wm42015-11-191-1/+2
| | | | | | | This makes advanced scaling sort-of work for GLES 3.0 (on ANGLE). It's still not very advisable, as 8 bits might not be enough to avoid debanding. (Ironically, the debanding filter can be enabled, and does not raise any GL errors - but probably doesn't do anything useful.)
* vo_opengl: don't mix floats and integers in dither shaderwm42015-11-191-3/+3
| | | | | Some GLSL dialects (GLSL ES 3.00) do not have such implicit conversions. They have to be made floats for the sake of the shader compiler.
* vo_opengl: fix ANGLE GLES3 modeJames Ross-Gowan2015-11-192-2/+9
| | | | | | Turns out glGetTexLevelParameter, which is missing in ANGLE, is a GLES3.1 function. Removing it from the list of core GLES3 functions makes ANGLE work in GLES3 mode.
* x11: request bypassing compositorwm42015-11-181-0/+6
| | | | | | | Maybe this is a good idea. Also add an option to disable it again, for the sake of testing. Fixes #2502.
* vo_opengl: add initial ANGLE supportJames Ross-Gowan2015-11-182-0/+219
| | | | | | | | | | | ANGLE is a GLES2 implementation for Windows that uses Direct3D 11 for rendering, enabling vo_opengl to work on systems with poor OpenGL drivers and bypassing some of the problems with native GL, such as VSync in fullscreen mode. Unfortunately, using GLES2 means that most of vo_opengl's advanced features will not work, however ANGLE is under rapid development and GLES3 support is supposed to be coming soon.
* videotoolbox: make decoder format customizablewm42015-11-176-13/+41
| | | | | | | | | | Because apparently there's no ideal universally working format. The weird OpenGL texture format for kCVPixelFormatType_32BGRA is from: http://stackoverflow.com/questions/22077544/draw-an-iosurface-to-an-opengl-context (Which apparently got it from the linked Apple example code.)
* vo_opengl: osx: error out if there is no IOSurfacewm42015-11-171-0/+4
|
* vo_opengl: force dumb mode if RG textures are not availablewm42015-11-161-3/+3
| | | | | | | Something goes wrong somewhere. Don't bother, it's only needed for compatibility with our absolute baseline (GL 2.1/GLES 2). On the other hand, we can process nv12 formats just fine.
* vo_opengl: attempt to improve GLX vs. EGL backend detectionwm42015-11-163-37/+57
| | | | | | | | | | | | | | | For the sake of vaapi interop, we want to use EGL, but on the other hand, but because driver developers are full of shit, vdpau interop will not work on EGL (even if the driver supports EGL). The latter happens with both nvidia and AMD Mesa drivers. Additionally, EGL vaapi interop support can apparently only detected at runtime by actually using it. While hwdec_vaegl.c already does this, it would require initializing libva on _every_ system, which will cause libav to print an unpreventable bullshit message to the terminal. Try to counter these huge loads of bullshit by adding more fucking bullshit.
* vo_opengl: fix backend autoprobingwm42015-11-161-0/+9
| | | | | | | | | | | | | We want the following behavior: - VO probed, backend probed: only accept non-sw, fail completely otherwise - VO forced, backend probed: use the first non-sw, or if none is found, fall back to the first working sw backend - VO probed, backend forced: (I don't care about this case) - VO forced, backend forced: just use that backend Also, on backend probe failure the vo->probed field was left in its old state.
* win32: support taskbar button progress indicatorMartin Herkt2015-11-152-0/+44
| | | | | | | | | | | This adds support for the progress indicator taskbar extension that was introduced with Windows 7 and Windows Server 2008 R2. I don’t like this solution because it keeps its own state and introduces another VOCTRL, but I couldn’t come up with anything less messy. closes #2399
* vo_opengl: use glBlitFramebuffer to draw repeated frameswm42015-11-153-16/+27
| | | | | | | | | | | | | | | | | | | | | In the display-sync, non-interpolation case, and if the display refresh rate is higher than the video framerate, we duplicate display frames by rendering exactly the same screen again. The redrawing is cached with a FBO to speed up the repeat. Use glBlitFramebuffer() instead of another shader pass. It should be faster. For some reason, post-process was run again on each display refresh. Stop doing this, which should also be slightly faster. The only disadvantage is that temporal dithering will be run only once per video frame, but I can live with this. One aspect is messy: clearing the background is done at the start on the target framebuffer, so to avoid clearing twice and duplicating the code, only copy the part of the framebuffer that contains the rendered video. (Which also gets slightly messy - needs to compensate for coordinate system flipping.)
* vo: fix unpausing with display-syncwm42015-11-151-5/+3
| | | | | | | Currently, vo.c will always continue to render the currently queued frame, which sets last_flip, which in turn confuses vo_get_delay(), which in turn will show a bogus A/V desync message on unpause. So just reset it again on unpause.
* vo: fix dropping frames with display-syncwm42015-11-141-2/+0
| | | | | | I guess the removed code is an old leftover, and makes no sense anymore. Should fix weird A/V diff dropouts when frames are being dropped with display-sync.
* player: account for minor VO underrunswm42015-11-142-10/+16
| | | | | | | | | If the player sends a frame with duration==0 to the VO, it can trivially underrun. Don't panic, but keep the correct time. Also, returning the absolute time from vo_get_next_frame_start_time() just to turn it into a float with relative time was silly. Rename it and make it return what the caller needs.
* command: rename vo-missed-frame-count propertywm42015-11-132-5/+5
| | | | | | | | | "Missed" implies the frame was dropped, but what really happens is that the following frame will be shown later than intended (due to the current frame skipping a vsync). (As of this commit, this property is still inactive and always returns 0. See git blame for details.)
* win32: avoid detection as exclusive fullscreen windowMartin Herkt2015-11-131-1/+1
| | | | | | | | | | | | | | | | | Apparently Windows treats windows that use OpenGL, cover an entire screen and have the WS_POPUP style set or are topmost windows as exclusive fullscreen windows that bypass DWM and cannot be covered by other windows. This means we can’t use dwmflush in fullscreen mode, and it also means that no other window can cover mpv, and it makes the screen flicker when switching to fullscreen mode. This can be avoided by not setting the WS_POPUP flag. Users can still access the old behavior by enabling stay-on-top (which IMO at least makes sense—now we just need to get dwmflush autodetection right to avoid nasty surprises). fixes #2177
* vo_opengl_cb: do not block on flipping when redrawingwm42015-11-121-0/+5
| | | | | Gives slightly better behavior when used with Qt. (Which tends not to flip buffers when the window is not visible.)
* drm: fix setting up connectorsrr-2015-11-111-1/+1
| | | | Fixes regression from 67caea357c23443cf583ad401a38bbaae19e3df8.
* vd_lavc: be more careful with flushing the decoderwm42015-11-102-5/+22
| | | | | | | | | | | | | | | | | Until now, we've relied on the following things: - you can send flush packets to the decoder even if it's fully flushed, - you can send new packets to a flushed decoder, - you can send new packers to a partially flushed decoder. ("flushing" refers to sending flush packets to the decoder until the decoder does not return new pictures, not avcodec_flush_buffers().) All of these are questionable. The libavcodec API probably doesn't guarantee that these work well or at all, even though most decoders have no issue with these. But especially with hardware decoding wrappers (like MMAL), real problems can be expected. Isolate us from these corner cases by handling them explicitly.
* vo_opengl: move the glFlush() call to the rendererwm42015-11-102-5/+5
|
* vo_opengl_cb: better underflow reportingwm42015-11-101-6/+12
| | | | | | | This applies to unexpected freezes or deadlocks, not e.g. normal framedrops. The verbose messages also might remind an API user if the API usage is incorrect, such as not calling mpv_opengl_cb_draw() when a redraw request was issued.
* vo_opengl: limit GLSL to version 3.3wm42015-11-101-0/+2
| | | | | Fixes custom shaders, which define their entrypoint as sample() function.
* vo_opengl: fix 10-bit video prescalingBin Jin2015-11-095-24/+21
| | | | | | | | | | | The nnedi3 prescaler requires a normalized range to work properly, but the original implementation did the range normalization after the first step of the first pass. This could lead to severe quality degradation when debanding is not enabled for NNEDI3. Fix this issue by passing `tex_mul` into the shader code. Fixes #2464
* vo_opengl_cb: make operation more similar to normal VOswm42015-11-091-118/+54
| | | | | | | | | | | | | | | | | | | | | vo_opengl_cb is a special case, because we somehow have to render video asynchronously, all while "trusting" the API user to do it correctly. This didn't quite work, and a while ago a compromise using a timeout to prevent theoretically possible deadlocks was added. Make it even more synchronous. Basically, go all the way, and synchronize rendering between VO and user renderer thread to the full extent possible. This means the silly frame queue is dropped, and we event attempt to synchronize the GL SwapBuffer call (via mpv_opengl_cb_report_flip()). The changes introduced with commit dc33eb56 are effectively dropped. I don't even remember if they mattered. In the future, we might make all VOs fetch asynchronously from a frame queue, which would mostly remove the differences between vo_opengl and vo_opengl_cb, but this will take a while (if it will even be done).
* vo_opengl: handle GL_ARB_uniform_buffer_object with low GLSL versionswm42015-11-095-6/+19
| | | | Why is this stupid crap being so much a pain for no reason.
* vo_opengl: fix extension namewm42015-11-091-1/+1
|
* vo_opengl: simplify GLSL version detectionwm42015-11-091-10/+4
| | | | | | | | | | | Pick the correct GLSL version from the GL_SHADING_LANGUAGE_VERSION string. Might be somewhat questionable, as we expect the minor version number not to have leading 0s. Should help with cases when the reported GLSL version is much higher than the equivalent of the reported GL version. This problem was observed in combination with GL_ARB_uniform_buffer_object, which can't be used if the declared GLSL version is too low.
* vo_opengl: never load vaapi GLX interop by defaultwm42015-11-095-8/+8
| | | | | | | Causes more harm than it helps. Will eventually be removed. Also rename the "reject_emulated" field to "probing" - this is more appropriate now.
* vo_opengl: always preload hwdec interopwm42015-11-091-3/+6
| | | | | | | | | Simplifies some auto detection matters. I _still_ don't want to remove the lazy loading mechanism, because it's still slightly useful for filters using the hwdec APIs. My main motivation for not always preloading them is actually that libva prints random useless crap to the terminal with no way to prevent this.
* vo_opengl: rename "drm_egl" to "drm-egl"wm42015-11-091-1/+1
|
* vo_opengl: disable drm_egl autopickuprr-2015-11-091-0/+4
|
* win32: request MMCSS "Playback" profilewm42015-11-081-0/+10
|
* vo_drm: relicense to LGPLrr-2015-11-083-10/+15
| | | | | Also removed authorship information (as per convention seen in other files)
* vo_drm: use bool rather than integer return valuesrr-2015-11-084-78/+60
| | | | | Since the errors weren't used for anything other than simple success/fail checks, I simplified things a bit.
* vo_opengl: add DRM EGL backendrr-2015-11-082-0/+439
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Notes: - Unfortunately the only way to talk to EGL from within DRM I could find involves linking with GBM (generic buffer management for Mesa.) Because of this, I'm pretty sure it won't work with proprietary NVidia drivers, but then again, last time I checked NVidia didn't offer proper screen resolution for VT. - VT switching doesn't seem to work at all. It's worth mentioning that using vo_drm before introduction of VT switcher had an anomaly where user could switch to another VT and input text to it, while video played on top of that VT. However, that isn't the case with drm_egl: I can't switch to other VT during playback like this. This makes me think that it's either a limitation coming from my firmware or from EGL/KMS itself rather than a bug with my code. Nonetheless, I still left (untestable) VT switching code in place, in case it's useful to someone else. - The mode_id, connector_id and device_path should be configurable for power users and people who wish to watch videos on nonprimary screen. Unfortunately I didn't see anything that would allow OpenGL backends to register their own set of options. At the same time, adding them to global namespace is pointless. - A few dozens of lines could be shared with vo_drm (setting up VT switching, most of code behind page flipping). I don't have any strong opinion on this. - Sometimes I get minor visual glitches. I'm not sure if there's a race condition of some sort, unitialized variable (doubtful), or if it's buggy driver. (I'm using integrated Intel HD Graphics 4400 with Mesa) - .config and .control are very minimal. Signed-off-by: wm4 <wm4@nowhere>
* vo_drm: move initialization to drm_commonrr-2015-11-083-219/+278
| | | | | Makes KMS initialization procedures reusable so that they can be used by the upcoming DRM EGL adapter.
* vo_opengl: fix typorr-2015-11-071-1/+1
|
* vo_opengl: rename fancy-downscaling to correct-downscalingwm42015-11-072-10/+9
| | | | The old name was stupid. Very stupid.
* vo_opengl: fancy-downscaling: enable also for anamorphic clipsAvi Halachmi (:avih)2015-11-071-4/+9
|
* x11: print Xlib errors in verbose mode if Xlib messages are silencedwm42015-11-071-9/+5
| | | | Follow up to commit b984ec52.
* vo_opengl: x11: silence error messages when using legacy GL contextwm42015-11-063-2/+16
| | | | | | | | glXCreateContextAttribsARB() by design can throw some X11 errors. We ignore these, but we generally still print error messages to the terminal. This was confusing/annoying users, so silence it. The stupid part is that the Xlib error handler is global, so we have to be slightly careful here.