summaryrefslogtreecommitdiffstats
path: root/video/out
Commit message (Collapse)AuthorAgeFilesLines
* vo_opengl: minor cleanup to hwdec texture setting codewm42015-07-261-14/+9
| | | | | | Instead of special-casing hwdec in the place where the video textures are used, just set the textures in the image upload function. The renderer code doesn't need to know whether hwdec interop is used at all.
* vo_opengl: remove legacy GL detectionwm42015-07-241-23/+1
| | | | | | | | | | This detected whether an OpenGL context still provided legacy OpenGL if the OpenGL version is modern (>= 3.0). This was actually only needed for vo_opengl_old, because it relied on legacy functions. Since it's gone, this code isn't needed either. (Also, the removed comment about OpenGL 3.0 was wrong: you could just query GL_CONTEXT_FLAGS and see if the forward compatible bit was set.)
* vo_opengl: fix scale=oversample's threshold calculationsNiklas Haas2015-07-231-1/+1
| | | | | This resulted in wrong behavior for values of scale-param1 between 0.0 and 0.5 (not inclusive).
* Revert "vo_opengl: make the size of interpolation textures exact"wm42015-07-221-2/+2
| | | | | | | | | | This reverts commit fb8d15836695e883355c5ec6ff8463e7bbf39461. Reallocating the FBOs on every resize is very slow. It affects resizing the window, as well as changing the video size itself with e.g. panscan. Since the original change was done based on a single user complaint, but the change itself caused a lot of complaints, we decided to just revert it.
* vo: minor simplification for queue size handlingwm42015-07-204-15/+14
| | | | | | | | | | Instead of calling it "future frames" and adding or subtracting 1 from it, always call it "requested frames". This simplifies it a bit. MPContext.next_frames had 2 added to it; this was mainly to ensure a minimum size of 2. Drop it and assume VO_MAX_REQ_FRAMES is at least 2; together with the other changes, this can be the exact size of the array.
* vo_opengl: add temporal-dither-period optionNiklas Haas2015-07-202-1/+5
| | | | | This was requested multiple times by users, and it's not hard to implement and/or maintain.
* vo_opengl: make oversample the default for opengl-hq as wellNiklas Haas2015-07-201-1/+1
| | | | | This was supposed to have changed back when oversample was reintroduced in 3007250. Fixes #2155.
* vo_opengl: make the size of interpolation textures exactNiklas Haas2015-07-181-2/+2
| | | | | | | | | | | | I still have no idea why this is needed, maybe some weird off-by-one in some shitty driver? Either way, the difference for a working setup shouldn't be too major, the most noticeable effect would be somewhat worse performance when resizing the video during playback with interpolation enabled using the mouse. That's a specific enough side effect for me to not care as much about it. Fixes #1814.
* vo_opengl: cleanup frame reupload logicwm42015-07-171-8/+9
| | | | | | | | There are some situations when redrawing is requested, but the current frame was deleted. This could happen when switching e.g. hw decoding mid-stream. Separate uploading/drawing and fix the condition.
* vo_opengl: refactor queue configurationwm42015-07-164-23/+29
| | | | | | | Just avoid some code duplication. Also, gl_video_set_options() having a queue size output parameter is weird at best. While I don't appreciate that this commit suddenly requires gl_video.c to deal with vo.c directly in a special case, it's simply the best place to put this function.
* vo: fix number of future frameswm42015-07-162-2/+2
| | | | | | That was 2 too many. Also fix a documentation comment.
* vo_opengl: reject future images in different formatswm42015-07-151-1/+2
| | | | | | | | | | | | | The VO will be provided with future frames even if the format changes mid-stream. This caused a crash if these frames were actually used (i.e. interpolation mode was enabled). Fixes a crash when deinterlacing is toggled during playback, and the deinterlacer changes the stream format (as it can happen e.g. if the decoder outputs nv12, which in turn happens with hw decoding). (On a side note, future frames are always non-NULL. Also, the current frame is of course always in the correct format.)
* vo_vaapi: drop unused fieldwm42015-07-151-2/+0
|
* vo_opengl: simplifywm42015-07-151-26/+11
| | | | | After recent changes, there is no reason why gl_video_set_image() should exist anymore. So merge it back into gl_video_upload_image().
* vo_opengl: reduce verbose outputwm42015-07-111-26/+2
| | | | | | | | | Outputting the detected OpenGL features was useless and redundant with the extension loading output. Also, remove MPGL_CAP_3D_TEX from OpenGL(ES) 3.0. This block didn't include the glTexImage3D function, so that was pointless and couldn't have worked. The OpenGL 2.1 block does it correctly.
* vo_vdpau: Implement rotation supportPhilip Langdale2015-07-111-8/+84
| | | | | | | | | | | | | | | | | | | | VDPAU has explicit support for rotating surfaces, and it is far less expensive than using the normal rotation filter (which would require reading video frames back into system memory), it is desirable to implement the VO rotation capability. To do this, we need to render the video frames to an output surface, without rotation, and then render from that surface to the final output surface to apply the rotation. It is important that the intermediate surface is the same size as the final one (only not rotated) so that hqscaling can be applied if requested by the user. (hqscaling is a mixer capability and so takes effect when the video surface is rendered to an output surface) Finally, we must remember to explicitly clear the final output surface as VDPAU only auto-clears output surfaces when rendering video surfaces.
* vo_opengl: reimplement tscale=oversampleNiklas Haas2015-07-111-9/+32
| | | | Closes #2102.
* gl_hwdec: change wording in verbose messagewm42015-07-101-1/+1
|
* vaapi: drop compatibility crap and vo_vaapi deinterlacerwm42015-07-081-37/+9
| | | | | | | | | | | Drop libva versions below 0.34.0. These are ancient, so I don't care. Drop the vo_vaapi deinterlacer as well. With 0.34.0, VPP is always available, and deinterlacing is done with vf_vavpp. The vaCreateSurfaces() function changes its signature - actually it did in 0.34.0 or so, and the <va/va_compat.h> defined a macro to make it use the old signature.
* vo_opengl_cb, vo_opengl: add option for preloading hwdec contextwm42015-07-074-14/+21
| | | | | | | | See manpage additions. This is mainly useful for vo_opengl_cb, but can also be applied to vo_opengl. On a side note, gl_hwdec_load_api() should stop using a name string, and instead always use the IDs. This should be cleaned up another time.
* vo_opengl_cb: drop frames eagerly if frames are not renderedwm42015-07-071-1/+7
| | | | | libmpv users might stop calling the frame render callback for stupid reasons, at which point video frames would pile up.
* vo: free frames before killing VOwm42015-07-041-1/+1
| | | | | | This caused issues with hardware decoding. The VOs by definition dictate the lifetime of the hardware context, so no surface allocations must survive the VO. Fixes assertions on exit with vdpau.
* vo: set correct frame parameters on redrawwm42015-07-031-2/+2
|
* client API, dxva2: add a workaround for OpenGL fullscreen issueswm42015-07-034-0/+79
| | | | | | | | | This is basically a hack for drivers which prevent the mpv DXVA2 decoder glue from working if OpenGL is in fullscreen mode. Since it doesn't add any "hard" new API to the client API, some of the code would be required for a true zero-copy hw decoding pipeline, and sine it isn't too much code after all, this is probably acceptable.
* vo_direct3d, dxva2: use the same D3D devicewm42015-07-031-0/+18
| | | | | Since we still read-back (and don't have hard plans on changing this), this doesn't have much of an advantage.
* vo_opengl: log some more stuff in verbose modewm42015-07-032-1/+4
|
* vo_opengl: fix "freezes" after seeking with interpolation onwm42015-07-021-1/+5
| | | | | | | | | | | | | | | | | | | | When seeking to a different position, and seeking takes long, the OSD might get redrawn. This means that the VO will receive a request to redraw an old frame using whatever the previous PTS was. This breaks the interpolation logic: the old frame will be added to the queue, and then the next frames (with lower PTS if you seeked backwards) are not drawn as the logic assumes they're past frames. Fix this by using the non-interpolation code path when redrawing after a seek reset, and no "real" frame has been drawn yet. It's a recent regression caused by the redrawing code simplification. The old code simply sent a VOCTRL for redrawing the frame, and the VO had to deal with retaining the old frame on its own. This is a hack as in there's probably a better solution. Fixes #2097.
* vo: reset frame timing when redrawingwm42015-07-021-0/+2
| | | | bother vo_vdpau.c, which actually uses these times.
* vo_opengl: X11: don't leak when GL init failswm42015-07-021-1/+4
|
* vo_opengl: X11 EGL: more detailed error reportingwm42015-07-021-2/+6
|
* vo_opengl: update EGL codewm42015-07-023-20/+35
| | | | Use the newer internal GL backend API.
* vo_opengl: remove unused GL API functionswm42015-07-022-4/+0
|
* x11: move GCs and background clearing to vo_xvwm42015-07-013-48/+49
| | | | vo_xv.c is the only place where these things are used.
* x11: remove clear on mapwm42015-07-012-12/+0
| | | | | | | | Less code, and avoids a black flash on start. In theory it could happen that we map the window, and then don't have a frame to draw - but mapping the window is done in the exact moment we have a new frame to display.
* vo: better magic value for unknown vsync intervalwm42015-07-012-1/+2
| | | | | The value 1 is useful in some contexts, but not such a good choice otherwise.
* vo_opengl_cb: fix interpolation code pathwm42015-07-011-6/+2
|
* vo_opengl: fix framestepping/pausing + interpolationNiklas Haas2015-07-011-2/+8
| | | | | | | | This is not the most theoretically perfect solution, ideally we could check to see if the frame in question has already been rendered somewhere in the queue and then avoid re-rendering it, at the cost of a few extra lines of code. But I don't think the performance trade-off is dramatic enough here.
* vo: change internal API for drawing frameswm42015-07-017-259/+246
| | | | | | | | | | | | | | draw_image_timed is renamed to draw_frame. struct frame_timing is renamed to vo_frame. flip_page_timed is merged into draw_frame (the additional parameters are part of struct vo_frame). draw_frame also deprecates VOCTRL_REDRAW_FRAME, and replaces it with a method that works for both VOs which can cache the current frame, and VOs which need to redraw it anyway. This is preparation to making the interpolation and (work in progress) display sync code saner. Lots of other refactoring, and also some simplifications.
* vo_opengl: adjust interpolation code for the new video-sync mechanismNiklas Haas2015-07-014-110/+113
| | | | | | | | | | | | | This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
* video: pass vsync offset to VOwm42015-07-012-0/+3
| | | | | | | For now, this is trivial (and actually redundant). The future display sync code will make better use of it. The main point is that the new internal API pretty much makes this transparent to the vo_opengl interpolation code.
* video: pass future frames to VOwm42015-07-015-10/+80
| | | | | | | | | | Now the VO can request a number of future frames with the last parameter of vo_set_queue_params(). This will be helpful to fix the interpolation code. Note that the first frame (after playback start or seeking) will usually not have any future frames (to make seeking fast). Near the end of the file, the number of future frames will become lower as well.
* video: fix panscan in vertical casewm42015-06-291-3/+8
| | | | | If the black bars appeared on the left/right borders, panscan=1 didn't make the video cover the whole screen.
* x11: remove trailing spaceswm42015-06-291-1/+1
|
* x11: Handle external fullscreen togglesEduardo Sánchez Muñoz2015-06-281-0/+43
| | | | | | | | | | | | | | | Some window managers let you change the fullscreen state of any window using a key combination. For example, on XFWM you can use Alt+F11 and on Compiz you can configure a key combination with the "Extra WM actions" plugin. With this change mpv will handle these fullscreen state changes. So, if you enter into fullscreen mode using the WM's shortcut and then you use mpv's fullscreen toggle, you will get back into window mode. Merges PR #2081. Signed-off-by: wm4 <wm4@nowhere>
* vo_drm: make VT switching non mandatoryrr-2015-06-281-11/+20
|
* vo_drm: fix missing newlines in error messagesrr-2015-06-281-4/+4
|
* vo_x11: remove this video outputwm42015-06-262-637/+0
| | | | | | | It only causes additional maintenance work. Even if you wanted to have a fallback, it's probably better to use --vo=sdl or so.
* vo_sdl: fix glaring memory leakwm42015-06-251-0/+2
| | | | Who knows when this broke?
* video: reduce error message when loading hwdec backend failswm42015-06-205-5/+5
| | | | | | | | | | | | | | | | | When using --hwdec=auto, about half of all systems will print: "[vdpau] Error when calling vdp_device_create_x11: 1" this happens because usually mpv will be linked against both vdpau and vaapi libs, but the drivers are not necessarily available. Then trying to load a driver will fail. This is a normal part of probing, but the error messages were printed anyway. Silence them by explicitly distinguishing probing. This pretty much goes through all the layers. We actually consider loading hw backends for vo_opengl always "auto probed", even if a hw backend is explicitly requested. In this case vd_lavc will print a warning message anyway (adjust this message a bit).
* x11: make screensaver failure message slightly more friendlywm42015-06-201-2/+4
|
* win32: remove a wine hackwm42015-06-201-8/+1
| | | | | | | No particular reason, but it's still possible that it causes additional corner cases, and it's not really needed to test this on wine (other than testing fullscreen stuff, which should be done on a real Windows anyway).
* win32: prefer using internal variable for fullscreenwm42015-06-201-11/+12
| | | | | | No particular reason, but since we already have an internal variable, it's better than using the option struct, which will be redone sooner or later.
* 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