summaryrefslogtreecommitdiffstats
path: root/video/out/vo_vdpau.c
Commit message (Collapse)AuthorAgeFilesLines
* vo_vdpau: fix resizing and rotation problemswm42018-03-081-3/+7
| | | | | | | | | | | | | | | The s_size() function, whatever it was supposed to do, caused the surface size to increase indefinitely. Fix by making it always use the maximum size that was last used, which is less optimal (many surface recreations when making the window slowly larger), but at least it works. The rotation code didn't mark the old surface as invalid when it was freed, so it could destroy random other surfaces (let's call it dangling ID). Also, the required rotation surface size depends on the rotation mode, so recreate the surfaces on rotation as well.
* video: change some remaining vo_opengl mentions to vo_gpuAkemi2018-01-201-1/+1
|
* video: redo video equalizer option handlingwm42017-08-221-37/+3
| | | | | | | | | | | | | | | | | | | | | | | I really wouldn't care much about this, but some parts of the core code are under HAVE_GPL, so there's some need to get rid of it. Simply turn the video equalizer from its current fine-grained handling with vf/vo fallbacks into global options. This makes updating them much simpler. This removes any possibility of applying video equalizers in filters, which affects vf_scale, and the previously removed vf_eq. Not a big loss, since the preferred VOs have this builtin. Remove video equalizer handling from vo_direct3d, vo_sdl, vo_vaapi, and vo_xv. I'm not going to waste my time on these legacy VOs. vo.eq_opts_cache exists _only_ to send a VOCTRL_SET_EQUALIZER, which exists _only_ to trigger a redraw. This seems silly, but for now I feel like this is less of a pain. The rest of the equalizer using code is self-updating. See commit 96b906a51d5 for how some video equalizer code was GPL only. Some command line option names and ranges can probably be traced back to a GPL only committer, but we don't consider these copyrightable.
* options: remove deprecated sub-option handling for --vo and --aowm42016-11-251-1/+1
| | | | | | | | Long planned. Leads to some sanity. There still are some rather gross things. Especially g_groups is ugly, and a hack that can hopefully be removed. (There is a plan for it, but whether it's implemented depends on how much energy is left.)
* vo: remove unused VOCTRL_GET_PANSCANwm42016-09-081-2/+0
| | | | | | It was used to determine whether the VO supports VOCTRL_SET_PANSCAN. With all those changes to property semantics this became unnecessary, and its only use was dropped at some point.
* vo_vdpau: rename some sub-optionswm42016-09-061-3/+6
| | | | | Since the sub-options have been deprecated very recently, and are redirected to global options, we don't need to document this change.
* options: deprecate suboptions for the remaining AO/VOswm42016-09-051-1/+2
|
* x11: stop using vo.event_fdwm42016-07-201-0/+2
| | | | Instead let it do its own event loop wakeup handling.
* vo_vdpau: minor simplificationwm42016-07-071-19/+9
| | | | Remove some indirections that aren't needed anymore.
* vo_vdpau: remove bitmap packer usewm42016-07-011-80/+57
| | | | See previous commit.
* video: refactor how VO exports hwdec device handleswm42016-05-091-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | The main change is with video/hwdec.h. mp_hwdec_info is made opaque (and renamed to mp_hwdec_devices). Its accessors are mainly thread-safe (or documented where not), which makes the whole thing saner and cleaner. In particular, thread-safety rules become less subtle and more obvious. The new internal API makes it easier to support multiple OpenGL interop backends. (Although this is not done yet, and it's not clear whether it ever will.) This also removes all the API-specific fields from mp_hwdec_ctx and replaces them with a "ctx" field. For d3d in particular, we drop the mp_d3d_ctx struct completely, and pass the interfaces directly. Remove the emulation checks from vaapi.c and vdpau.c; they are pointless, and the checks that matter are done on the VO layer. The d3d hardware decoders might slightly change behavior: dxva2-copy will not use the VO device anymore if the VO supports proper interop. This pretty much assumes that any in such cases the VO will not use any form of exclusive mode, which makes using the VO device in copy mode unnecessary. This is a big refactor. Some things may be untested and could be broken.
* vo_opengl: vdpau: fix certain cases of preemption recovery failureswm42016-05-031-1/+0
| | | | | | | | | | | | | | The vdpau_mixer could fail to be recreated properly if preemption occured at some point before playback initialization (like when using --hwdec-preload and the opengl-cb API). Normally, the vdpau_mixer was supposed to be marked invalid when the components using it detect a preemption, e.g. in hwdec_vdpau.c. This one didn't mark the vdpau_mixer as invalid if preemption was detected in reinit(), only in map_image(). It's cleaner to detect preemption directly in the vdpau_mixer, which ensures it's always recreated correctly.
* mpv_talloc.h: rename from talloc.hDmitrij D. Czarkoff2016-01-111-1/+1
| | | | This change helps avoiding conflict with talloc.h from libtalloc.
* vo_opengl: disable interpolation without display-syncwm42015-11-251-1/+1
| | | | | Without display-sync mode, our guesses wrt. vsync phase etc. are much worse, and I see no reason to keep the complicated "vsync_timed" code.
* Remove some VLAswm42015-11-061-2/+4
| | | | | | | | They are evil and should be eradicated. Some of these were pretty dumb anyway. There are probably some more around in platform specific code or other code not enabled by default on Linux.
* vo_vdpau: check VDP_RGBA_FORMAT_A8 supportwm42015-11-041-2/+6
| | | | | Apparently not all vdpau drivers in the wild support this format (VDPAU SUNXI can't). Revert to RGB in these cases.
* video/out: remove an unused parameterwm42015-10-031-1/+1
| | | | | | | | | | | This parameter has been unused for years (the last flag was removed in commit d658b115). Get rid of it. This affects the general VO API, as well as the vo_opengl backend API, so it touches a lot of files. The VOFLAGs are still used to control OpenGL context creation, so move them to the OpenGL backend code.
* x11: separate window creation and configurationwm42015-09-301-1/+6
| | | | | | | | | | | | | | | | | | | This gets rid of an old hack, VOFLAG_HIDDEN. Although handling of it has been sane for a while, it used to cause much pain, and is still unintuitive and weird even today. The main reason for this hack is that OpenGL selects a X11 Visual for you, and you're supposed to use this Visual when creating the X window for the OpenGL context. Which means the X window can't be created early in the common X11 init code, but the OpenGL code needs to do something before that. API-wise you need separate functions for X11 init and X11 window creation. The VOFLAG_HIDDEN hack conflated window creation and the entrypoint for resizing on video resolution change into one function, vo_x11_config_vo_window(). This required all platform backends to handle this flag, even if they didn't need this mechanism. Wayland still uses this for minor reasons (alpha support?), so the wayland backend must be changed before the flag can be entirely removed.
* video: replace vf_format outputlevels option with global optionwm42015-09-291-4/+0
| | | | | | | | | | | The vf_format suboption is replaced with --video-output-levels (a global option and property). In particular, the parameter is removed from mp_image_params. The mechanism is moved to the "video equalizer", which also handles common video output customization like brightness and contrast controls. The new code is slightly cleaner, and the top-level option is slightly more user-friendly than as vf_format sub-option.
* vo_vdpau: fix frame scheduling if display FPS is unknownwm42015-08-041-1/+1
| | | | | | | | | | | Pretty stupid: vo_get_vsync_interval() returns a negative value if the display FPS is unknown (e.g. xrandr not compiled), and the comparison whether the value is below 0 fails later because it's assigned to an unsigned int. Regression since commit e3d85ad4. Also, fix some comments in vo.c.
* vo: minor simplification for queue size handlingwm42015-07-201-1/+1
| | | | | | | | | | 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_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: better magic value for unknown vsync intervalwm42015-07-011-0/+1
| | | | | The value 1 is useful in some contexts, but not such a good choice otherwise.
* vo: change internal API for drawing frameswm42015-07-011-18/+27
| | | | | | | | | | | | | | 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.
* video: pass future frames to VOwm42015-07-011-1/+1
| | | | | | | | | | 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: reduce error message when loading hwdec backend failswm42015-06-201-1/+1
| | | | | | | | | | | | | | | | | 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).
* 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?
* 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.
* vdpau: retrieve mixer parameters directly from the hw surfacewm42015-05-281-4/+1
| | | | | | | | | | | | Always configure the vdpau mixer based on the current surface sent to it. Before this, we just hardcoded the chroma type, and the surface size was essentially a guess. Calling VdpVideoSurfaceGetParameters() on every surface is a bit suspicious, but it appears it's a cheap function (just requiring some locks and a table lookup). This way we avoid creating another complicated mechanism to carry around the actual surface parameters with a mp_image/AVFrame.
* video/out: remove VOFLAG_FLIPPINGwm42015-05-011-4/+2
| | | | | | | I think this used to be quite important, because the ancient VfW support in MPlayer used to output flipped frames. This code has been dead in mpv for quite some time (because VfW decoders were removed, and the --flip option was dropped too), so get rid of it.
* Update license headersMarcin Kurczewski2015-04-131-5/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* video/out: fix screenshot image formatswm42015-04-071-1/+1
| | | | | | | Use variants without alpha. I skipped vo_sdl, because format selection seems a bit more complicated here, and nobody cares about vo_sdl anymore.
* video/out: remove unused colorspace reportingwm42015-03-311-9/+0
| | | | | | | | Rarely used and essentially useless. The only VO for which this was implemented correctly and for which this did anything was vo_xv, but you shouldn't use vo_xv anyway (plus it support BT.601 only, plus a vendor specific extension for BT.709, whose presence this function essentially reported - use xvinfo instead).
* vo_vdpau: remove some minor code duplicationwm42015-03-231-13/+7
| | | | | The way-too-big API call for clearing the screen can be easily shared between two completely different codepaths.
* vo_vdpau: check vdpau API return valuewm42015-03-231-0/+1
|
* osd: simplify an aspect of change detection handlingwm42015-03-181-10/+4
| | | | | | | | | | | | | | | | | | There was a somewhat obscure optimization in the OSD and subtitle rendering path: if only the position of the sub-images changed, and not the actual image data, uploading of the image data could be skipped. In theory, this could speed up things like scrolling subtitles. But it turns out that even in the rare cases subtitles have such scrolls or axis-aligned movement, modern libass rarely signals this kind of change. Possibly this is because of sub-pixel handling and such, which break this. As such, it's a worthless optimization and just introduces additional complexity and subtle bugs (especially in cases libass does the opposite: incorrectly signaling a position change only, which happened before). Remove this optimization, and rename bitmap_pos_id to change_id.
* buid: readd -Wparentheseswm42015-03-021-1/+1
| | | | | | | | | This warning wasn't overly helpful in the past, and warned against perfectly fine code. But at least with recent gcc versions, this is the warning that complains about assignments in if expressions (why???), so we want to enable it. Also change all the code this warning complains about for no reason.
* vo_vdpau: minor simplificationwm42015-02-071-4/+1
| | | | No change in behavior.
* vo_vdpau: remove unneeded codewm42015-02-041-4/+0
| | | | This is already done in the common vo.c code.
* vo: simplify VOs by adding generic screenshot supportwm42015-01-241-9/+1
| | | | | | | | | | | At the time screenshot support was added, images weren't refcounted yet, so screenshots required specialized implementations in the VOs. But now we can handle these things much simpler. Also see commit 5bb24980. If there are VOs in the future which can't do this (e.g. they need to write to the image passed to vo_driver->draw_image), this still could be disabled on a per-VO basis etc., so we lose no potential performance advantages.
* video: separate screenshot modeswm42015-01-231-5/+6
| | | | | | | | | Use different VOCTRLs for "window" and normal screenshot modes. The normal one will probably be removed, and replaced by generic code in vo.c, and this commit is preparation for this. (Doing it the other way around would be slightly simpler, but I haven't decided yet about the second one, and touching every VO is needed anyway in order to remove the unneeded crap. E.g. has_osd has been unused for a long time.)
* vo: fix disabling/enabling smoothmotion at runtimewm42015-01-231-1/+1
| | | | | | | | | | | | | vo.c queried the VO at initialization whether it wants to be updated on every display frame, or every video frame. If the smoothmotion option was changed at runtime, the rendering mode in vo.c wasn't updated. Just let vo_opengl set the mode directly. Abuse the existing vo_set_flip_queue_offset() function for this. Also add a comment suggesting the use of --display-fps to the manpage, which doesn't have anything to do with the rest of this commit, but is important to make smoothmotion run well.
* vo_vdpau: don't render to an output surface if it could be busywm42015-01-221-6/+6
| | | | | | There was a case when we could have rendered to an output surface while it's still used for display. Not sure why the API doesn't do this automatically.
* video: handle hwdec screenshots differentlywm42015-01-221-45/+7
| | | | | | | | Instead of converting the hw surface to an image in the VO, provide a generic way to convet hw surfaces, and use this in the screenshot code. It's all relatively straightforward, except vdpau is being terrible. It needs a huge chunk of new code, because copying back is not simple.
* video: have a generic context struct for hwdec backendswm42015-01-221-1/+1
| | | | | | | | | | | Before this commit, each hw backend had their own specific struct types for context, and some, like VDA, had none at all. Add a context struct (mp_hwdec_ctx) that provides a somewhat generic way to pass the hwdec context around. Some things get slightly better, some slightly more verbose. mp_hwdec_info is still around; it's still needed, but is reduced to its role of handling delayed loading of the hwdec backend.
* video: remove vfcap.hwm42015-01-211-5/+3
| | | | | | | | | | | | | | | | | And remove all uses of the VFCAP_CSP_SUPPORTED* constants. This is supposed to reduce conversions if many filters are used (with many incompatible pixel formats), and also for preferring the VO's natively supported pixel formats (as opposed to conversion). This is worthless by now. Not only do the main VOs not use software conversion, but also the way vf_lavfi and libavfilter work mostly break the way the old MPlayer mechanism worked. Other important filters like vf_vapoursynth do not support "proper" format negotation either. Part of this was already removed with the vf_scale cleanup from today. While I'm touching every single VO, also fix the query_format argument (it's not a FourCC anymore).
* vo: fix some nonsensewm42014-12-101-2/+0
| | | | | | | | | Commit d38bc531 is incorrect: the 50ms queue-ahead value and the flip queue offset have different functions. The latter is about calling flip_page in advance, so the change attempted to show video frames 50ms in advance on all VOs. The change was for vo_opengl_cb, but that can be handled differently.
* vo: include normal render-ahead time in flip_queue_offsetwm42014-12-091-7/+8
| | | | | | A small refactor; shouldn't change any behavior. Do this so immediate display can be achieved.
* vdpau/GLX: don't access VO backendwm42014-12-031-1/+1
| | | | | | | | | Same as with the previous commits. In theory, vdpau/x11 GL interop doesn't assume GLX. It could use EGL as well. But since it's always GLX in practice, so we're fine with this. Remove the gl_hwdec.mpgl field - it's unused now.
* command: make window-scale property observablewm42014-11-021-0/+1
| | | | | | | | | | | | Add a generic mechanism to the VO to relay "extra" events from VO to player. Use it to notify the core of window resizes, which in turn will be used to mark all affected properties ("window-scale" in this case) as changed. (I refrained from hacking this as internal command into input_ctx, or to poll the state change, etc. - but in the end, maybe it would be best to actually pass the client API context directly to the places where events can happen.)
* vo_vdpau: don't try to create surfaces of size 0wm42014-10-011-10/+9
| | | | | | | | | | | | | | | | | | | | | | At least on kwin, we decide to proceed without waiting for the window being mapped (due to the frame exts hack, see commit 8c002b79). But that leaves us with a window size of 0x0, which causes VdpOutputSurfaceCreate to fail. This prints some warnings, although vo_vdpau recovers later and this has no other bad consequences. Do the following things to deal with this: - set the "known" window size to the suggested window size before the window is even created - allow calling XGetGeometry on the window even if the window is not mapped yet (this should work just fine) - make the output surface minimum size 1x1 Strictly speaking, only one of these would be required to make the warning disappear, but they're all valid changes and increase robustness and