summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vo_opengl: support rotationwm42014-04-212-15/+48
| | | | | | | | | | | This turned out much more complicated than I thought. It's not just a matter of adjusting the texture coordinates, but you also have to consider separated scaling and panscan clipping, which make everything complicated. This actually still doesn't clip 100% correctly, but the bug is only visible when rotating (or flipping with --vf=flip), and using something like --video-pan-x/y at the same time.
* vo: add some general support code for VOs that allow rotationwm42014-04-214-12/+30
| | | | | | 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.
* vo_opengl: clean up rendering pathwm42014-04-211-76/+94
| | | | | Shuffle the special cases around so that it looks cleaner. The result should be equivalent to the code before.
* demux: export video rotation parameterwm42014-04-211-0/+1
| | | | | Now the rotation hint is propagated everywhere. It just isn't used anywhere yet.
* mp_image: add rotation parameterwm42014-04-212-1/+4
|
* video: make mp_image use mp_image_params directlywm42014-04-215-69/+37
| | | | | Minor cleanup, so that we can stuff more information into mp_image_params later.
* vf_rotate: support all multiples of 90 degreeswm42014-04-212-92/+23
| | | | | | | | | | | | | This couldn't rotate by 180°. Add this, and also make the parameter in degrees, instead of magic numbers. For now, drop the flipping stuff. You can still flip with --vf=flip or --vf=mirror. Drop the landscape/portrait stuff - I think this is something almost nobody will use. If it turns out that we need some of these things, they can be readded later. Make it use libavfilter. Its vf_transpose implementation looks pretty simple, except that it uses slice threading and should be much faster.
* Fix some libav* include statementswm42014-04-196-13/+13
| | | | | | | | | | | | | Fix all include statements of the form: #include "libav.../..." These come from MPlayer times, when FFmpeg was somehow part of the MPlayer build tree, and this form was needed to prefer the local files over system FFmpeg. In some cases, the include statement wasn't needed or could be replaced with mpv defined symbols.
* Remove CPU detection and inline asm handlingwm42014-04-191-2/+5
| | | | | | | | | | | | | | Not needed anymore. I'm not opposed to having asm, but inline asm is too much of a pain, and it was planned long ago to eventually get rid fo all inline asm uses. For the note, the inline asm use that was removed with the previous commits was almost worthless. It was confined to video filters, and most video filtering is now done with libavfilter. Some mpv filters (like vf_pullup) actually redirect to libavfilter if possible. If asm is added in the future, it should happen in the form of external files.
* vf_pp: fix include statementwm42014-04-191-1/+1
|
* vf_pp: use native libpostproc CPU detectionwm42014-04-191-5/+1
|
* vf_divtc: remove inline asmwm42014-04-191-50/+0
| | | | | | Becomes a bit slower (tested with progressive solid color video only), but this filter is pretty obscure and I'm not even sure what it's useful for.
* vf_pullup: remove inline asmwm42014-04-193-218/+0
| | | | | | No change in speed (or even slightly faster, though I tested with progressive solid color video only), and normally we use libavformat's vf_pullup anyway.
* vf_noise: remove line asmwm42014-04-191-130/+4
| | | | | | | | I didn't test the speed, but by default, this filter diverts to libavfilter already. So this would help only if libavfilter is disabled, or libavfilter doesn't have vf_noise (like on Libav). For these cases, we still provide the (possibly but not necessarily) slower C implementation of vf_noise.
* vf_ilpack: remove inline asmwm42014-04-191-277/+4
| | | | | | | | This makes it multiple times slower. However, the output format (packed YUV) isn't handled efficiently by anything to begin with, and I have no clue we even have this filter. I guess it's one of these filters which find some use sometimes, but are not of higher importance, which justifies removing the faster inline asm.
* vf_eq: remove slow inline asmwm42014-04-191-75/+0
| | | | | Compiled with -O2, the C code runs just as far (or even slightly faster) then the MMX inline asm.
* w32_common: use ToUnicode to translate key inputJames Ross-Gowan2014-04-172-50/+184
| | | | | | | | | | | | | | | | This replaces translate_key_input with a solution that gives mpv more control over how keyboard input is converted to unicode. As a result: - Key up/down events are generated the same way for all keys. - Dead keys generate their base character instead of being combined with the following character. - Many Ctrl and Ctrl+Alt key combinations that were previously broken are fixed, since it's possible to discover the base keys. - AltGr doesn't produce special characters when mp_input_use_alt_gr is false. This also fixes some logic to do with detecting AltGr and adds proper UTF-16 decoding.
* vo_opengl: make spline36 default with --vo=opengl-hqwm42014-04-171-1/+1
|
* player: add a --dump-stats optionwm42014-04-171-1/+3
| | | | | | | | | | | | | | | | | | | | | | | This collects statistics and other things. The option dumps raw data into a file. A script to visualize this data is included too. Litter some of the player code with calls that generate these statistics. In general, this will be helpful to debug timing dependent issues, such as A/V sync problems. Normally, one could argue that this is the task of a real profiler, but then we'd have a hard time to include extra information like audio/video PTS differences. We could also just hardcode all statistics collection and processing in the player code, but then we'd end up with something like mplayer's status line, which was cluttered and required a centralized approach (i.e. getting the data to the status line; so it was all in mplayer.c). Some players can visualize such statistics on OSD, but that sounds even more complicated. So the approach added with this commit sounds sensible. The stats-conv.py script is rather primitive at the moment and its output is semi-ugly. It uses matplotlib, so it could probably be extended to do a lot, so it's not a dead-end.
* wayland: unset input regions for osdAlexander Preisinger2014-04-161-0/+4
| | | | | Set a zero sized input region for the osd surfaces in order to avoid getting input for the subsurfaces which might dissapear any time.
* wayland/shm: Use subsurfaces for OSDAlexander Preisinger2014-04-164-29/+133
|
* video: remove use of deprecated AVFrame fields on Libavwm42014-04-151-4/+0
| | | | | | qscale export has been completely removed from Libav 10, and FFmpeg has an alternative API, so this code does nothing and only causes deprecation warnings on Libav.
* vf_vapoursynth: handle destruction more gracefullywm42014-04-141-7/+8
| | | | | | | | | | | | | | We were relying on vsscript_freeScript() to take care of proper termination. But it doesn't do that: it doesn't wait for the filters to finish and exit at all. Instead, it just destroys all objects, which causes the worker threads to crash sometimes. Also, we're supposed to wait for the frame callback to finish before freeing the associated node. Handle this by explicitly waiting as far as we can. Probably fixes crashes on seeking, although VapourSynth itself might also need some work to make this case completely stable.
* video: change image format names, prefer mostly FFmpeg nameswm42014-04-142-89/+60
| | | | | | | | | | | | | | | The most user visible change is that "420p" is now displayed as "yuv420p". This is what FFmpeg uses (almost), and is also less confusing since "420p" is often confused with "420 pixels vertical resolution". In general, we return the FFmpeg pixel format name. We still use our own old mechanism to keep a list of exceptions to provide compatibility for a while. Also, never return NULL for image format names. If the format is unset (0/IMGFMT_NONE), return "none". If the format has no name (probably never happens, FFmpeg seems to guarantee that a name is set), return "unknown".
* vf_vapoursynth: wipe vapoursynth state completely on reloadingwm42014-04-141-40/+55
| | | | | | | | Before this commit, the filter attempted to keep the vsscript state (p->se) even when the script was reloaded. Change it to destroy the script state too on reloading. Now no workaround for LoadPlugin is necessary, and this also fixes a weird theoretical race condition when destroying and recreating the mpv source filter.
* Kill all tabswm42014-04-1315-1372/+1372
| | | | | | | | | | | I hate tabs. This replaces all tabs in all source files with spaces. The only exception is old-makefile. The replacement was made by running the GNU coreutils "expand" command on every file. Since the replacement was automatic, it's possible that some formatting was destroyed (but perhaps only if it was assuming that the end of a tab does not correspond to aligning the end to multiples of 8 spaces).
* vf_lavfi: copy AVFrame metadata into vf_lavfi privKevin Mitchell2014-04-132-0/+21
| | | | | | | | store it as mp_tas and add VFCTRL_GET_METADATA to access it from elsewhere Signed-off-by: wm4 <wm4@nowhere> old-configure test by wm4.
* vf_lavfi: fix ffmpeg deprecation warning for avfilter_graph_parseKevin Mitchell2014-04-131-1/+1
| | | | use avfilter_graph_parse_ptr for ffmpeg
* vf: auto-label video filters if no label is specifiedKevin Mitchell2014-04-131-1/+12
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vf: add vf_control_by_label to send vfctrl to specific filterKevin Mitchell2014-04-132-0/+12
|
* wayland: don't schedule resize if going fullscreenRicardo Vieira2014-04-131-1/+0
| | | | mpv was resizing to the same size before it went to fullscreen, we don't need to schedule a resize because the compositor will send a configure event with the new dimensions and thats when we should do it.
* vf_vapoursynth: print an error if VapourSynth returns an unknown formatwm42014-04-131-0/+1
| | | | | Apparently there is no real format negotiation, so this can actually happen.
* vf_vapoursynth: error out early if the file sub-option is not setwm42014-04-131-0/+4
| | | | Instead of crashing by possibly passing a NULL pointer to VapourSynth.
* video: add VapourSynth filter bridgewm42014-04-122-0/+480
| | | | | | | | | | | | Mainly meant to apply simple VapourSynth filters to video at runtime. This has various restrictions, which are listed in the manpage. Additionally, this actually copies video frames when converting frame references from mpv to VapourSynth, and a second time when going from VapourSynth to mpv. This is inefficient and could probably be easily improved. But for now, this is simpler, and in fact I'm not sure if we even can references VapourSynth frames after the core has been destroyed.
* encode: write 2-pass stats only per-packetwm42014-04-111-1/+2
| | | | | | The stats were retrieved and written on every encode call, instead of every encode call that actually returned a packet. ffmpeg.c also does it this way, so it must be "more correct". Fixes 2-pass encoding.
* sws_utils: remove custom GBRP conversionwm42014-04-101-48/+0
| | | | | | | We needed this because the OSD rendering path used GBRP for RGB rendering, and not all swscale versions supported this conversion. But recently we've dropped support for very old ffmpeg/libav versions, so this isn't needed anymore.
* vo_vdpau: add an additional check for timestamp robustnesswm42014-04-081-0/+16
| | | | | | | | | | This might be a good idea in order to prevent queuing a frame too far in the future (causing apparent freezing of the video display), or dropping an infinite number of frames (also apparent as freezing). I think at this point this is most of what we can do if the vdpau time source is unreliable (like with Mesa). There are still inherent race conditions which can't be fixed.
* vo_vdpau: document what WRAP_ADD doeswm42014-04-081-0/+2
| | | | This wasn't necessarily clear.
* vo_vdpau: simplify previous vsync timestamp calculationwm42014-04-081-9/+8
| | | | | | | | | | | | | | | | | | | | | | | | The strange thing about this code was the shift parameter of the prev_vs2 function. The parameter is used to handle timestamps before the last vsync, since the % operator handles negative values incorrectly. Most callers set shift to 0, and _usually_ pass a timestamp after the last vsync. One caller sets it to 16, and can pass a timestamp before the last timestamp. The mystery is why prev_vs2 doesn't just compensate for the % operator semantics in the most simple way: if the result of the operator is negative, add the divisor to it. Instead, it adds a huge value to it (how huge is influenced by shift). If shift is 0, the result of the function will not be aligned to vsyncs. I have no idea why it was written in this way. Were there concerns about certain numeric overflows that could happen in the calculations? But I can't think of any (the difference between ts and vc->recent_vsync_time is usually not that huge). Or is there something more clever about it, which is important for the timing code? I can't think of anything either. So scrap it and simplify it.
* vo_vdpau: simplify time management and make it more robustwm42014-04-071-68/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | vo_vdpau used a somewhat complicated and fragile mechanism to convert the vdpau time to internal mpv time. This was fragile as in it couldn't deal well with Mesa's (apparently) random timestamps, which can change the base offset in multiple situations. It can happen when moving the mpv window to a different screen, and somehow it also happens when pausing the player. It seems this mechanism to synchronize the vdpau time is not actually needed. There are only 2 places where sync_vdptime() is used (i.e. returning the current vdpau time interpolated by system time). The first call is for determining the PTS used to queue a frame. This also uses convert_to_vdptime(). It's easily replaced by querying the time directly, and adding the wait time to it (rel_pts_ns in the patch). The second call is pretty odd: it updates the vdpau time a second time in the same function. From what I can see, this can matter only if update_presentation_queue_status() is very slow. I'm not sure what to make out of this, because the call merely queries the presentation queue. Just assume it isn't slow, and that we don't have to update the time. Another potential issue with this is that we call VdpPresentationQueueGetTime() every frame now, instead of every 5 seconds and interpolating the other calls via system time. More over, this is per video frame (which can be portantially dropped, and not per actually displayed frame. Assume this doesn't matter. This simplifies the code, and should make it more robust on Mesa. But note that what Mesa does is obviously insane - this is one situation where you really need a stable time source. There are still plenty of race condition windows where things can go wrong, although this commit should drastically reduce the possibility of this. In my tests, everything worked well. But I have no access to a Mesa system with vdpau, so it needs testing by others. See github issues #520, #694, #695.
* gl_lcms: properly expand the cache filename being writtenStefano Pigozzi2014-04-051-1/+3
| | | | | This is needed to preserve the same path used when opening the cache file, and correctly expands ~ when icc-cache is added to the mpv config file.
* vo_vdpau: more debugging outputwm42014-04-031-4/+20
| | | | Might help to debug certain problems with Mesa.
* gl_lcms: fix build when lcms2 is not availableStefano Pigozzi2014-03-311-0/+5
| | | | Was broken in b0ee9334e.
* vo_corevideo: remove unused variableStefano Pigozzi2014-03-311-1/+0
|
* vo_opengl, cocoa: allow to autoselect a color profileStefano Pigozzi2014-03-317-2/+219
| | | | | | | | | | | | | This commit adds support for automatic selection of color profiles based on the display where mpv is initialized, and automatically changes the color profile when display is changed or the profile itself is changed from System Preferences. @UliZappe was responsible with the testing and implementation of a lot of this commit, including the original implementation of `cocoa_get_icc_profile_path` (See #594). Fixes #594
* vf_eq: don't malloc priv structwm42014-03-301-1/+0
| | | | | There wasn't any reason for this. In fact, it's a memory leak. The proper priv struct is already allocated vf.c and the option parser.
* Fix compilation on OSX and win32wm42014-03-292-2/+1
| | | | Probably.
* video/out: remove legacy colorspace stuffwm42014-03-2912-135/+106
| | | | | | | | | 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.
* mp_image: add missing field to mp_image_params_equals()wm42014-03-281-0/+1
| | | | | | This is pretty obscure, so it didn't matter much. It still breaks switching output levels at runtime, because the video output is not reinitialized with the new params.
* vo_opengl: runtime icc profile switchingwm42014-03-242-19/+40
| | | | | The changes in vo_opengl.c are merely for adding the icc options to the set of options than can be changed with the vo_cmdline command.
* x11_common: fix some problems with window draggingwm42014-03-221-1/+2
| | | | | | | | | | | | | | | | There were some bad interactions with the OSC. For one, dragging the OSC bar, and then moving the mouse outside of the OSC (while mouse button still held) would suddenly initiate window dragging. This was because win_drag_button1_down was not reset when sending a normal mouse event, which means the window dragging code can become active even after we've basically decided that the preceding click didn't initiate window dragging. Second, dragging the window and clicking on the OSC bar after that did nothing. This was because no mouse button up event was sent to the core, even though a mouse down event was sent. So make sure the key state is erased with MP_INPUT_RELEASE_ALL.
* vdpau: remove pointer indirection for a fieldwm42014-03-195-14/+13
| | | | There's no reason to. This is basically a cosmetic change.
* vdpau: fix decoder init return valuewm42014-03-191-3/+3
|
* x11: implement window dragging by grabbingwm42014-03-182-1/+37
| | | | | | | | | | | | | | | | | | We don't check whether the WM supports _NET_WM_MOVERESIZE_MOVE, but if it doesn't, nothing bad happens. There might be a race condition when pressing a button, and then moving the mouse and releasing the button at the same time; then the WM might get the message to initiate moving the window after the mouse button has been released, in which case the result will probably be annoying. This could possibly be fixed by sending _NET_WM_MOVERESIZE_CANCEL on button release, but on the other hand, we probably won't receive a button release event in this situation, so ignore this problem. The dragging is initiated only when moving the mouse pointer after a click in order to reduce annoying behavior when the user is e.g. doubleclicking. Closes #608.
* vaapi: solve potential problem with ambiguous image formatswm42014-03-171-32/+27
| | | | | | | | | | | | | VAAPI has some ambiguous image formats, like VA_FOURCC_I420, VA_FOURCC_IYUV, VA_FOURCC_YV12 (the latter exactly the same as the first two, just with swapped planes). There is potentially a problem when one specific VAAPI format was picked, and converting it to a mpv format and back to a VAAPI FourCC would result in a numerically different format (even if it's actually the same). Then it could e.g. happen that functions like va_surface_upload() reallocate the underlying VAImage, which would be inefficient. Change the code so that this can't happen. (Probably not a problem in practice with the current VAAPI usage.)
* vaapi: simplifywm42014-03-171-67/+60
| | | | Merge va_surface_priv into va_surface.
* vaapi: make struct va_surface privatewm42014-03-176-90/+78
| | | | | | It's not really needed to be public. Other code can just use mp_image. The only disadvantage is that the other code needs to call an accessor to get the VASurfaceID.
* vaapi: replace image pool implementation with mp_image_poolwm42014-03-175-241/+152
| | | | | | | | | | | | Although I at first thought it would be better to have a separate implementation for hwaccels because the difference to software images are too large, it turns out you can actually save some code with it. Note that the old implementation had a small memory management bug. This got painted over in commit 269c1e1, but is hereby solved properly. Also note that I couldn't test vf_vavpp.c (due to lack of hardware), and I hope I didn't accidentally break it.
* mp_image_pool: add features needed for use with hwaccelwm42014-03-172-18/+69
| | | | | | | | | | | | | | The plan is to get rid of the custom VAAPI and possibly VDPAU surface allocators. Add custom surface allocation, because hwaccel surfaces are allocated completely differently from software surfaces. Add optional LRU allocation, which is (probably) helpful for hwaccel, but (probably) less optimal for software surfaces. mp_image_pool_get_no_alloc() is specifically for VAAPI, which can't allocate new decoder surfaces after decoder init.
* vdpau: remove legacy pixel formatswm4