summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* 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 formatswm42014-03-176-41/+10
| | | | | | They were used by ancient libavcodec versions. This also removes the need to distinguish vdpau image formats at all (since there is only one), and some code can be simplified.
* vdpau: remove unused typewm42014-03-171-6/+0
|
* video: change image format from unsigned int to int in some placeswm42014-03-176-12/+12
| | | | | | Image formats used to be FourCCs, so unsigned int was better. But now it's annoying and the only difference is that unsigned int is more to type than int.
* img_format: AV_PIX_FMT_FLAG_ALPHA is always availablewm42014-03-171-5/+0
| | | | We no more support ancient libavutil versions.
* vd_lavc: reinit hwdec on profile changeswm42014-03-172-2/+6
| | | | | Needed in theory. I don't know if there are even any real-world files which change the profile mid-stream.
* video: fix FFmpeg or Libav being a special snowflakewm42014-03-161-1/+2
|
* vd_lavc: remove unused fieldwm42014-03-162-3/+0
|
* vd_lavc: reduce hardware decoder mid-stream reinitializationswm42014-03-161-1/+6
| | | | | | | | | | Instead of doing it on every seek (libavcodec calls get_format on every seek), reinitialize the decoder only if the video resolution changes. Note that this may be relatively naive, since we e.g. (or: in particular) don't check for profile changes. But it's not worse than the state before the get_format change, and at least it paints over the current vaapi breakage (issue #646).
* encode: use new AVFrame APIwm42014-03-161-5/+3
|
* image_writer: use new AVFrame APIwm42014-03-161-3/+2
|
* vf_delogo: remove internal implementationwm42014-03-161-249/+2
| | | | See previous commit.
* vf_hqdn3d: remove internal implementationwm42014-03-161-276/+10
| | | | See previous commit.
* vf_yadif: remove internal implementationwm42014-03-161-467/+3
| | | | See previous commit.
* vf_unsharp: remove internal implementationwm42014-03-161-176/+3
| | | | See previous commit.
* vf_gradfun: remove internal implementationwm42014-03-161-339/+5
| | | | | | | This follows the (only slowly progressing) plan to replace all internal video filters with libavfilter. All what's left in vf_gradfun.c is the weird wrapper around vf_lavfi.c.
* build: simplify libavfilter configure checkswm42014-03-162-2/+2
| | | | | This is all not needed anymore. In particular, remove all configure switches except --enable-libavfilter.
* Remove some more unneeded version checkswm42014-03-161-12/+2
| | | | | All of these check against things that happened before the latest supported FFmpeg/Libav release.
* vd_lavc: remove compatibility crapwm42014-03-169-823/+29
| | | | | | | All this code was needed for compatibility with very old libavcodec versions only (such as Libav 9). Includes some now-possible simplifications too.
* vd_lavc: ridiculous workaround for Libav 9 compatibilitywm42014-03-163-1/+23
| | | | | | | | This "sometimes" crashed when seeking. The fault apparently lies in libavcodec: the decoder returns an unreferenced frame! This is completely insane, but somehow I'm apparently still expected to work this around. As a reaction, I will drop Libav 9 support in the next commit. (While this commit will go into release/0.3.)
* w32_common: prevent MOUSE_BTN0 sticking after dragJames Ross-Gowan2014-03-121-0/+2
| | | | | | The window doesn't recieve a WM_LBUTTONUP message after it's dragged, probably because it's swallowed by the modal loop. To stop the button from sticking, release it manually when the drag is complete.
* w32_common: capture mouse inputJames Ross-Gowan2014-03-121-0/+5
| | | | | | Mouse buttons can get stuck down if the button is pressed inside the video window and released outside. Avoid this by capturing mouse input when a button is pressed.
* video: initialize hw decoder in get_formatwm42014-03-104-46/+42
| | | | | | | | | | | | | | | | Apparently the "right" place to initialize the hardware decoder is in the libavcodec get_format callback. This doesn't change vda.c and vdpau_old.c, because I don't have OSX, and vdpau_old.c is probably going to be removed soon (if Libav ever manages to release Libav 10). So for now the init_decoder callback added with this commit is optional. This also means vdpau.c and vaapi.c don't have to manage and check the image parameters anymore. This change is probably needed for when libavcodec VDA supports gets a new iteration of its API.
* vo_opengl: Correct and clarify gl_check_featuresNiklas Haas2014-03-101-11/+24
| | | | | | | This updates the logic for the new, somewhat unified behavior of SRGB and 3DLUT since 34bf9be (not that it was particularly correct even that change) and checks for the presence of corresponding extensions only in the cases in which they're needed.
* vo_opengl: Simplify and clarify color correction codeNiklas Haas2014-03-105-48/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit: - Changes some of the #define and variable names for clarification and adds comments where appropriate. - Unifies :srgb and :icc-profile, making them fit into the same step of the decoding process and removing the weird interactions between both of them. - Makes :icc-profile take precedence over :srgb (to significantly reduce the number of confusing and useless special cases) - Moves BT709 decompanding (approximate or actual) to the shader in all cases, making it happen before upscaling (instead of the old 0.45 gamma function). This is the simpler and more proper way to do it. - Enables the approx gamma function to work with :srgb as well due to this (since they now share the gamma expansion code). - Renames :icc-approx-gamma to :approx-gamma since it is no longer tied to the ICC options or LittleCMS. - Uses gamma 2.4 as input space for the actual 3DLUT, this is now a pretty arbitrary factor but I picked 2.4 mainly because a higher pure power value here seems to produce visually better results with wide gamut profiles, rather then the previous 1.95 or BT.709. - Adds the input gamma space to the 3dlut cache header in case we change it more in the future, or even make it user customizable (though I don't see why the latter would really be necessary). - Fixes the OSD's gamma when using :srgb, which was previously still using the old (0.45) approximation in all cases. - Updates documentation on :srgb, it was still mentioning the old behavior from ci