summaryrefslogtreecommitdiffstats
path: root/video/out/vo.h
Commit message (Collapse)AuthorAgeFilesLines
* video: add vaapi decode and output supportwm42013-08-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is based on the MPlayer VA API patches. To be exact it's based on a very stripped down version of commit f1ad459a263f8537f6c from git://gitorious.org/vaapi/mplayer.git. This doesn't contain useless things like benchmarking hacks and the demo code for GLX interop. Also, unlike in the original patch, decoding and video output are split into separate source files (the separation between decoding and display also makes pixel format hacks unnecessary). On the other hand, some features not present in the original patch were added, like screenshot support. VA API is rather bad for actual video output. Dealing with older libva versions or the completely broken vdpau backend doesn't help. OSD is low quality and should be rather slow. In some cases, only either OSD or subtitles can be shown at the same time (because OSD is drawn first, OSD is prefered). Also, libva can't decide whether it accepts straight or premultiplied alpha for OSD sub-pictures: the vdpau backend seems to assume premultiplied, while a native vaapi driver uses straight. So I picked straight alpha. It doesn't matter much, because the blending code for straight alpha I added to img_convert.c is probably buggy, and ASS subtitles might be blended incorrectly. Really good video output with VA API would probably use OpenGL and the GL interop features, but at this point you might just use vo_opengl. (Patches for making HW decoding with vo_opengl have a chance of being accepted.) Despite these issues, decoding seems to work ok. I still got tearing on the Intel system I tested (Intel(R) Core(TM) i3-2350M). It was also tested with the vdpau vaapi wrapper on a nvidia system; however this was rather broken. (Fortunately, there is no reason to use mpv's VAAPI support over native VDPAU.)
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-061-2/+2
| | | | Followup commit. Fixes all the files references.
* video/out: use new mp_msg stuff for vo.c and vo_openglwm42013-07-311-3/+8
| | | | The first step; also serves as example.
* vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel APIwm42013-07-281-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This file is named so because because it's written against the "old" libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau"). Add support for the "new" libavcodec vdpau support. This was recently added and replaces the "old" vdpau parts. (In fact, Libav is about to deprecate and remove the "old" API without deprecation grace period, so we have to support it now. Moreover, there will probably be no Libav release which supports both, so the transition is even less smooth than we could hope, and we have to support both the old and new API.) Whether the old or new API is used is checked by a configure test: if the new API is found, it is used, otherwise the old API is assumed. Some details might be handled differently. Especially display preemption is a bit problematic with the "new" libavcodec vdpau support: it wants to keep a pointer to a specific vdpau API function (which can be driver specific, because preemption might switch drivers). Also, surface IDs are now directly stored in AVFrames (and mp_images), so they can't be forced to VDP_INVALID_HANDLE on preemption. (This changes even with older libavcodec versions, because mp_image always uses the newer representation to make vo_vdpau.c simpler.) Decoder initialization in the new code tries to deal with codec profiles, while the old code always uses the highest profile per codec. Surface allocation changes. Since the decoder won't call config() in vo_vdpau.c on video size change anymore, we allow allocating surfaces of arbitrary size instead of locking it to what the VO was configured. The non-hwdec code also has slightly different allocation behavior now. Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau doesn't work anymore (a warning suggesting the --hwdec option is printed instead).
* video/out: remove options argument from preinit()wm42013-07-221-3/+1
| | | | | All VOs use proper option parsing now, and compatibility hacks are not needed.
* options: use new code for parsing --vowm42013-07-211-4/+0
| | | | | | | | | Nothing should change from user perspective. mpv --vo=opengl:help now works. Remove the vo_opengl inline help text. The new code can list option names for you, but that's it. Refer to the manpage if you have trouble.
* video: remove fullscreen flags chaoswm42013-07-181-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There was a MPOpts fullscreen field, a mp_vo_opts.fs field, and VOFLAG_FULLSCREEN. Remove all these and introduce a mp_vo_opts.fullscreen flag instead. When VOs receive VOCTRL_FULLSCREEN, they are supposed to set the current fullscreen mode to the state in mp_vo_opts.fullscreen. They also should do this implicitly on config(). VOs which are capable of doing so can update the mp_vo_opts.fullscreen if the actual fullscreen mode changes (e.g. if the user uses the window manager controls). If fullscreen mode switching fails, they can also set mp_vo_opts.fullscreen to the actual state. Note that the X11 backend does almost none of this, and it has a private fs flag to store the fullscreen flag, instead of getting it from the WM. (Possibly because it has to deal with broken WMs.) The fullscreen option has to be checked on config() to deal with the -fs option, especially with something like: mpv --fs file1.mkv --{ --no-fs file2.mkv --} (It should start in fullscreen mode, but go to windowed mode when playing file2.mkv.) Wayland changes by: Alexander Preisinger <alexander.preisinger@gmail.com> Cocoa changes by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
* vo: remove aspdat.asp memberwm42013-07-181-1/+0
| | | | | | This was bad, because it was the only aspdat member updated by vo_get_src_dst_rects() instead of vo_reconfig(). Now it isn't accessed anymore, so remove it.
* core: remove mp_fifo leftoverswm42013-07-041-1/+0
|
* core: remove mp_fifo indirectionwm42013-07-021-1/+0
| | | | | | | | | | For some reason mp_fifo specifically handled double clicks, and other than that was a pointless wrapper around input.c functionality. Move the double click handling into input.c, and get rid of mp_fifo. Add some compatibility wrappers, because so much VO code uses these functions. Where struct mp_fifo is still used it's just a casted struct input_ctx.
* input: handle mouse movement differentlywm42013-06-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this commit, mouse movement events emitted a special command ("set_mouse_pos"), which was specially handled in command.c. This was once special-cased to the dvdnav and menu code, and did nothing after libmenu and dvdnav were removed. Change it so that mouse movement triggers a pseudo-key ("MOUSE_MOVE"), which then can be bound to an arbitrary command. The mouse position is now managed in input.c. A command which actually needs the mouse position can use either mp_input_get_mouse_pos() or mp_get_osd_mouse_pos() to query it. The former returns raw window-space coordinates, while the latter returns coordinates transformed to OSD- space. (Both are the same for most VOs, except vo_xv and vo_x11, which can't render OSD in window-space. These require extra code for mapping mouse position.) As of this commit, there is still nothing that uses mouse movement, so MOUSE_MOVE is mapped to "ignore" to silence warnings when moving the mouse (much like MOUSE_BTN0). Extend the concept of input sections. Allow multiple sections to be active at once, and organize them as stack. Bindings from the top of the stack are preferred to lower ones. Each section has a mouse input section associated, inside which mouse events are associated with the bindings. If the mouse pointer is outside of a section's mouse area, mouse events will be dispatched to an input section lower on the stack of active sections. This is intended for scripting, which is to be added later. Two scripts could occupy different areas of the screen without conflicting with each other. (If it turns out that this mechanism is useless, we'll just remove it again.)
* video: add a new method to configure filters and VOswm42013-06-281-15/+22
| | | | | | | | | | | | | | | | | | The filter chain and the video ouputs have config() functions. They are strictly limited to transfering the video size and format. Other parameters (like color levels) have to be transferred separately. Improve upon this by introducing a separate set of reconfig() functions, which use mp_image_params to carry format parameters. This struct contains all image format related parameters from config(), plus additional parameters such as colorspace. Change vf_rotate to use it, as well as vo_opengl. vf_rotate is just an example/test case, but vo_opengl will need it later. The intention is also to get rid of VOCTRL_SET_YUV_COLORSPACE. This information is now handed to the VOs via reconfig(). The getter, VOCTRL_GET_YUV_COLORSPACE, will still be needed though.
* video/out: introduce VOCTRL_UPDATE_WINDOW_TITLEwm42013-06-151-0/+1
| | | | | | | | | | | Instead of implicitly changing the window title on config(), do it as part of the new VOCTRL. At first I wanted to make all VOs use the VOCTRL argument directly, but on a second thought it appears vo_get_window_title() is much more useful for some (namely, if the window is created lazily on first config()). Not all VOs are changed. Wayland and OSX have to follow.
* vo: define VO_TRUE/FALSE to C99 constantswm42013-06-151-2/+2
| | | | | | | | | This make the intention more apparent, and some VOs are actually using true instead of VO_TRUE in some places. Hopefully this changes makes it less confusing (instead of more). The C99 constants true/false are defined to 1/0 as well, so this commit doesn't actually change anything.
* core: introduce separate VOCTRLs for screensaver stop/resumewm42013-06-141-0/+3
| | | | | | | | | | | | | | | | | | | | | | This is slightly better because VOCTRL_RESUME/VOCTRL_PAUSE are usually needed by VOs to know whether video is actually being played (for whatever reason), and they wouldn't be passed to the backend's VOCTRL handler, like vo_x11_control(). Also try to make sure that these flags (both pause state and screensaver state) are set consistently in some corner cases. For example, it seems enabling video in the middle of playing a file while the player is paused would not set the paused flag. If codec initialization fails, destroy the VO instead of keeping it around to make sure the state is consistent. Framestepping is implemented by unpausing the player for the duration of a frame. Remove the special handling of VOCTRL_PAUSE/RESUME in these cases. It was most likely needed because these VOCTRLs used to be important for screen redrawing (blatant guess), which is now handled completely differently. The only potentially bad side-effect is that the screensaver will be disabled/reenabled for the duration of one frame.
* Replace all calls to GetTimer()/GetTimerMS()wm42013-05-261-1/+5
| | | | | | | | | | | | | | | | | | | | | | GetTimer() is generally replaced with mp_time_us(). Both calls return microseconds, but the latter uses int64_t, us defined to never wrap, and never returns 0 or negative values. GetTimerMS() has no direct replacement. Instead the other functions are used. For some code, switch to mp_time_sec(), which returns the time as double float value in seconds. The returned time is offset to program start time, so there is enough precision left to deliver microsecond resolution for at least 100 years. Unless it's casted to a float (or the CPU reduces precision), which is why we still use mp_time_us() out of paranoia in places where precision is clearly needed. Always switch to the correct time. The whole point of the new timer calls is that they don't wrap, and storing microseconds in unsigned int variables would negate this. In some cases, remove wrap-around handling for time values.
* vo: rip out VO timer wakeup mechanism againwm42013-05-261-4/+0
| | | | | | | This was used by some VOs to do timing of cursor autohiding, but we recently moved that out of the VOs. Even though this mechanism might be a good idea and could be needed again in future (but for what?), it's unused now. So better just get rid of it.
* core: do mouse cursor hiding business in frontendwm42013-05-261-0/+2
| | | | | Do this so that not every VO backend has to setup a timer for cursor hiding and interpret the --cursor-autohide option.
* vo: remove vo.check_events callbackwm42013-05-261-6/+0
| | | | | | Use VOCTRL_CHECK_EVENTS instead. Change the remaining VOs to use it. Only vo_sdl and vo_caca actually need this, and vo_null, vo_lavc, and vo_image had stubs only.
* video/out: introduce vo_control for gl_common based VOswm42013-05-261-0/+2
| | | | | | | | | | | | | | | | Instead of having separate callbacks for each backend-handled feature (like MPGLContext.fullscreen, MPGLContext.border, etc.), pass the VOCTRL responsible for this directly to the backend. This allows removing a bunch of callbacks, that currently must be set even for optional/lesser features (like VOCTRL_BORDER). This requires changes to all VOs using gl_common, as well as all backends that support gl_common. Also introduce VOCTRL_CHECK_EVENTS. vo.check_events is now optional. VO backends can use VOCTRL_CHECK_EVENTS instead to implementing check_events. This has the advantage that the event handling code in VOs doesn't have to be duplicated if vo_control() is used.
* vo: remove unused callbackwm42013-05-231-1/+0
|
* vo: rename vo_draw_image to vo_queue_imagewm42013-03-281-1/+1
|
* vo: remove two unused symbolswm42013-03-281-6/+0
|
* vo_opengl: add alpha outputwm42013-03-281-0/+1
| | | | | | | | | | | | | | | | | | | Allows playing video with alpha information on X11, as long as the video contains alpha and the window manager does compositing. See vo.rst. Whether a window can be transparent is decided by the choice of the X Visual used for window creation. Unfortunately, there's no direct way to request such a Visual through the GLX or the X API, and use of the XRender extension is required to find out whether a Visual implies a framebuffer with alpha used by XRender (see for example [1]). Instead of depending on the XRender wrapper library (which would require annoying configure checks, even though XRender is virtually always supported), use a simple heuristics to find out whether a Visual has alpha. Since getting it wrong just means an optional feature will not work as expected, we consider this ok. [1] http://stackoverflow.com/questions/4052940/how-to-make-an-opengl- rendering-context-with-transparent-background/9215724#9215724
* vo_opengl: split into multiple files, convert to new option APIwm42013-03-281-0/+6
| | | | | | gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
* video: simplify aspect calculation stuffwm42013-03-171-12/+2
| | | | | | | Remove lots of weird logic and dead code. The only difference is that when specifying a monitor aspect ratio, it will always upscale and never downscale.
* vo: Separate vo options from MPOptsAlexander Preisinger2013-03-041-3/+3
| | | | | | | Separate the video output options from the big MPOpts structure and also only pass the new mp_vo_opts structure to the vo backend. Move video_driver_list into mp_vo_opts
* Remove vo_fps global variablewm42013-03-041-2/+0
| | | | | This is needed by the encode stuff for some reason, so we have to explicitly pass it. Functionality shouldn't change.
* vo: remove and cleanup globalsAlexander Preisinger2013-03-041-21/+6
| | | | | | | | Removes almost every global variabel in vo.h and puts them in a special struct in MPOpts for video output related options. Also we completly remove the options/globals pts and refresh rate because they were unused.
* x11_common: fix --cursor-autohide when pausedwm42013-03-031-0/+4
| | | | | | | | When paused, --cursor-autohide worked with a precision of 500ms, which is the main loop's default sleep time when paused. Cursor hiding is polled in x11_common, and the main loop never called the X11 code at the right time. Fix this by allowing the VO to set a time when it should be called next.
* x11_common: use private variables for window statewm42013-03-031-2/+0
| | | | | | | | | | | | | | | | Store the window state (position and size) in vo_x11_state, instead of in vo->dx/dy/dwidth/dheight. The VO variables are overwritten by vo.c on every vo_config() call, which is extremely not helpful. Now vo->dx/dy are mostly unused (except for passing the position forced by the --geometry option), and vo->dwidth/dheight are set for the VO, and otherwise read for resize detection only. In the long term, the way vo_config() handles the --geometry option should be changed, and vo->dx/dy should be removed. Remove some useless stuff: VO_EVENT_MOVE and VO_EVENT_KEYPRESS were generated, but unused. Wayland changes by Alexander Preisinger.
* video/out: remove VO_EVENT_REINITwm42013-03-031-1/+0
| | | | | | | It was once used for vo_sdl (the old one based on SDL 1.2), since SDL apparently lost the GL state when switching to fullscreen. The new vo_sdl (using SDL 1.3) doesn't use or need this. It's dead code, so get rid of it.
* core: simplify OSD capability handling, remove VFCAP_OSDwm42013-03-011-1/+1
| | | | | | | | | | | | | | | | | | | VFCAP_OSD was used to determine at runtime whether the VO supports OSD rendering. This was mostly unused. vo_direct3d had an option to disable OSD (was supposed to allow to force auto-insertion of vf_ass, but we removed that anyway). vo_opengl_old could disable OSD rendering when a very old OpenGL version was detected, and had an option to explicitly disable it as well. Remove VFCAP_OSD from everything (and some associated logic). Now the vo_driver.draw_osd callback can be set to NULL to indicate missing OSD support (important so that vo_null etc. don't single-step on OSD redraw), and if OSD support depends on runtime support, the VO's draw_osd should just do nothing if OSD is not available. Also, do not access vo->want_redraw directly. Change the want_redraw reset logic for this purpose, too. (Probably unneeded, vo_flip_page resets it already.)
* wayland: add wayland supportAlexander Preisinger2013-02-281-0/+1
| | | | | | | | | | | | | | | | | | | | | All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
* video/out: remove video mode switching (--vm)wm42013-02-261-2/+0
| | | | | | | | | | | | | | | | | | | | This allowed making the player switch the monitor video mode when creating the video window. This was a questionable feature, and with today's LCD screens certainly not useful anymore. Switching to a random video mode (going by video width/height) doesn't sound too useful either. I'm not sure about the win32 implementation, but the X part had several bugs. Even in mplayer-svn (where x11_common.c hasn't been receiving any larger changes for a long time), this code is buggy and doesn't do the right thing anyway. (And what the hell _did_ it do when using multiple physical monitors?) If you really want this, write a shell script that calls xrandr before and after calling mpv. vo_sdl still can do mode switching, because SDL has native support for it, and using it is trivial. Add a new sub-option for this.
* Remove --rootwin option and rootwin propertywm42013-02-241-2/+0
| | | | | | | | You can just use --wid=0 if you really want this. This only worked/works for X11, and even then it might interact badly with most desktop environments. All the option did was setting --wid to 0, and the property did nothing.
* core: move `xineramascreen` to `MPOpts` as `vo_screen_id`Stefano Pigozzi2013-02-211-1/+0
| | | | This is a small cleanup in preparation for the next commit.
* audio/out, video/out: hide encoding VO/AOwm42013-02-061-0/+3
| | | | | | mpv -ao help and mpv -vo help shouldn't show the encoding outputs (named "lavc" on both cases). Also make it impossible to select these manually when not encoding.
* video: decouple internal pixel formats from FourCCswm42013-01-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mplayer's video chain traditionally used FourCCs for pixel formats. For example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the string 'YV12' interpreted as unsigned int. Additionally, it used to encode information into the numeric values of some formats. The RGB formats had their bit depth and endian encoded into the least significant byte. Extended planar formats (420P10 etc.) had chroma shift, endian, and component bit depth encoded. (This has been removed in recent commits.) Replace the FourCC mess with a simple enum. Remove all the redundant formats like YV12/I420/IYUV. Replace some image format names by something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P. Add img_fourcc.h, which contains the old IDs for code that actually uses FourCCs. Change the way demuxers, that output raw video, identify the video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to request the rawvideo decoder, and sh_video->imgfmt specifies the pixel format. Like the previous hack, this is supposed to avoid the need for a complete codecs.cfg entry per format, or other lookup tables. (Note that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT raw video, but this is still considered better than adding a raw video decoder - even if trivial, it would be full of annoying lookup tables.) The TV code has not been tested. Some corrective changes regarding endian and other image format flags creep in.
* video: cleanup: replace old mp_image function nameswm42013-01-131-1/+1
| | | | | mp_image_alloc() also changes argument order compared to alloc_mpi(). The format now comes first, then width/height.
* video/out: replace VFCAP_TIMER with vo->untimed, fix vo_image and vo_lavcwm42013-01-131-0/+2
| | | | | | | | VFCAP_TIMER disables any additional waiting done by mpv in the playloop. Remove VFCAP_TIMER, but re-use the idea for vo_image and vo_lavc. This means --untimed doesn't have to be passed when using --vo=image.
* video/filter: change filter API, use refcounting, remove filter DRwm42013-01-131-2/+2
| | | | | | | | | | | | | | | | | | | | Change the entire filter API to use reference counted images instead of vf_get_image(). Remove filter "direct rendering". This was useful for vf_expand and (in rare cases) vf_sub: DR allowed these filters to pass a cropped image to the filters before them. Then, on filtering, the image was "uncropped", so that black bars could be added around the image without copying. This means that in some cases, vf_expand will be slower (-vf gradfun,expand for example). Note that another form of DR used for in-place filters has been replaced by simpler logic. Instead of trying to do DR, filters can check if the image is writeable (with mp_image_is_writeable()), and do true in-place if that's the case. This affects filters like vf_gradfun and vf_sub. Everything has to support strides now. If something doesn't, making a copy of the image data is required.
* video: make vdpau hardware decoding not use DR code pathwm42013-01-131-2/+2
| | | | | | vdpau hardware decoding used the DR (direct rendering) path to let the decoder query a surface from the VO. Special-case the HW decoding path instead, to make it separate from DR.
* video: remove slice based filtering and video outputwm42013-01-131-14/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Slices allowed filtering or drawing video in horizontal bands or blocks. This allowed working on the video i