summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* vaapi: prefer direct display over copy-backwm42015-06-291-1/+1
| | | | | | Again. With the old OpenGL interop dropped, this probably works better than vaapi-copy now. Last time we defaulted to vaapi-copy, because the OpenGL interop could swap U/V planes and other stupid crap. We'll see.
* vaapi: treat cropped decoder output slightly more correctlywm42015-06-291-2/+13
| | | | | | | | | | | | Work around that FFmpeg doesn't distinguish between surface and cropped size. The decoder always aligns the surface size to something "convenient" (e.g. 16 for h264), and to get to the correct cropped size, the output image's width/height is reduced. Using the cropped size instead of the real surface size breaks the libva API in certain cases, so we simply store and use the original size in our per-surface struct. (If data is cropped on the left/top borders, hw decoding will simply display these - FFmpeg doesn't let us do better.)
* vaapi: fix potential NULL deref on memory allocation failurewm42015-06-291-2/+3
|
* vaapi: remove vaDeriveImage() code pathwm42015-06-291-40/+17
| | | | | | | In theory, this code path avoids a copy. In practice, it never seems to get enabled at all. But it does have potential for weird bugs or performance issues (like being mapped from non-cacheable memory), so kill it.
* 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?
* demux: merge extradata fieldswm42015-06-211-1/+1
| | | | | | | MPlayer traditionally had completely separate sh_ structs for audio/video/subs, without a good way to share fields. This meant that fields shared across all these headers had to be duplicated. This commit deduplicates essentially the last remaining duplicated fields.
* demux: rename sh_stream.format to sh_stream.codec_tagwm42015-06-211-4/+4
| | | | | Why not. "format" sounds too misleading for the actual importance and meaning of this field.
* video: reduce error message when loading hwdec backend failswm42015-06-2011-19/+28
| | | | | | | | | | | | | | | | | 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>
* player: make decoding cover art more robustwm42015-06-182-0/+3
| | | | | | | | | | | | | | When showing cover art, the decoding logic pretends that the source has an infinite number of frames. This slightly simplifies dealing with filter data flow. It was done by feeding the same packet repeatedly to the decoder (each decode run produces new output). Change this by decoding once at the video initialization. This is easier to follow, and increases robustness in case of broken images. Usually, we try to tolerate decoding errors, so decoding normally continues, but in this case it would just burn the CPU for no reason. Fixes #2056.
* 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.
* vaapi: add missing license headerwm42015-06-081-0/+17
| | | | | | Absence of license header implies LGPL, as mentioned in the "Copyright" file. But vaapi.h contains some code taken from the mplayer-vaapi patch, which was under the typical MPlayer license.
* 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-052-6/+12
| | | | | | | 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?
* vf_sub: minor simplificationwm42015-06-052-5/+2
|
* 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-042-0/+21
| | | | | | | | | 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.
* vf_vavpp: provide future/past frames to driverwm42015-06-011-30/+97
| | | | | | | | | | | | | This was missing for extended deinterlacer. Unfortunately, these deinterlacer still do not work. The provided future frame (which is all the deinterlacers want) seems to be correct, though. One minor behavioral change is that this always keeps the previous frame for PTS computations. This could be avoided (in order to keep exactly the same behavior as before), but it seems more elegant and should not do any harm. (Also, if we really cared about reducing hw frame refs, a more worthy goal is producing the field output incrementally.)
* vf_vavpp: move vaMapBuffer() closer to its usewm42015-06-011-4/+4
| | | | | | | | The mapped data (pointed to by the param variable) is not needed before, so the call can be moved down. Also, this prevents that the buffer remains mapped forever if the other vaMapBuffer() call above fails (the cleanup code forgets to unmap the buffer - this commit makes it unnecessary).
* vf_vavpp: remove dummy loop, unindentwm42015-06-011-51/+61
| | | | | | | This used a do-while loop, which runs only once, as replacement for a cleanup goto. While this is ok, doing a goto directly is easier to follow and is closer to idiomatic C. But mainly remove it so that the indentation can be reduced.
* vf_vavpp: cosmeticswm42015-06-011-10/+10
| | | | Adjust coding style. Get rid of some useless consts too.
* vf_vavpp: minor simplificationwm42015-06-011-29/+24
| | | | Slightly easier to follow.
* 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.
* vf_vavpp: fix bob deinterlacing for bottom field first videosFilip Milivojevic2015-05-301-0/+2
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vf_vavpp: do not pretend to support referenceswm42015-05-291-3/+5
| | | | | | | | | | | | | | | We do not fill them, so we would pass random IDs to the driver. The code was originally written to handle bob deinterlacing only, so I guess it originally passed always 0 anyway, despite having code for reference surface list allocation. Also, move down the vaUnmapBuffer() call. This call actually "unmaps" the param pointer, so accessing it after the unmap call would be undefined behavior. The "example" in <va/vavpp.h> does this too, but it's most likely an error. (Additionally, not even bob deinterlacing worked correctly in my test, sigh.)
* vf_vavpp: simplify surface list allocationwm42015-05-291-14/+2
|
* 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
|
* vaapi: remove direct mapping non-sensewm42015-05-291-42/+6
| | | | | | | | | | | | | | | | | | | | This must have been some non-sense in the original vaapi mplayer patch. While I still have no good idea what this "direct mapping" business is about, it appears to be pretty much pointless. Nothing can hold additional "real" surface references (due to how the API and mpv/lavc refcounting work), so removing the additional surfaces won't break anything. It still could be that this was for achieving additional buffering (not reusing surfaces as soon), but we buffer some additional data anyway. Plus, the original intention of the vaapi mplayer code was probably increasing surface count just by 1 or 2, not actually doubling it, and/or it was a "trick" to get to the maximum count of 21 when h264 is in use. gstreamer-vaapi uses "ref_frames + SCRATCH_SURFACES_COUNT" here, with SCRATCH_SURFACES_COUNT defined to 4. It doesn't appear to check the overlay attributes at all in the decoder. In any case, remove this non-sense.
* vd_lavc: fix a hw decoding fallback casewm42015-05-291-1/+6
| | | | | | | On hw decoder reinit failure we did not actually always return a sw format, because the first format (fmt[0]) is not always a sw format. This broke some cases of fallback. We must go through the trouble to determine the first actual sw format.
* vdpau: do not attempt to allocate surfaces while preemptedwm42015-05-291-10/+17
| | | | | | | | This reduces spam while preempted a bit. The remaining message, "hardware accelerator failed to decode picture" on every frame, can not be prevented because it's hardcoded in libavcodec.
* 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: add support for the "new" libavcodec vdpau APIwm42015-05-283-1/+120
| | | | | | | | | Yet another of these dozens of hwaccel changes. This time, libavcodec provides utility functions, which initialize the vdpau decoder and m