summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* video: fix a typo in a commentwm42017-03-231-1/+1
|
* vd_lavc: fix potential build failure with vaapiwm42017-03-231-1/+1
| | | | | | | If vaapi was found, but neither the old or new libavcodec vaapi hwaccel API, then HAVE_VAAPI_HWACCEL will be defined, but not _OLD or _NEW. The HAVE_VAAPI_HWACCEL define pretty much exists only for acrobatics with our own waf dependency checker helper code.
* vdpau: support new vdpau libavcodec decode APIwm42017-03-233-3/+73
| | | | | | | | | | | | | | | | | | | The new API works like the new vaapi API, using generic hwaccel support. One minor detail is the error message that will be printed if using non-4:2:0 surfaces (which as far as I can tell is completely broken in the nVidia drivers and thus not supported by mpv). The HEVC warning (which is completely broken in the nVidia drivers but should work with Mesa) had to be added to the generic hwaccel code. This also trashes display preemption recovery. Fuck that. It never really worked. If someone complains, I might attempt to add it back somehow. This is the 4th iteration of the libavcodec vdpau API (after the separate decoder API, the manual hwaccel API, and the automatic vdpau hwaccel API). Fortunately, further iterations will be generic, and not require much vdpau-specific changes (if any at all).
* vo_opengl: add a backend start_frame callback for context_vdpauwm42017-03-204-40/+52
| | | | | | Might be useful for other backends too. For context_vdpau, resize handling, presentation, and handling the mapping state becomes somewhat less awkward.
* vo_opengl: read framebuffer depth from actual FBO used for renderingwm42017-03-208-21/+25
| | | | | | | | | | | | In some cases, such as when using the libmpv opengl-cb API, or with certain vo_opengl backends, the main framebuffer is never accessed. Instead, rendering is done to a FBO that acts as back buffer. This meant an incorrect/broken bit depth could be used for dithering. Change it to read the framebuffer depth lazily on the first render call. Also move the main FBO field out of the GL struct to MPGLContext, because the renderer's init function does not need to access it anymore.
* vo_opengl: move some init_gl code to utility functionswm42017-03-203-50/+61
|
* vo_opengl: add a --opengl-es=force2 optionwm42017-03-203-3/+9
| | | | | | | Useful for testing. Unfortunately, the nVidia EGL driver ignores this, and returns a GLES 3.2 context anyway (which it is allowed to do). Might still be useable with ANGLE, which will really give you a GLES 2 context if you ask for it.
* vo_opengl: properly respect dither option if dumb mode is usedwm42017-03-201-1/+6
| | | | | | | When dumb mode is used (the "simple" rendering path), respect the dither options. Options should never be ignored (except in GLESv2 mode); either they should be respected in dumb mode, or they should disable dumb mode. In this case, the former applies.
* vo_opengl: context_vdpau: resize output surfaces lazilywm42017-03-191-80/+82
| | | | | | | This actually fixes the dreaded errors during resizing. It works pretty much like before, except each surface is reallocated before it's used. It implies surfaces with the old size remain in the presentation queue and will be displayed.
* vo_opengl: context_vdpau: minor fixeswm42017-03-192-20/+38
| | | | | | | | | | | | | | | | | | Don't assume 0 is an invalid object handle. vdpau with its weird API design makes all objects indexes, with 0 being a perfectly valid and common value. You need to use VDP_INVALID_HANDLE, which is not 0. Don't crash if init fails at vdpau initialization. It's because mp_vdpau_destroy(NULL) crashes. Simplify it. Destroy output surface backed FBO before output surface. Also, strictly bookkeep the map/unmap calls (and unmap surfaces before destroying the FBO/texture). I can't see a change in the weird errors when resizing the window, but I guess it's slightly more correct. Add the GL_WRITE_DISCARD_NV symbol to header_fixes.h, because we might fail compilation with headers that do not contain the vdpau extension (well, probably doesn't matter).
* vo_opengl: fix some undefined behaviorwm42017-03-181-1/+1
| | | | | | | The gl_timer_last_us() function could access samples[-1]. Fix by coercing to unsigned, so the % will put it into index [0,max). The real value returned in this corner case doesn't mean too much, I guess.
* vo_opengl: add experimental vdpauglx backendwm42017-03-182-0/+379
| | | | | | | | | | | | | | | | As the manpage says, this has no value other than adding bugs. It uses code based on context_x11.c, and basically does very stripped down context creation (no alpha support etc.). It uses vdpau for display, and maps vdpau output surfaces as FBOs to render into them. This might be good to experiment with asynchronous presentation. For now, it presents synchronously, with a 4 frame delay (which should whack off A/V sync). The forced 4 frame delay is probably also why interaction feels slower. There are some weird vdpau errors on resizing and uninit. No idea what causes them.
* vo_opengl: add log field to MGLContextwm42017-03-182-0/+2
| | | | | | Should have done this 1000 years ago. Now GL backends can use mp_log macros directly on the MPGLContext, instead of doing stupid things like for example MP_WARN(ctx->vo, ...).
* screenshot: change details of --screenshot-format handlingwm42017-03-182-46/+45
| | | | | | | | | | | | | | | | This is just a pointless refactor with the only goal of making image_writer_opts.format a number. The pointless part of it is that instead of using some sort of arbitrary ID (in place of a file extension string), we use a AV_CODEC_ID_. There was also some idea of falling back to the libavcodec MJPEG encoder if mpv was not linked against libjpeg, but this fails. libavcodec insist on having AV_PIX_FMT_YUVJ420P, which we pretend does not exist, and which we always map to AV_PIX_FMT_YUV420P (without the J indicating full range), so encoder init fails. This is pretty dumb, but whatever. The not-caring factor is raised by the fact that we don't know that we should convert to full range, because encoders have no proper way to signal this. (Be reminded that AV_PIX_FMT_YUVJ420P is deprecated.)
* image_writer: remove useless formatswm42017-03-181-4/+0
| | | | Nobody cares about those.
* wayland_common: organize and correctly map mouse buttonsRostislav Pehlivanov2017-03-171-4/+8
| | | | | | | The function tried to do something clever but ignored the fact that the middle button followed the left button rather than the right. Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
* vdpau: warn on HEVC due to completely broken nVidia driverswm42017-03-141-4/+7
| | | | | | I guess that's the full extent I still care about nVidia's broken garbage. In theory, we could always force the video mixer (which is the only method getting the video data that works), but why bother.
* cocoa: set background of the title bar from black to whiteAkemi2017-03-092-1/+3
| | | | | | | | | | | | due to the see-through nature of the title bar and our standard black window background, the title bar appears dark grey opposed to the expected light grey. we change the window background to white but at the same time set the background of the enclosed view to black. that way the title bar has a white background and the background of our video stays black in all cases. this prevents white flashing in some cases when the video is resized with too heavy render settings.
* cocoa: fix autofit options on HiDPI resolutions without HiDPI scalingAkemi2017-03-091-33/+15
| | | | Fixes #4194
* vd_lavc: disable videotoolbox hack with newer ffmpeg versionswm42017-03-071-2/+5
| | | | | The hack becomes unnecessary with newer versions, but it's still needed for older ones.
* options: add M_OPT_FILE to some more file optionsPhilip Sequeira2017-03-064-5/+5
| | | | (Helps shell completion.)
* filter_kernels: Keep f.radius in terms of dest/filter coords.Nicholas J. Kain2017-03-064-12/+20
| | | | | | | | | | | | | The existing code modifies f.radius so that it is in terms of the filter sample radius (in the source coordinate space) and has some small errors because of this behavior. This commit changes f.radius so that it is always in terms of the filter function radius (in the destination coordinate space). The sample radius can always be derived by multiplying f.radius by filter_scale, which is the new, more descriptive name for the previous inv_scale.
* filter_kernels: Apply blur/taper before culling radius.Nicholas J. Kain2017-03-061-3/+3
| | | | | | | | | | | | | Modifications to the input coordinates should all be performed before the final range check against the filter boundaries. However, in the existing code, the blur/taper is applied after the filter radius check is performed. Thus, effectively the filter radius cutoff is applied to only-downscaling-metric-modified coordinates, not the final coordinates. Correct this issue and restructure the returns a bit to make it more obvious what is being done.
* hw_videotoolbox: allow using native decoder output formatwm42017-03-021-2/+8
| | | | | | | Depends on FFmpeg commit ade7c1a2326e2bb9b. It has yet to show whether it actually does what it should. Probably doesn't.
* vd_lavc: log pixel format requested from decoderwm42017-03-011-8/+18
| | | | | | I find it slightly helpful in some situations. Also change the code to have a single exit path to make this easier.
* vf_vavpp: fix first-field modewm42017-02-281-3/+3
| | | | It didn't deinterlace at all. Oops.
* vf_vavpp: add advanced deint bug compatibility for Intel vaapi driverswm42017-02-281-4/+20
| | | | | | | | | | | | | | | I'm not sure what's going on here, but it appears kodi switches forward and backwards references for advanced VPP deinterlacing modes. This in turn makes deinterlacing with these modes apparently work. If you don't switch the directions, you get a stuttering mess. As far as the libva trace dump is concerned, this makes mpv's libva deinterlacing API use behave like kodi's, and appears to reproduce smooth video with advanced libva deinterlacing enabled. I'm hearing that Mesa actually does it correctly, and I'm not sure what will happen there. For now, passing "reversal-bug=no" as sub-option to the vavpp filter will undo this behavior.
* vf_vavpp: minor fixeswm42017-02-281-2/+4
| | | | | | | Fully initialize two structs (not doing so may or may not have been a bug). Actually destroy the VABufferID we create (moderate memory leak).
* cocoa: improve calculation of new window position on a different screenAkemi2017-02-281-13/+44
| | | | | | | | | | | forcibly moving a window from one screen to another is supposed to put it in a position that looks relative the same as on the old screen, as in bottom, top, left and right margin look the same, without changing the window size. in some situations the old code moved the window off screen or on top of the menu bar so it ended up at a somewhat random position. the new code fixes some edge cases but is probably not completely correct since the priority is to make sure that the window ends up on the right screen.
* cocoa: only move window into screen bounds when changing screensAkemi2017-02-271-3/+9
| | | | | | | | | | | when forcibly moving windows to a different screen with --screen or --fs-screen we need to move the window into the screen bounds if the window is out of bounds, otherwise it can end up on the wrong screen. previously it always recalculated the bounds and moved the window when toggling fullscreen, now it only does the bound calculation when changing screens. Fixes #4178
* cocoa: fix segfault in certain circumstancesAkemi2017-02-273-3/+9
| | | | | | | | | | | | | | i falsely assumed that the windowDidChangeScreen was meant to report ‘physical’ screen changes but was wondering why it triggers on other events too. it actually is a event that informs us when anything referenced by our current NSScreen is changed. even when something referenced in the NSScreen changed the old and new NSScreen are still equal if the physical screen didn’t change. with that my previous optimisation broke some cases where the physical screen didn’t change but things it referenced did, leading to a segfault when theses were accessed. to keep the optimisation we will always update our internal NSScreen reference but the rest only when the physical screen was changed.
* cocoa: add option to force dedicated GPUAkemi2017-02-271-15/+32
| | | | Fixes #3242
* osx: drop support for OS X 10.7 and earlierAkemi2017-02-271-2/+0
|
* vo_opengl: hwdec_d3d11egl: make it work with some ANGLE DLL versionswm42017-02-271-1/+7
| | | | | | | | What a fucking waste of time. It depends on with which headers you compile as well, so the situation is worse and more confusing than you'd think. God knows what brain fart made them change the numeric ID without changing the extension name or any other ways to keep ABI-compatibility and without any warning.
* decode: fix extra surface countwm42017-02-274-5/+4
| | | | | | | | | | | | FFmpeg could crash with vaapi (new) and --vo=opengl + interpolation. It seems the actual surface count the old vaapi code uses (and which usually never exceeded the preallocated amount) was higher than what was used for the new vaapi code, so just correct that. The d3d helpers also had weird code that bumped the real pool size, fix them as well. Why this would result in an assertion failure instead of a proper error, who knows.
* vf_vavpp: always limit forward/backward surfaces to requested numberwm42017-02-271-3/+7
| | | | | | Don't give the driver more forward/backward refernces than it requested in num_forward_references/num_backward_references. This shouldn't matter, I'm just trying to play it safe.
* vf_vavpp: remove apparently broken change-detectionwm42017-02-271-2/+0
| | | | | | This is probably wrong. Just don't bother with it. The only potentially negative effect is from calling vaQueryVideoProcPipelineCaps() every frame.
* vo_opengl: use misc/ctype.h instead of <ctype.h>wm42017-02-251-2/+2
| | | | | | Locale-independent, and doesn't have the char vs. unsigned char problem. (Although in this case, the code was fine, because bstr.start is unsigned char.)
* cocoa: fix dragging out of focus windowAkemi2017-02-212-6/+21
| | | | | | | | | | fffab30 introduced a small regression where the cursor couldn't be unhidden after refocusing. the problem is that no mouseUp event was reported in our events_view. work around this with a separate event monitor. this also fixes another regression when the window is being dragged from the title bar. #4174
* vo: fix subtleties in the redrawing logicwm42017-02-213-10/+12
| | | | | | | | | | | | | | | | | This fixes a race condition created by the previous commit, and possibly others. Sometimes interpolated frames weren't redrawn as uninterpolated ones. The problem is that redrawing/drawing a frame can't reset the VO want_redraw flags, because logically these have to happen after the core acknowledged and explicitly reissued a redraw. The core needs to be involved because the OSD text and drawings could depend on the playback or window state. Change it such that it always goes through the core. Also, VOs inconsistently called vo_wakeup() when setting want_redraw, which is also taken care of by this commit.
* player: reduce blocking on VO when switching pausewm42017-02-211-1/+8
| | | | | | | | | | | | | | | | | | | When pausing, we sent BOCTRL_PAUSE and VOCTRL_RESTORE_SCREENSAVER. These essentially wait until the video frame has been rendered. This is a problem with the opengl-cb, if GL rendering is done in the same thread as libmpv uses. Unfortunately, it's allowed to use opengl-cb this way. Logically speaking, it's a deadlock situation, which is resolved with a timeout. This can lead to quite ugly effects, like the on-pause frame not being rendered until the timeout has passed. It has been interpreted as video continuing to play. Resolve this by simply not blocking on pause. Make the screensaver controls async, and handle sending VOCTRL_PAUSE in the VO thread. (All this could be avoided by redoing the internal VO API.) Also see #4152.
* img_format: stop setting some fields to dummy values for hwaccel formatswm42017-02-211-6/+7
| | | | | Flags like MP_IMGFLAG_YUV were meaningless for hwaccel formats, and setting fields like component_bits made even less sense.
* mp_image: for hwaccel, use underlying fmt in mp_image_params_guess_csp()wm42017-02-211-1/+2
| | | | | | | | If imgfmt is a hwaccel format, hw_subfmt will contain the CPU equivalent of the data stored in the hw frames. Strictly speaking, not doing this was a bug, but since hwaccel formats were tagged with MP_IMGFLAG_YUV, it didn't have much of an impact.
* cocoa: only report mouse movements when window is not being draggedAkemi2017-02-203-1/+19
| | | | | | even though the mouse doesn’t move relative to the window itself, when the window is being dragged, some outliers are still reported and trigger the OSC.
* cocoa: make window draggable on initAkemi2017-02-201-0/+2
| | | | | | fixes the case when mpv is opened and the cursor is within the window bounds without moving the mouse. previously the window could only be dragged around after the first mouse movement.
* vo_tct: check ioctl resultrr-2017-02-201-6/+6
|
* image_writer: check a return valuewm42017-02-201-1/+3
| | | | | Doesn't matter, since it's the flush call, but be nice. In particular, don't upset coverity.
* dec_video, dec_audio: remove redundant NULL-checkswm42017-02-201-2/+1
| | | | OK, they're redundant. Now stop wasting my time, coverity.
* lavfi: use mp_image to store the filter pad formatwm42017-02-202-0/+12
| | | | | | | | | | Preparation for enabling hw filters. mp_image_params can't have an AVHWFramesContext reference (because it can't hold any allocations, and isn't meant to hold "active" data in the first place. So just use a mp_image. It has all real data removed, because that would essentially leak 1 frame once the decoder or renderer don't need it anymore.
* Fix two typoswm42017-02-202-2/+2
| | | | They're unrelated. Sue me.
* vd_lavc: increase verbosity if requested hwaccel is not compiledwm42017-02-201-1/+2
| | | | | Well, not like we can detect whether it's missing from libavcodec, but it's still slightly better.
* vd_lavc, vaapi: move hw device creation to generic codewm42017-02-208-160/+104
| | | | | | | | hw_vaapi.c didn't do much interesting anymore. Other than the function to create a device for decoding with vaapi-copy, everything can be done by generic code. Other libavcodec hwaccels are planned to provide the same API as vaapi. It will be possible to drop the other hw_ files in the future. They will use this generic code instead.
* vo_opengl: remove dxva2 dummy hwdec backendwm42017-02-202-69/+0
| | | | | | | | | This was a hack to let libmpv API users pass a d3d device to mpv. It's not needed anymore for 2 reasons: 1. ANGLE does not have this problem 2. Even native GL via nVidia (where this failed) seems to not require this anymore
* cocoa: fix cursor hiding at the top of the screen in fullscreenAkemi2017-02-191-0/+12
| | | | | | | | | | | | | | | | | | | even before the recent refactor the cursor was hidden when moving it to the top of the screen in fullscreen and placing it on top of the now visible menu bar. we need to know when the menu bar is hidden so we don’t create a ‘dead zone’ at the top of the screen where the cursor can’t be hidden. to determine when the menu bar is visible, and with that the title bar, we get the height of the menu bar. the height is always 0 when hidden. furthermore there is no way to get the title bar directly and with that its height. so we calculate the frame rect of a NSWindowStyleMaskTitled window from a CGRectZero content frame. the resulting height is the height of a title bar. with that we can exclude the top area for the cursor hiding and can be certain when the menu bar is not hidden.
* cocoa: fix cursor hiding in the Dock area of the screenAkemi2017-02-191-1/+1
| | | | | | | | | | | | | | | | the cursor couldn’t be hidden when the cursor was at the same position as the Dock, even if the cursor was next to it. this is especially annoying in fullscreen since the Dock isn’t actually hidden but is still reported as being visible. this basically made the part of the screen, where the Dock resides, a ‘dead zone’. so instead of using the visibleFrame we will just use the normal frame. there is no problem at the top area of the screen, since a window can’t be placed above the menu bar and in fullscreen the menu bar is always reported as not being on screen. i suspect this was done so the cursor wasn’t hidden when the it was placed above the Dock when windowed. with the recent refactor this is not needed any more.
* cocoa: simplify the cursor hiding codeAkemi2017-02-191-35/+15
| | | | | | | | | | we can simplify the code because we don't need to change the bool pointer we were given by the VOCTRL_SET_CURSOR_VISIBILITY event. i assume this was done to work around some bugs previously to the recent cursor refactor. i kept that because i thought it was necessary, which wasn't in the end. after the refactor it only caused some weirdnesses i tried to work around. without it we can get rid of some special cases and simplify the code quite a bit.
* cocoa: fix scroll wheel input with Shift modifierAkemi2017-02-191-1/+2
| | | | | | | holding shift swaps the scroll wheel axes and deltaY returned zero. summing up deltaX and deltaY will always give us the right button. Fixes #3506
* vo_opengl: implement videotoolbox hwdec on iOSAman Gupta2017-02-172-1/+215
| | | | | | Implements --hwdec=videotoolbox on iOS. Similar to hwdec_osx.c, but using CVPixelBuffer APIs available on iOS instead of the equivalent IOSurface APIs in macOS.
*