summaryrefslogtreecommitdiffstats
path: root/video/out/vo_vdpau.c
Commit message (Collapse)AuthorAgeFilesLines
* vo_vdpau: don't calculate destination alpha when drawing OSDwm42013-11-181-2/+2
| | | | | | Same as MPlayer svn commit r36515 "Chose cheaper alpha blend equation." No idea if this is actually faster, but can't hurt.
* vdpau: move device and video surface management from vo_vdpau.c to vdpau.cwm42013-11-051-214/+34
| | | | | The goal is being able to use vdpau decoding independently from vo_vdpau.c.
* configure: uniform the defines to #define HAVE_xxx (0|1)Stefano Pigozzi2013-11-031-1/+1
| | | | | | | | | | | | | | | | | | | | | The configure followed 5 different convetions of defines because the next guy always wanted to introduce a new better way to uniform it[1]. For an hypothetic feature 'hurr' you could have had: * #define HAVE_HURR 1 / #undef HAVE_DURR * #define HAVE_HURR / #undef HAVE_DURR * #define CONFIG_HURR 1 / #undef CONFIG_DURR * #define HAVE_HURR 1 / #define HAVE_DURR 0 * #define CONFIG_HURR 1 / #define CONFIG_DURR 0 All is now uniform and uses: * #define HAVE_HURR 1 * #define HAVE_DURR 0 We like definining to 0 as opposed to `undef` bcause it can help spot typos and is very helpful when doing big reorganizations in the code. [1]: http://xkcd.com/927/ related
* Enable -Wshadowwm42013-11-011-1/+0
| | | | | | | | | This one really did bite me hard (see previous commit), so enable it by default. Fix some cases of shadowing throughout the codebase. None of these change behavior, and all of these were correct code, and just tripped up the warning.
* video/out: remove useless info struct and redundant fieldswm42013-10-231-7/+3
| | | | The author and comment fields were printed only in -v mode.
* vo_vdpau: don't blank screen on VOCTRL_RESETwm42013-10-021-16/+35
| | | | | | | | | | | vo_vdpau is the only VO which implements VOCTRL_RESET. Redrawing the last output frame is hard, because the output could consist of several source video frames with certain types of post-processing (deinterlacing). Implement redrawing as special case by keeping the previous video frames aside until at least one new frame is decoded. This improves the previous commit, but is separate, because it's rather complicated.
* video/out: always support redrawing VO window at any pointwm42013-10-021-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | Before, a VO could easily refuse to respond to VOCTRL_REDRAW_FRAME, which means the VO wouldn't redraw OSD and window contents, and the player would appear frozen to the user. This was a bit stupid, and makes dealing with some corner cases much harder (think of --keep-open, which was hard to implement, because the VO gets into this state if there are no new video frames after a seek reset). Change this, and require VOs to always react to VOCTRL_REDRAW_FRAME. There are two aspects of this: First, behavior after a (successful) vo_reconfig() call, but before any video frame has been displayed. Second, behavior after a vo_seek_reset(). For the first issue, we define that sending VOCTRL_REDRAW_FRAME after vo_reconfig() should clear the window with black. This requires minor changes to some VOs. In particular vaapi makes this horribly complicated, because OSD rendering is bound to a video surface. We create a black dummy surface for this purpose. The second issue is much simpler and works already with most VOs: they simply redraw whatever has been uploaded previously. The exception is vdpau, which has a complicated mechanism to track and filter video frames. The state associated with this mechanism is completely cleared with vo_seek_reset(), so implementing this to work as expected is not trivial. For now, we just clear the window with black.
* Some more mp_msg conversionswm42013-08-231-51/+45
| | | | | Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
* vo_vdpau: add RGB supportwm42013-08-181-14/+154
| | | | | | | | | | | | | | | | | | | | | Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
* vo_vdpau: fix screenshots if panscan is usedwm42013-08-181-4/+5
| | | | | | | When panscan was used, i.e. the video is cropped to make the video fill the screen if video and screen aspects don't match, screenshots contained only the visible region of the source video, stretched to original video size.
* vo_vdpau: remove unused variablewm42013-08-181-2/+0
| | | | | It was used to manage video surface in the software decoding path, but now surface management shares the code with hardware decoding.
* vo_vdpau: use color close to black as default colorkey (instead of green)wm42013-08-171-1/+4
| | | | | | | | | | | | | | | | | | The VDPAU default colorkey, although it seems to be driver specific, is usually green. This is a pretty annoying color, and you usually see it briefly (as flashes) if the VDPAU window resizes. Change it to some shade of black. The new default color is close to what MPlayer picks as colorkey (and apparently it worked well for them): VdpColor vdp_bg = {0.01, 0.02, 0.03, 0}; Since our OPT_COLOR can set 8 bit colors only, we use '#020507' instead, which should be the same assuming 8 bit colors. Obviously, you can't use black, because black is a way too common color, and would make it too easy to observe the colorkey effect when e.g. moving a terminal with black background over the video window.
* vo_vdpau: allow setting colorkeywm42013-08-171-0/+15
| | | | | | | Formally, this sets the "background color" of the presentation queue. But in practice, this color is also used as colorkey. This commit doesn't change the VDPAU default yet.
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-061-3/+3
| | | | Followup commit. Fixes all the files references.
* build: fix build with vdpau, simplifywm42013-07-291-1/+1
| | | | | | | | | | | | Instead of generating vdpau_template.c with a Perl script, just include the generated file in git. This is ok because it changes very rarely, and the script is larger than the output it generates. It also simplify the Makefile, and fixes the build. The problem was that transitive dependencies do not work with generated files: there is no dependency information yet when building it the first time. I overlooked this because I didn't delete the .d files for testing (which contained the correct dependencies, but only _after_ a first successful build).
* vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel APIwm42013-07-281-232/+140
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* Fix some -Wshadow warningswm42013-07-231-2/+1
| | | | | | In general, this warning can hint to actual bugs. We don't enable it yet, because it would conflict with some unmerged code, and we should check with clang too (this commit was done by testing with gcc).
* video/out: remove options argument from preinit()wm42013-07-221-1/+1
| | | | | All VOs use proper option parsing now, and compatibility hacks are not needed.
* video: remove fullscreen flags chaoswm42013-07-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Replace all calls to GetTimer()/GetTimerMS()wm42013-05-261-13/+13
| | | | | | | | | | | | | | | | | | | | | | 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.
* x11: use vo_x11_control() for all VOswm42013-05-261-30/+11
|
* video: remove aspect.h includes from files which don't need itwm42013-03-171-1/+0
|
* vo: Separate vo options from MPOptsAlexander Preisinger2013-03-041-1/+1
| | | | | | | 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
* vo: remove and cleanup globalsAlexander Preisinger2013-03-041-1/+4
| | | | | | | | 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.
* m_option: don't define OPT_BASE_STRUCT by defaultwm42013-03-011-1/+0
| | | | | | | | | | | OPT_BASE_STRUCT defines which struct the OPT_ macros (like OPT_INT etc.) reference implicitly, since these macros take struct member names but no struct type. Normally, only cfg-mplayer.h should need this, and other places shouldn't be bothered with having to #undef it. (Some files, like demux_lavf.c, still store their options in MPOpts. In the long term, this should be removed, and handled like e.g. with VO suboptions instead.)
* 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.)
* video/out: rename create_window to config_windowwm42013-02-261-1/+1
| | | | | | create_window is really bad naming, because this function can be called multiple times, while the name implies that it always creates a new window. At least the name config_window is not actively misleading.
* cleanup: replace OPT_FLAG_ON and OPT_MAKE_FLAGS with OPT_FLAGwm42013-02-091-3/+3
| | | | | | | | | | OPT_MAKE_FLAGS() used to emit two options (one with "no" prefixed), but that has been long removed by special casing flag options in the option parser. OPT_FLAG_ON() used to imply that there's no "no-" prefixed option, but this hasn't been the case for a while either. (Conceptually, it has been replaced by OPT_FLAG_STORE().) Remove OPT_FLAG_OFF, which was unused.
* options: change handling of "no-" optionswm42013-02-091-1/+0
| | | | | | | | | | | | | | | | Normally, all flag options can be negated by prepending a "no-", for example "--no-opt" becomes "--opt=no". Some flag options can't actually be negated, so add a CONF_TYPE_STORE option type to disallow the "no-" fallback. Do the same for choice options. Remove the explicit "no-" prefixed options, add "no" as choice. Move the handling of automatic "no-" options from parser-mpcmd.c to m_config.c, and use it in m_config_set_option/m_config_parse_option. This makes these options available in the config file. It also simplifies sub-option parsing, because it doesn't need to handle "no-" anymore.
* x11: simplify handling of X Visuals and Colormaps in VOswm42013-01-271-19/+2
| | | | | | | | | | | | | | | | | Don't force VOs to pick an arbitrary default Visual and Colormap. They still can override them if needed. This simplifies the X11 VO interface. Always create a Colormap for simplicity. Using CopyFromParent fails if the selected visual is not the same of that of the parent window, which happens for me with vo_opengl. vo_vdpau and vo_xv explicitly set CWBorderPixel, do that in x11_common instead (it was already done for native windows, but not for slave mode windows). What gl_common did was incorrect in theory: freeing a colormap while a window uses it will change the colormap of the window to "None", and the color mapping for such windows is "undefined".
* x11: reduce VO mode switching code duplicationwm42013-01-271-29/+1
| | | | | | | | | | | | | | Some parts for initiating mode switches were duplicated in every VO supporting X11 (except vo_opengl/gl_common, which didn't support mode switching). Move this to x11_common.c. Note that this might be slightly risky: is it really guaranteed that no VO needed to do "special" setup that depends on X parameters changing after a mode switch, such as bit depth, visuals etc.? From what I can see, this shouldn't be the case (X probably can't even change depth on the fly). Even if this should be a one-way road, VM switching is in general very useless, and its implementation buggy, so it can just be removed should unfixable problems arise.
* x11: cleanup, refactorwm42013-01-271-2/+2
| | | | | | | | | | | | | | | | Move things that are used by vo_xv only into vo_xv, same for vo_x11. Rename some functions exported by x11_common, like vo_init to vo_x11_common. Make functions not used outsode of x11_common.c private to that file. Eliminate all global variables defined by x11_common (except error handler and colormap stuff). There shouldn't be any functional changes, and only code is moved around. There are some minor simplifications in the X11 init code, as we completely remove the ability to initialize X11 and X11+VO separately (see commit b4d9647 "mplayer: do not create X11 state in player frontend"), and the respective functions are conflated into vo_x11_init() and vo_x11_uninit().
* vo_vdpau: always try to native bit depth (makes 30 bit work)wm42013-01-231-5/+2
| | | | | | | | | | | | | Using vdpau on an X server configured to a bit depth of 30 (10 bit per component) failed finding a visual. The cause was a hack that tried to normalize the bit depth to 24 if it was not a known depth. It's unknown why/if this is needed, but the following things speak against it: - it prevented unusual bit depths like 30 bit from working - it wasn't needed with normal bit depth like 24 bit - it's probably copy-pasted from vo_x11 (where this code possibly makes sense, unlike in vo_vdpau) Just remove this code and look for a visual with native depth.
* video: decouple internal pixel formats from FourCCswm42013-01-131-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/filter: change filter API, use refcounting, remove filter DRwm42013-01-131-24/+37
| | | | | | | | | | | | | | | | | | | | 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.
* mp_image: require using mp_image_set_size() for setting w/hwm42013-01-131-4/+2
| | | | | | | | | | | | | | Setting the size of a mp_image must be done with mp_image_set_size() now. Do this to guarantee that the redundant fields (like chroma_width) are updated consistently. Replacing the redundant fields by function calls would probably be better, but there are too many uses of them, and is a bit less convenient. Most code actually called mp_image_setfmt(), which did this as well. This commit just makes things a bit more explicit. Warning: the video filter chain still sets up mp_images manually, and vf_get_image() is not updated.
* video: make vdpau hardware decoding not use DR code pathwm42013-01-131-14/+5
| | | | | | 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-7/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Slices allowed filtering or drawing video in horizontal bands or blocks. This allowed working on the video in smaller units. In theory, this could bring a performance win by lowering cache pressure, as you didn't have to keep the whole video frame in cache while filtering, only the slice. In practice, the slice code path was barely used for the following reasons: - Multithreaded decoding with ffmpeg didn't use slices. The ffmpeg slice callback was disabled, because it can be called from another thread, and the mplayer video chain is not thread-safe. - There was nothing that would turn "full" images into appropriate slices, so slices were rarely used. - Most filters didn't actually support slices. On the other hand, supporting slices lead to code duplication and more complex code in general. I made some experiments and didn't find any actual measurable performance improvements when using slices. Even ffmpeg removed slices based filtering from libavfilter in favor of simpler code. The most broken thing about the slices code path is that slices can't be queued, like it is done for images in vo.c.
* video: make vdpau hardware decoding not use slices code pathwm42013-01-131-4/+4
| | | | | | | | | | | | | | For some reason, libavcodec abuses the slices rendering code path for hardware decoding: in that case, the only purpose of the draw callback is to pass a vdpau video surface object to video output. (It is unclear to me why this had to use the slices code, instead of just returning an AVFrame with the required vdpau state.) Make this code separate within mpv, so that the internal slices code path is not used for hardware decoding. Pass the vdpau state with VOCTRL_HWDEC_DECODER_RENDER instead. Remove the mencoder specific VOCTRLs.
* video/out: replace VOCTRL_QUERY_FORMAT with vo_driver.query_formatwm42013-01-131-3/+2
|
* video/out: make draw_image mandatory, remove VOCTRL_DRAW_IMAGEwm42013-01-131-4/+1
| | | | | | | | | | | | | Remove VOCTRL_DRAW_IMAGE and always set vo_driver.draw_image in VOs. Make draw_image mandatory: change some VOs (like vo_x11) to support it, and remove the image-to-slices fallback in vf_vo. Remove vo_driver.is_new. This member indicated whether draw_image is supported unconditionally, which is now always the case. draw_image_pts is a hack until the video filter chain is changed to include the PTS as field in mp_image. Then vo_vdpau and vo_lavc will be changed to use draw_image.
* vdpau: silence a clang warningRudolf Polzer2012-12-281-1/+2
| | | | It's just some braces...
* options, vo_x11: remove -zoom option, make it defaultwm42012-11-161-2/+1
| | | | | | | | | | | | | | T