summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* vf_vdpaurb: Add a new filter for reading back vdpau decoded framesPhilip Langdale2015-07-112-0/+114
| | | | | | | | | | | | | | | | | Normally, vdpau decoded frames are passed directly to a suitable vo (vo_vdpau or vo_opengl) without ever touching system memory. This is efficient for output purposes, but prevents any of the regular filters from being used with such frames. This new filter implements a read-back step to pull the frames back into system memory where they can be acted on by other filters. Eventually the frames will be sent to the vo as if they were normal software-decoded frames. Note that a vdpau compatible vo must still be used to ensure that the decoder is properly initialised. Signed-off-by: wm4 <wm4@nowhere>
* video: add a way to disable automatic stereo conversionwm42015-07-101-0/+1
| | | | Fixes #2111.
* vf_stereo3d: drop internal implementationwm42015-07-101-393/+15
| | | | Leave the libavfilter wrapper only.
* gl_hwdec: change wording in verbose messagewm42015-07-101-1/+1
|
* vf_vdpaupp: don't attempt to deinterlace progressive frameswm42015-07-081-5/+9
|
* mp_image: fix vf_vdpaupp referenceswm42015-07-081-2/+0
| | | | | | | | | | Some code called by vf_vdpaupp.c calls mp_image_new_custom_ref(), but out of convenience doesn't reset the buffers. Make this behavior ok. (The assert() was there to catch usage errors, but the same error could already happen before the refcount changes were made, so the check is not overly helpful.) Fixes #2115.
* vaapi: drop compatibility crap and vo_vaapi deinterlacerwm42015-07-084-96/+15
| | | | | | | | | | | 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.
* vf_vavpp: don't attempt to deinterlace progressive frameswm42015-07-081-0/+7
|
* vaapi: increase number of additional surfaceswm42015-07-081-6/+2
| | | | | | | | | | | | | | | | | | | Sometime recently, hardware decoding started to fail if h264 with full reference frames was decoded, and --vo=vaapi was used. VAAPI requires registering all surfaces that the decoder will ever use in advance, so if the playback chain uses more surfaces than originally allocated, we fail and drop back to software decoding. I'm not really sure why or when this started happening. Commit 7b9d7265 for one is not the cause - it can be reproduced with earlier commits. It also seems to be timing dependent. Possibly it has to do with the way vo.c retains previous surfaces, and the way they can be queued/unqueued asynchronously. Increasing the number of reserved additional surfaces by 1 fixes it. (Though I have no idea where exactly all these surfaces are being used. Or rather, _when_.)
* vf_yadif: expose interlaced frame modewm42015-07-071-9/+5
| | | | | Also remove the enabled suboption, which did nothing. (It was probably broken at some point.)
* 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.
* options: cleanup hwdec name mappingswm42015-07-071-1/+6
| | | | | | | | | Now there's a "canonical" table for mapping the names, that other code can use, without having to rely too much on option code magic. Also, use the central HWDEC constants, instead of magic values. (There used to be semi-ok reasons to do this, but now it makes no sense anymore.)
* 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.
* dxva2: fix handling of cropped videowm42015-07-061-1/+5
| | | | | | Basically, we need to make sure to allocate enough data for the pretty dumb copy_nv12 function. (It could be avoided by making the function less dumb, but this fix is simpler.)
* video: replace our own refcounting with libavutil'swm42015-07-054-150/+123
| | | | | | | | | | | | | | | | | | | | | | mpv had refcounted frames before libav*, so we were not using libavutil's facilities. Change this and drop our own code. Since AVFrames are not actually refcounted, and only the image data they reference, the semantics change a bit. This affects mainly mp_image_pool, which was operating on whole images instead of buffers. While we could work on AVBufferRefs instead (and use AVBufferPool), this doesn't work for use with hardware decoding, which doesn't map cleanly to FFmpeg's reference counting. But it worked out. One weird consequence is that we still need our custom image data allocation function (for normal image data), because AVFrame's uses multiple buffers. There also seems to be a timing-dependent problem with vaapi (the pool appears to be "leaking" surfaces). I don't know if this is a new problem, or whether the code changes just happened to cause it more often. Raising the number of reserved surfaces seemed to fix it, but since it appears to be timing dependent, and I couldn't find anything wrong with the code, I'm just going to assume it's not a new bug.
* mp_image: make image writeable before overwriting palettewm42015-07-051-2/+4
| | | | This is an obscure but theoretically possible bug.
* 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-035-0/+80
| | | | | | | | | 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-034-0/+42
| | | | | Since we still read-back (and don't have hard plans on changing this), this doesn't have much of an advantage.
* dxva2: move device creation codewm42015-07-031-34/+50
| | | | Preparation for the following commit.
* 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.
* 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 every