summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* win32: remove ProcThreadAttributeList dynamic loadingJames Ross-Gowan2015-12-201-36/+6
| | | | | These are always available in supported Windows versions, as is the EXTENDED_STARTUPINFO_PRESENT flag.
* win32: remove SetDllDirectoryW dynamic loadingJames Ross-Gowan2015-12-201-4/+1
| | | | All Windows versions we support have this API.
* vaapi: add VP9 profile entiresBtbN2015-12-201-0/+7
|
* sd_ass: handle --sub-clear-on-seek correctly with non-ASS subswm42015-12-201-1/+3
| | | | | | Converted subtitles use a different method to avoid adding repeated packets as duplicate subtitle events. The state for this mechanism must be cleared as well if --sub-clear-on-seek is used.
* vf_vapoursynth: fix everythingwm42015-12-201-17/+13
| | | | | | | Broken by commit 0a0bb905. The changes to this filter were accidentally simply not tested, and it was obviously broken in a bunch of ways. Fixes #2616.
* demux_disc: fix aspect ratiowm42015-12-201-2/+6
| | | | | Broken by commit 0a0bb905. STREAM_CTRL_GET_ASPECT_RATIO returns a display aspect ratio, not a pixel aspect ratio.
* lavc_conv: fix invalid writewm42015-12-191-3/+2
| | | | | Well shit. Restructure it such that the returned list is always NULL- terminated with the same mechanism.
* video: switch from using display aspect to sample aspectwm42015-12-1937-215/+154
| | | | | | | | | | | | | | | | MPlayer traditionally always used the display aspect ratio, e.g. 16:9, while FFmpeg uses the sample (aka pixel) aspect ratio. Both have a bunch of advantages and disadvantages. Actually, it seems using sample aspect ratio is generally nicer. The main reason for the change is making mpv closer to how FFmpeg works in order to make life easier. It's also nice that everything uses integer fractions instead of floats now (except --video-aspect option/property). Note that there is at least 1 user-visible change: vf_dsize now does not set the display size, only the display aspect ratio. This is because the image_params d_w/d_h fields did not just set the display aspect, but also the size (except in encoding mode).
* vf: remove old config() callbackwm42015-12-199-96/+88
|
* vf: flush before reconfigwm42015-12-192-10/+1
|
* vo_opengl: disable pbo by defaults for opengl-hqwm42015-12-192-6/+7
| | | | Too many problems.
* vo_opengl: handle alpha with odd bit widths toowm42015-12-191-4/+8
| | | | | | | | | | | | | | | Since alpha isn't pulled through the colormatrix (maybe it should?), we reject alpha formats with odd sizes, such as yuva444p10. But the awful tex_mul path in vo_opengl does this anyway (at some points even explicitly), which means there will be a subtle difference in handling of 16 bit yuv alpha formats. Make it consistent and always apply the range adjustment to the alpha component. This also means odd sizes like 10 bit are supported now. This assumes alpha uses the same "shifted" range as the yuv color channels for depths larger than 8 bit. I'm not sure whether this is actually the case.
* vo_opengl: cocoa: output premultiplied alphawm42015-12-193-0/+4
| | | | | Which is apparently what is expected here. (I'm pretty sure X11 compositors want stright alpha, so 2 code paths are needed.)
* vo_opengl: prefix per-backend source files with context_wm42015-12-1913-13/+13
|
* vo_opengl: split backend code from common.c to context.cwm42015-12-1916-275/+345
| | | | | | | | Now common.c only contains the code for the function loader, while context.c contains the backend loader/dispatcher. Not calling it "backend.c", because the central struct is called MPGLContext.
* vo_opengl: x11egl: retrieve framebuffer depthwm42015-12-196-2/+56
| | | | | | | | | | This is used for dithering, although I'm not aware of anyone who got higher than 8 bit depth support to work on Linux. Also put this into egl_helpers.c. Since EGL is pseudo-portable at best I have no hope that the EGL context creation code in all the backends can be fully shared. But some self-contained functionality can definitely be shared.
* vo_opengl: refactor how framebuffer depth is passed from backendswm42015-12-197-30/+22
| | | | | | | | | | | Store the determined framebuffer depth in struct GL instead of MPGLContext. This means gl_video_set_output_depth() can be removed, and also justifies adding new fields describing framebuffer/backend properties to struct GL instead of having to add more functions just to shovel the information around. Keep in mind that mpgl_load_functions() will wipe struct GL, so the new fields must be set before calling it.
* vo_opengl: cocoa: implement alpha window supportwm42015-12-192-2/+11
| | | | | With --vo=opengl:alpha=yes, the Cocoa backend will now render alpha video without background.
* man: fix grammar issuesMartin Herkt2015-12-199-65/+71
|
* vo_opengl: fix "win" backend namewm42015-12-191-1/+1
| | | | | | | Although the source file is named w32.c, the backend name was "win" until recently. It was accidentally changed to "w32"; fix it. Fixes #2608 (the manual is correct).
* csputils: update MP_STEREO3D_COUNTPaul B Mahol2015-12-191-1/+1
| | | | | | | | | | This actually alows to playback alternating videos with mpv. Tested with actual file found in wild remuxed to mkv and changed props with following command: mkvpropedit /tmp/o.mkv --edit track:1 -s stereo-mode=13 Signed-off-by: Paul B Mahol <onemda@gmail.com>
* csputils: let mpv recognise frame sequenced 3D matroska videosPaul B Mahol2015-12-181-0/+2
| | | | | | Do actually such files exist? Signed-off-by: Paul B Mahol <onemda@gmail.com>
* vf_stereo3d: add alternating modesPaul B Mahol2015-12-181-0/+4
| | | | Signed-off-by: Paul B Mahol <onemda@gmail.com>
* sub: remove unused video width/height headerswm42015-12-184-17/+0
| | | | | | | Apparently, this was replaced by the SD_CTRL_SET_VIDEO_PARAMS set dimensions. But I can't find out when this happened - possibly, these fields were never used by sd_lavc.c, and only by the (long removed) MPlayer dvdsub decoder.
* sub: rename sd_lavc_conv.c to lavc_conv.cwm42015-12-183-2/+2
| | | | | | | | The previous commit turned sd_lavc_conv from a sd_driver to free-standing functions. Do the rename to reflect this change separately to avoid confusing git's content tracking. (Or did git solve this, making separating renames and content changes unnecessary?)
* sub: remove subtitle filter chain conceptwm42015-12-186-293/+122
| | | | | | | | | | | | | It was stupid. The only thing that still effectively used it was sd_lavc_conv - all other "filters" were the subtitle decoder/renderers for text (sd_ass) and bitmap (sd_lavc) subtitles. While having a subtitle filter chain was interesting (and actually worked in almost the same way as the audio/video ones), I didn't manage to use it in a meaningful way, and I couldn't e.g. factor secondary features like fixing subtitle timing into filters. Refactor the shit and drop unneeded things as it goes.
* sub: do not clear subtitle list on seekingwm42015-12-184-28/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This affects non-ASS text subtitles (those which go through libavcodec's subtitle converter), which are muxed with video/audio. (Typically srt subs in mkv.) The problem is that seeking in the file can send a subtitle packet to the decoder multiple times. These packets are interlaved with video, and thus can't be all read when opening the file. Rather, subtitle packets can essentially be randomly skipped or repeated (by seeking). Until recently, this was solved by scanning the libass event list for duplicates. Then our builtin srt-to-ass converter was removed, and the problem was handled by fully clearing the subtitle list on each seek. This resulted in sub-seek not working properly for this type of file. Since the subtitle list was cleared on seek, it was not possible to do e.g. sub-seeks to subtitles before the current playback position. Fix this by not clearing the list, and intead explicitly rejecting duplicate packets. We use the packet file position was unique ID for subtitles; this is confirmed working for most file formats (although it is slightly risky - new demuxers may not necessarily set the file position to something unique, or at all). The list of seen packets is sorted, and the lookup uses binary search. This is to avoid quadratic complexity when subtitles are added in bulks, such as when opening a text subtitle file. In some places, the code has to be adjusted to pass through the packet file position correctly.
* demux: check embedded cuesheet refers to only one fileKevin Mitchell2015-12-173-4/+25
| | | | | | If someone was "clever" enough to embed a cuesheet referencing multiple files, mpv would create a bunch of nonsense chapter markers.
* demux_cue: remove cue tracks which have a null filename.Kevin Mitchell2015-12-171-2/+12
| | | | | | | | | | This can happen if the file references a track, but does not specify an INDEX 01 for it. This would cause mpv to just segfault due to dereferencing the null pointer as a string. A file causing this was observed in the wild by ExactAudioCopy v0.99pb4 for a disk that contained a data track at the end.
* demux_lavf: minor cleanupswm42015-12-171-13/+5
|
* sd_ass: remove dead codewm42015-12-173-65/+7
| | | | | | | | | | | | | | | | | | | | | | | | With the FFmpeg subtitle decoder used for _all_ non-ASS text subtitle format, this code is simply unused now. Ironically, the FFmpeg subtitle decoder does not handle things correctly in a bunch of cases. Should it turn out they actually matter, they will have to hack back. The extend_event one is a candidate, although even though there were allegedly files which need it, I couldn't get samples from the user who originally reported such files. As such, extend_event was only confirmed to handle trailing events with no (endless) duration like with MicroDVD and LRC, but FFmpeg "fudges" these anyway, so no special handling is needed. This code also had logic to handle seeking with muxed srt subtitles, which made the sub-seek command work. But this has been broken before this commit already. Currently, seeking with muxed srt subs will clear all subtitles, as the broken FFmpeg ASS format output by the libavcodec subtitle converters does not check for duplicates. Since the subtitles are all cleared, ass_step_sub() can not work properly and sub-seek can not seek to already seen subtitles.
* sub: detect charset in demuxerwm42015-12-175-51/+40
| | | | | | | | | | | | Slightly simpler, and removes the need to pre-read all subtitle packets. This still does the subtitle charset conversion on the packet level (instead converting when parsing the file), so in theory this still could provide a way to change the charset at runtime. But maybe even this should be removed, as FFmpeg is somewhat likely to get its own charset detection and conversion mechanism in the future. (Would have to keep the subtitle file in memory to allow changing the charset on the fly, I guess.)
* sub: remove sd_srt.cwm42015-12-154-481/+0
| | | | | | | | The FFmpeg subtitle converter does the same. There used to be some deficiencies in FFmpeg's code, but it seems at least some of them have been fixed. There also used to be the timestamp issue (see previous commit messages), but this doesn't matter anymore. So no reason to keep this code - get rid of it.
* sub: remove sd_microdvd.cwm42015-12-154-348/+0
| | | | | | | This can be dropped for the same reasons as in the previous commits. It removes MicroDVD conversion support on Libav, although MicroDVD files couldn't be read in the first place ever since demux_subreader.c was removed.
* sub: remove sd_lavf_srt.cwm42015-12-154-98/+0
| | | | | | | This restored timestamps when demuxing srt subtitles in Libav, which was important for avoiding slightly overlapping subtitles. Since the way this works was changed, there is no real reason to maintain proper timestamps anymore on this level - this can be dropped without issues.
* sub: remove sd_movtext.cwm42015-12-155-69/+13
| | | | | libavcodec's movtext-to-ass converter does the same and has more features. On Libav, this commit disables mp4 subtitle display.
* vo_opengl: dxinterop: prevent crash after lost deviceJames Ross-Gowan2015-12-141-0/+13
| | | | | | | | | | | When a Direct3D 9Ex device fails to reset, it gets put into the lost state, so set the lost_device flag and don't attempt to present until the device moves out of that state. Failure to recreate the size- dependent objects should set lost_device as well, since we shouldn't try to present in that state. Also, it looks like I was too eager to remove code that sets priv members to NULL and I accidentally removed some that was needed.
* vo_opengl: dxinterop: prevent crash with 0-size windowJames Ross-Gowan2015-12-141-2/+3
| | | | | | Direct3D doesn't like 0-sized swapchain dimensions, even when those dimensions are automatically set. Manually set them to a size that isn't zero instead.
* vo_opengl: enable brightness/contrast controls for RGBwm42015-12-122-9/+14
| | | | | | | | | Why not. Also, instead of disabling hue/saturation for RGB, just don't apply them. (They don't make sense for conversion matrixes other than YUV, but I can't be bothered to keep the fine-grained disabling of UI controls either.)
* mixer: fix volume initialization with --af=volumewm42015-12-111-0/+2
| | | | | | | | A manually added af_volume could lead to muted audio when switching to a new file. af_volume keeps the last volume set by AF_CONTROL_SET_VOLUME to return it with AF_CONTROL_GET_VOLUME, but the initial value is 0. So the mixer volume was forced to 0 when unintializing the filter chain and reading back the previously set volume.
* mixer: minor simplificationwm42015-12-111-4/+7
| | | | (Why is this code so complex?)
* vo_opengl: add dxinterop backendJames Ross-Gowan2015-12-117-1/+689
| | | | | | | | | | | | | | | | | | | | | WGL_NV_DX_interop is widely supported by Nvidia and AMD drivers. It allows a texture to be shared between Direct3D and WGL, so that rendering can be done with WGL and presentation can be done with Direct3D. This should allow us to work around some persistent WGL issues, such as dropped frames with some driver/OS combos, drivers that buffer frames to increase performance at the cost of latency, and the inability to disable exclusive fullscreen mode when using WGL to render to a fullscreen window. The addition of a DX_interop backend might also enable some cool Direct3D-specific enhancements in the future, such as using the GetPresentStatistics API to get accurate frame presentation timestamps. Note that due to a driver bug, this backend is currently broken on Intel. It will appear to work as long as the window is not resized too often, but after a few changes of size it will be unable to share the newly created renderbuffer with GL. See: https://software.intel.com/en-us/forums/graphics-driver-bug-reporting/topic/562051
* demux: remove old subtitle parserwm42015-12-104-842/+0
| | | | | | | | | All of these are supported by FFmpeg now. It was disabled by default too (with FFmpeg). If compiled against Libav, mpv will lose the ability to read some subtitle formats (but the most important ones, srt and ass, still should work).
* stream: drop PVR supportwm42015-12-108-1694/+0
| | | | | | | | | This is only for specific Hauppage cards. According to the comments in who is actively using this feature. Get it out of the way. Anyone who still wants to use this should complain. Keeping this code would not cause terribly much additional work, and it could be restored again. (But not if the request comes months later.)
* player: init playback speed correctlywm42015-12-101-0/+2
| | | | | Usually not a problem, but could not be initialized early enough in some corner cases.
* vo_opengl: remove one more XYZ special-casewm42015-12-091-7/+2
| | | | The XYZ colorspace on XYZ pixfmt is enforced in some sanitation routine.
* vo_opengl: fix precision loss of fruit dithering matrixBin Jin2015-12-091-2/+9
| | | | | | | | | | With default setting, the matrix for fruit dithering requires 12 bits precision (values from 0/4096 to 4095/4096). But 16-bit float provides only 10 bits. In addition, when `dither-size-fruit=8` is set, 16 bits are required from the texture format. Fix this by attempting to use 16 bit integer texture first. This is still not precise, but should be better than using a half float.
* csputils: rename "yuv2rgb" functionswm42015-12-098-15/+15
| | | | | | They're not necessarily restricted to YUV aka YCbCr. vo_direct3d.c and demux_disc.c (DVD specific code) changes untested.
* csputils, vo_opengl: remove XYZ special case in color matrix retrievalwm42015-12-093-14/+8
| | | | | This just seems unnecessary. Refactor it a bit. There should be no functional changes.
* csputils: remove obscure int_bits matrix scalingwm42015-12-095-37/+22
| | | | | | | This has no reason to be there. Put the functionality into another function instead. While we're at it, also adjust for possible accuracy issues with high bit depth YUV (matters for rendering subtitles into screenshots only).
* vo_opengl: fix shader compilation regressionwm42015-12-082-4/+5
| | | | | | | | | | The recent LUT adjustment changes broke interpolation. The concatenation of the shader stages is a bit messy, and it seems like sampler_prelude is not a good place to add this macro. Always add the macro to every shader instead. (While this doesn't seem too elegant, this isn't too inelegant either, and goes these problems out of the way.)
* sub: increase gap/overlap fixing threshold to 210mswm42015-12-072-3/+3
| | | | Don't ask why.
* vo_opengl: enable colormatrix even for RGB inputwm42015-12-071-15/+13
| | | | Enables brightness/contrast controls, and handles gbrp10 correctly.
* vo_opengl: fix issues with some obscure pixel formatswm42015-12-075-11/+39
| | | | | | | | | | | | | | | | | | | The computation of the tex_mul variable was broken in multiple ways. This variable is used e.g. by debanding for moving expansion of 10 bit fixed-point input to normalized range to another stage of processing. One obvious bug was that the rgb555 pixel format was broken. This format has component_bits=5, but obviously it's already sampled in normalized range, and does not need expansion. The tex_mul-free code path avoids this by not using the colormatrix. (The code was originally designed to work around dealing with the generally complicated pixel formats by only using the colormatrix in the YUV case.) Another possible bug was with 10 bit input. It expanded the input by bringing the [0,2^10) range to [0,1], and then treating the expanded input as 16 bit input. I didn't bother to check what this actually computed, but it's somewhat likely it was wrong anyway. Now it uses mp_get_csp_mul(), and disables expansion when computing the YUV matrix.
* vo_opengl: decrease default lookup texture size to 64Bin Jin2015-12-072-4/+4
| | | | | | It turns out that with accurate lookup we can decrease the default size of texture now. Do it to compensate the performance loss introduced by the LUT_POS macro.
* vo_opengl: make LOOKUP_TEXTURE_SIZE configurableBin Jin2015-12-073-4/+14
|
* vo_opengl: Fix minor LUT sampling errorBin Jin2015-12-073-11/+22
| | | | | | Define a macro to correct the coordinate for lookup texture. Cache the corrected coordinate for 1D filter and use mix() to minimize the performance impact.
* filter_kernels: add warnings for potential LUT sampling errorBin Jin2015-12-071-0/+6
|
* cocoa: fix recent regressionwm42015-12-071-4/+6
| | | | | | | Commit 9db50c67 changed it so that the window title can now be a NULL string. Completely untested. Probably fixes #2570.
* win32: add option to set VO MMCSS profilewm42015-12-065-1/+17
| | | | This was requested.
* vo: get rid of vo_get_window_title()wm42015-12-066-34/+28
| | | | | | | | | | | It always was a weird artifact - VOCTRLs are meant _not_ to require special handling in the code that passes them through (like in vo.c). Removing it is also interesting to further reduce the dependency of backends on struct vo. Just get rid of it. Removing it is somewhat inconvenient, because in many situations the UI window is created after the first VOCTRL_UPDATE_WINDOW_TITLE. This means these backends have to store it in a new field in their own context.
* sd_ass: slightly better heuristic for applying --sub-fix-timingwm42015-12-061-1/+10
| | | | | | | | | | | Fixes a reported sample, that has a sign interrupted by a few frames (for which --sub-fix-timing would remove the wanted gap). The list of tags in has_overrides() is taken from libass. It has a similar function (which even checks whether the tag are within the { } delimiters). Unfortunately, this function is not public, so we just have a simpler one which does roughly the same. It doesn't matter that this function sometimes returns false positives.
* sub: another minor simplificationwm42015-12-061-6/+5
|