summaryrefslogtreecommitdiffstats
path: root/video/out/vo.c
Commit message (Collapse)AuthorAgeFilesLines
* vdpau: don't upload video images in advancewm42014-07-291-6/+0
| | | | | | | | | | | | With software decoding, images were uploaded to vdpau surfaces as they were queued to the VO. This makes it slightly more complicated (especially later on), and has no advantages - so stop doing it. The only reason why this was done explicitly was due to attempts to keep the code equivalent (instead of risking performance regressions). The original code did this naturally for certain reasons, but now that we can measure that it has no advantages and just requires extra code, we can just drop it.
* vo: remove vo_mouse_movement() wrapperwm42014-07-271-14/+0
| | | | So that VO backends don't have to access the VO just for that.
* vo: different hack for VOs which need to mangle mouse inputwm42014-07-271-4/+2
| | | | | | | | Follow up on commit 760548da. Mouse handling is a bit confusing, because there are at least 3 coordinate systems associated with it, and it should be cleaned up. But that is hard, so just apply a hack which gets the currently-annoying issue (VO backends needing access to the VO) out of the way.
* vo: hack to avoid threading issues with mouse inputwm42014-07-261-1/+2
| | | | | | VO backends which are or will run in their own thread have a problem with vo_mouse_movement() calling vo_control(). Restrict this to VOs which actually need this.
* video: correct spelling: mp_image_params_equals -> mp_image_params_equalwm42014-06-171-1/+1
| | | | | The type is struct mp_image_params, so the "params" should have a "s". "equals" shouldn't, because it's plural for 2 params. Important.
* vo: make draw_image and vo_queue_image transfer image ownershipwm42014-06-171-3/+2
| | | | Basically a cosmetic change. This is probably more intuitive.
* video: introduce failure path for image allocationswm42014-06-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, failure to allocate image data resulted in a crash (i.e. abort() was called). This was intentional, because it's pretty silly to degrade playback, and in almost all situations, the OOM will probably kill you anyway. (And then there's the standard Linux overcommit behavior, which also will kill you at some point.) But I changed my opinion, so here we go. This change does not affect _all_ memory allocations, just image data. Now in most failure cases, the output will just be skipped. For video filters, this coincidentally means that failure is treated as EOF (because the playback core assumes EOF if nothing comes out of the video filter chain). In other situations, output might be in some way degraded, like skipping frames, not scaling OSD, and such. Functions whose return values changed semantics: mp_image_alloc mp_image_new_copy mp_image_new_ref mp_image_make_writeable mp_image_setrefp mp_image_to_av_frame_and_unref mp_image_from_av_frame mp_image_new_external_ref mp_image_new_custom_ref mp_image_pool_make_writeable mp_image_pool_get mp_image_pool_new_copy mp_vdpau_mixed_frame_create vf_alloc_out_image vf_make_out_image_writeable glGetWindowScreenshot
* video/out: change aspects of OSD handlingwm42014-06-151-18/+12
| | | | | | | | | Let the VOs draw the OSD on their own, instead of making OSD drawing a separate VO driver call. Further, let it be the VOs responsibility to request subtitles with the correct PTS. We also basically allow the VO to request OSD/subtitles at any time. OSX changes untested.
* Add more constwm42014-06-111-18/+18
| | | | | | | While I'm not very fond of "const", it's important for declarations (it decides whether a symbol is emitted in a read-only or read/write section). Fix all these cases, so we have writeable global data only when we really need.
* video: fix another cover art corner casewm42014-06-091-1/+1
| | | | | | | Playing a video and then an audio file with cover art kept displaying the last frame of the video. This was because the hasframe flag was set, perhaps due to redrawing the last video frame before the cover art image is decoded.
* vo: correctly initialize parameters in corner caseswm42014-06-011-1/+4
|
* vo: minor simplificationswm42014-05-221-11/+3
|
* vo: remove config_ok check from vo_check_events()wm42014-05-221-3/+1
| | | | This should be ok now after the x11 code was adjusted.
* player: remove VO from seeking code pathwm42014-05-071-5/+0
| | | | | | | | | | | | | | | Until recently, the VO was an unavoidable part of the seeking code path. This was because vdpau deinterlacing could double the framerate, and hr- seek and framestepping etc. all had to "see" the additional frames. But we've removed the frame doubling from the vdpau VO and moved it into a video filter (vf_vdpaupp), and there's no reason left why the VO should participate in seeking. Instead of queuing frames to the VO during seek and skipping them afterwards, drop the frames early. This actually might make seeking with vo_vdpau and software decoding faster, although I haven't measured it.
* vo: remove old stuffwm42014-05-061-16/+0
|
* video/out: separate out code to compute window sizewm42014-05-061-85/+18
| | | | | | | | | | | | | | | | | | | Currently, vo_reconfig() calculates the requested window size and sets the vo->dwidth/dheight fields _if_ VOCTRL_UPDATE_SCREENINFO is implemented by the VO or the windowing backend. The window size can be different from the display size if e.g. the --geometry option is used. It will also set the vo->dx/dy fields and read vo->xinerama_x/y. It turned out that this is very backwards and actually requires the windowing backends to workaround these things. There's also MPOpts.screenwidth/screenheight, which used to map to actual options, but is now used only to communicate the screen size to the vo.c code calculating the window size and position. Change this by making the window geometry calculations available as separate functions. This commit doesn't change any VO code yet, and just emulates the old way using the new functions. VO code will remove its usage of VOCTRL_UPDATE_SCREENINFO and use the new functions directly.
* vo: fix previous commitwm42014-05-061-1/+1
| | | | | | Commit 433161 actually broke vo_opengl (and maybe others), because config_ok is not necessarily set correctly yet _during_ reconfig. So a vo_get_src_dst_rects() call during reconfig did nothing.
* vo: don't crash when changing panscan before first configurationwm42014-05-061-0/+2
| | | | | | | | | | When the VO was not initialized with vo_reconfig(), or if the last vo_reconfig() failed, changing panscan would cause a crash due to vo_get_src_dst_rects() dereferencing vo->params (NULL if not configured). Just do nothing if that happens, as there is no video that could be displayed anyway.
* vo: get rid of config_count fieldwm42014-05-061-1/+0
| | | | | | | | Doesn't really seem to be much of use. Get rid of the remaining uses of it. Concerning vo_opengl_old, it seems uninitGl() works fine even if called before initialization.
* video: change everythingwm42014-05-021-30/+28
| | | | | | | Change how the video decoding loop works. The structure should now be a bit easier to follow. The interactions on format changes are (probably) simpler. This also aligns the decoding loop with future planned changes, such as moving various things to separate threads.
* vo: verify format of queued imagewm42014-05-021-0/+1
| | | | | Currently, only the configured format is accepted, so assert that the playback core code (which handles format changes) is correct.
* video: move video frame queue from vo_vdpau.c to vo.cwm42014-05-021-38/+57
| | | | | | | | | | | | | | | | | | | | | Remove the special casing of vo_vdpau vs. other VOs. Replace the complicated interaction between vo.c and vo_vdpau.c with a simple queue in vo.c. VOs other than vdpau are handled by setting the length of the queue to 1 (this is essentially what waiting_mpi was). Note that vo_vdpau.c seems to have buffered only 1 or 2 frames into the future, while the remaining 3 or 4 frames were past frames. So the new code buffers 2 frames (vo_vdpau.c requests this queue length by setting vo->max_video_queue to 2). It should probably be investigated why vo_vdpau.c kept so many past frames. The field vo->redrawing is removed. I'm not really sure what that would be needed for; it seems pointless. Future directions include making the interface between playloop and VO simpler, as well as making rendering a frame a single operation, as opposed to the weird 3-step sequence of rendering, drawing OSD, and flipping.
* vo: do not check for events on unconfigured VOMartin Herkt2014-04-251-1/+3
| | | | fixes #741
* vo: simplify event_fd handlingwm42014-04-221-21/+13
| | | | | | Add the event FD after preinit, remove it before destroy. There's no need to do it on vo_config, and there's no need to remove the event FD when vo_config fails.
* vo: cosmetics: move around some codewm42014-04-221-134/+136
| | | | Group together related functionality.
* vo: minor cosmetic changewm42014-04-221-2/+1
|
* vo: warn if the VO doesn't support certain flagswm42014-04-221-1/+15
| | | | | | | | | Unfortunately, if a VO can't display something as intended, we can just complain to the user, and leave it at it. But it's still better than silently displaying things differently with different VOs. For now, this is used for rotation only. Other things that we should check includes colorspace and colorlevels stuff.
* vo: add some general support code for VOs that allow rotationwm42014-04-211-3/+8
| | | | | | For rotation, we assume that the source image will be rotated within the VO, so the aspect/panscan code needs to calculate its param using rotated coordinates. VOs which support rotation natively can use this.
* video/out: remove legacy colorspace stuffwm42014-03-291-10/+0
| | | | | | | | | Reduce most dependencies on struct mp_csp_details, which was a bad first attempt at dealing with colorspace stuff. Instead, consistently use mp_image_params. Code which retrieves colorspace matrices from csputils.c still uses this type, though.
* video/out: do remaining config to reconfig replacementswm42014-01-241-13/+3
| | | | | | | The main difference between the old and new callbacks is that the old callbacks required passing the window size, which is and always was very inconvenient and confusing, since the window size is already in vo->dwidth and vo->dheight.
* vo: merge get rid of vo.aspdat fieldwm42014-01-221-7/+20
| | | | | | | | | | | | Rename vo_get_src_dst_rects() to mp_get_src_dst_rects() and make it independent from the VO (it takes a comical amount of parameters now to pass all required state). Add a convenience wrapper with the name vo_get_src_dst_rects() to vo.c. Replace all aspdat and vo usages with immediate parameters. Functionally, nothing should change, except that the window size is clamped to a minimum of size 1 much earlier, and some log messages change the prefix (don't bother with vo.vo_log stuff).
* vo: move vo_get_src_dst_rects to aspect.cwm42014-01-221-128/+0
| | | | | | | The plan is to make all the code in aspect.c independent from vo.c, which should make the code easier to understand, will allow removal of vo->aspdat, and reduces the amount of code that accesses weird mutable struct vo fields.
* video/out: simplify monitor aspect handlingwm42014-01-111-3/+20
| | | | | | | | For some reason, this made all VO backends both set the screen resolution in opts->screenwidth/height, and call aspect_save_screenres(). Remove the latter. Move the code to calculate the PAR-corrected window size from aspect.c to vo.c, and make it so that the monitor PAR is recalculated when it makes sense.
* input: move files drag and drop to a new event.c fileStefano Pigozzi2014-01-041-41/+0
| | | | | event.c will be used to feed the input queue with 'global' events that don't mesh well with the usual check_events path in mpv.
* vo: dropping subtitle files on the VO window adds them as subtitle fileswm42014-01-041-11/+27
| | | | | | | Note that we don't try to be clever about detecting the files as subtitles: we just check the file extension. We could go all the way and check the files by opening them with a demuxer, but that would probably do more bad than good.
* vo: add vo_drop_files()wm42014-01-041-0/+25
| | | | Intended to be used for GUI drag & drop.
* vo_vdpau: fix unintended truncation of 64 bit timestamps to 32 bitwm42013-12-221-1/+1
| | | | | | | | How embarrassing... This code is inactive for all VOs other than vo_vdpau. For vo_vdpau, this caused various issues, such as stuttering after about an hour of running mpv; see github issue #403.
* msg: rename mp_msg_log -> mp_msgwm42013-12-211-1/+1
| | | | Same for companion functions.
* m_option, m_config: mp_msg conversionswm42013-12-211-1/+1
| | | | | | | | Always pass around mp_log contexts in the option parser code. This of course affects all users of this API as well. In stream.c, pass a mp_null_log, because we can't do it properly yet. This will be fixed later.
* input: rework how input sources are addedwm42013-12-211-2/+2
| | | | | | | | | | | | | | Until now, there were two functions to add input sources (stuff like stdin input, slave mode, lirc, joystick). Unify them to a single function (mp_input_add_fd()), and make sure the associated callbacks always have a context parameter. Change the lirc and joystick code such that they take store their state in a context struct (probably worthless), and use the new mp_msg replacements (the point of this refactoring). Additionally, get rid of the ugly USE_FD0_CMD_SELECT etc. ifdeffery in the terminal handling code.
* video/out: pass along global contextwm42013-12-211-0/+1
| | | | Will be needed for other parts (especially in gl_lcms.c).
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-171-3/+3
|
* Move options/config related files from mpvcore/ to options/wm42013-12-171-2/+2
| | | | | | | | | Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
* Move mpvcore/input/ to input/wm42013-12-171-1/+1
|
* video: change --video-zoom behaviorwm42013-12-131-3/+5
| | | | | | | | | | | Use the scaled video size (i.e. as shown on the window) as reference for zoom. This is the easiest way to fix different width/height scale factors as they happen when zooming video with a pixel aspect ratio other than 1:1. Also fix the unscaled mode, so that it 1. doesn't scale even with --video-zoom, and 2. doesn't scale by small amounts when the video is cropped by making the window smaller than the video.
* vo: reset some fields properlywm42013-12-101-0/+6
| | | | | | Otherwise, next_pts2 can be == next_pts (and not MP_NOPTS_VALUE), in which case the player thinks the first frame has duration 0. (Weird corner case.)
* options: add options that set defaults for af/vf/ao/vowm42013-12-011-0/+2
| | | | | | | | There are some use cases for this. For example, you can use it to set defaults of automatically inserted filters (like af_lavrresample). It's also useful if you have a non-trivial VO configuration, and want to use --vo to quickly change between the drivers without repeating the whole configuration in the --vo argument.
* osd: remove mp_osd_res.video_par fieldwm42013-11-241-1/+0
| | | | | | This is not needed anymore, because we decided that the PAR of the decoded video matters, and not the PAR of the filtered video that arrives at the VO.
* Rename sub.c/.h to osd.c/.hwm42013-11-241-1/+1
| | | | | This was way too misleading. osd.c merely calls the subtitle renderers, instead of actually dealing with subtitles.
* configure: uniform the defines to #define HAVE_xxx (0|1)Stefano Pigozzi2013-11-031-13/+13
| | | | | | | | | | | | | | | | | | | | | 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
* m_config: refactor option defaults handlingwm42013-10-241-1/+0
| | | | | | | | | | | | | Keep track of the default values directly, instead of creating a new instance of the option struct just to get the defaults. Also get rid of the special handling of m_obj_desc.init_options. Instead, handle it purely by the option parser. Originally, I wanted to handle --vo=opengl-hq and --vo=direct3d_shaders with this (by making them aliases to the real VOs with a different preset), but since --vo =opengl-hq=help prints the wrong values (as consequence of the simplification), I'm not doing that, and instead use something different.
* video/out: remove useless info struct and redundant fieldswm42013-10-231-3/+3
| | | | The author and comment fields were printed only in -v mode.
* mp_msg: remove gettext() supportwm42013-10-181-1/+1
| | | | | | | | | Was disabled by default, was never used, internal support was inconsistent and poor, and there has been virtually no interest in creating translations. And I don't even think that a terminal program should be translated. This is something for (hypothetical) GUIs.
* vo: mark frame lost after seek resetwm42013-10-021-0/+1
| | | | | | | Reverts a small change made in commit ed9295c. This is needed, because otherwise mplayer.c/update_video_attached_pic() thinks it never has to update the picture after initialization. (Maybe there would be more elegant ways to handle this, but not without adding extra state.)
* core: add --force-windowwm42013-10-021-0/+5
| | | | | | | | | | | | | | | | | This commit adds the --force-window option, which will cause mpv always to create a window when started. This can be useful when pretending that mpv is a GUI application (which it isn't, but users pretend anyway), and playing audio files would run mpv in the background without giving a window to control it. This doesn't actually create the window immediately: it only does so only after initializing playback and when it is clear that there won't be any actual video. This could be a problem when starting slow or completely stuck network streams (mpv would remain frozen in the background), or if video initialization somehow is stuck forever in an in-between state (like when the decoder doesn't output a video frame, but doesn't return an error either). Well, we can pretend only so much that mpv is a GUI application.
* video/out: always support redrawing VO window at any pointwm42013-10-021-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* input: translate mouse position to OSD space earlywm42013-09-271-1/+3
| | | | | | | | | | | | | | Until now, mouse positions were just passed to the core as-is, even if the mouse coordinates didn't map to any useful coordinate space, like OSD coordinates. Lua scripting (used by the OSC, the only current user of mouse input) had to translate mouse coordinates manually to OSD space using mp_get_osd_mouse_pos(). This actually didn't work correctly in cases mouse coordinates didn't map to OSD (like vo_xv): the mouse coordinates the OSC got were correct, but input.c was still expecting "real" mosue coordinates for mouse area