summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* client: remove legacy API that is unused nowAkemi2018-03-042-44/+1
| | | | | | this API was introduced in c5e4538 solely for the use with cocoa-cb and was not public. with the port to the new API in 760d471 it is now unused and can safely be removed.
* cocoa-cb: use new libmpv API instead of opengl-cbAkemi2018-03-045-62/+76
| | | | | a new replacement API was introduced with b037121 and the old one was deprecated. porting cocoa-cb to the new API.
* cocoa-cb: move the GL dummy function to swiftAkemi2018-03-042-6/+3
| | | | | | it's possible to get a function pointer through a closure after all in swift. remove the GL dummy function from the c header and do it in the swift code instead.
* cocoa-cb: remove debug remnant (stray print)Akemi2018-03-041-1/+0
|
* vo_gpu: don't segfault in libmpv_gl's destroy()Niklas Haas2018-03-041-1/+2
| | | | | This segfaults when the GPU context has not been fully initialized, such as would be the case when initialization errors.
* wscript: also install render API related headersNiklas Haas2018-03-041-1/+2
| | | | Omitted from b0371214
* player: fix strange behavior on edition switchingwm42018-03-031-0/+2
| | | | | | | After switching, the playback state was not reset, which could leave it in a strange, pause like state, that could be fixed by e.g. seeking. This seems to be an older regression - it's even in 0.27.
* player: don't free root filter while it's still neededwm42018-03-031-1/+1
| | | | | | | | | | | | | | Sometimes, playback needs to be fully uninitialized and reinitialized without "officially" closing and reopening the playlist entry. This happens with PT_RELOAD_FILE, which is triggered by edition switching and also DVD/BD title switching. (Not really sure why it goes through so much pain for such obscure cases. All it gains is not resetting "local" options, and not signaling a reload to the client API. Whatever.) The recent filter change freed filter_root too early without recreating it, so it crashed on edition switching. Fixes #5587.
* demux_lavf: add some hacks for SDPwm42018-03-031-0/+6
| | | | | | | Just the usual guess-what-opaque-ffmpeg-thing-supports. See #5550. It looks like we can reduce packet drop by having the cache enabled automatically.
* player: fix track autoselection of external files yet againwm42018-03-031-3/+3
| | | | | | If you used --aufio-file=file.mkv, and file.mkv included a video track marked as default, then the logic in select_default_track() would pick the video track from file.mkv. This is 100% broken, so fix it.
* command: fix whitespacewm42018-03-031-1/+1
|
* video: add option to reduce latency by 1 or 2 frameswm42018-03-035-4/+31
| | | | | | | | | | | | | | | | | | | | The playback start logic explicitly waits until the first frame has been displayed. Usually this will introduce a wait of 1 vsync. For normal playback this doesn't matter, but with respect to low latency needs, this only leads to additional data getting queued up in the demuxer or network buffers. Another thing is that the timing logic decodes 1 frame ahead (= 1 frame extra latency) to determine the exact duration of a frame. To be fair, there doesn't really seem to be a hard reason why this is needed. With the current code, enabling the option does lead to A/V desync sometimes (if the demuxer FPS is too inaccurate), and also frame drops at playback start in some situations. But this all seems to be avoidable, if the timing logic were to be rewritten completely, which should probably happen in the future. Thus the new option comes with the warning that it can be removed any time. This is also why the option has "hack" in the name.
* manpage: describe how to list/inspect/apply profileswm42018-03-031-0/+5
| | | | | This is all documented elsewhere in the manpage, but hard to find from here.
* options: add a builtin low-latency profilewm42018-03-032-0/+49
| | | | | | | | | | Well I guess it doesn't help that much. Also add some stuff that might help to the manpage. The fundamental problem with some "live" sources (e.g. x11grab) is actually that the player gets behind initially, and never thinks it has to catch up. This is also why --untimed can help.
* video: don't read ahead a frame in --untimed modewm42018-03-031-0/+3
| | | | | The extra frame is used to compute the exact frame duration. But frame drop is disabvled with --untimed.
* demux_lavf: add --demuxer-lavf-probe-info=nostreamswm42018-03-032-4/+11
| | | | Another attempt to try to make it behave in certain situations.
* demux: move some code to a separate functionwm42018-03-031-33/+41
| | | | No functional changes.
* demux: improve audio tag merging for OGG fileswm42018-03-031-4/+17
| | | | | | | | | | | | | | It's a mess: mp3 files have user tags as global metadata (because the id3v2 tag is global and there is only 1 stream), while OGG files have it per-track (because it's per-stream on the lowest level). mpv needs to try to make something nice out of the mess. It did so by trying to detect audio-only OGG files, and then copying the per-stream metadata to the global metadata. Make the heuristic for detecting this slightly more clever, so it works for files with extra, unrelated streams, like the awful libavformat cover art hack. Fixes #5577.
* vo_gpu: error out if there were rendering errors when taking screenshotwm42018-03-031-1/+5
|
* vo_gpu: fix taking screenshots of rotated videoswm42018-03-031-0/+3
| | | | Good old 90° rotation logic messing everything up.
* vd_lavc: fix inverted conditionwm42018-03-031-1/+1
|
* mp_image: replace rude function with less rude FFmpeg upstream functionwm42018-03-034-54/+5
| | | | This is new, thus a dependency bump is required.
* demux_lavf: don't mess up in streams with unknown size and init segmentwm42018-03-031-1/+2
| | | | | The return value of stream_get_size() will be -1 if it fails. We shouldn't mess up this value if a mp4 init segment is used.
* player: set thread name in opener threadwm42018-03-031-0/+3
| | | | Somewhat helpful for debugging.
* DOCS/interface-changes: add note about desyncing audio filterswm42018-03-031-0/+2
| | | | For example af_loudnorm is a known filter with this behavior.
* mp_image: make ref error handling slightly readablewm42018-03-031-10/+9
| | | | I think this is slightly more readable than this repeated "fail |= !".
* mp_image: pass through unknown AVFrame side datawm42018-03-032-1/+42
| | | | | | | | | Useful for libavfilter. Somewhat risky, because we can't ensure the consistency of the unknown side data (but this is a general problem with side data, and libavfilter filters will usually get it wrong too _if_ there are conflict cases). Fixes #5569.
* player: add warning comment about ignoring ABI safetywm42018-03-031-0/+3
| | | | | At least ffmpeg_garbage() uses sizeof(AVFrameSideData), which is not included in the ABI, but there's no ABI-safe alternative either.
* mp_image: fix subtle side data memory leakswm42018-03-031-2/+2
| | | | | | We must not create new references herem because mp_image_new_ref() is called later, and actually creates new references (including doing actual error checking). Blame C, not me.
* demux_mkv: enable libavcodec parser for eac3wm42018-03-031-1/+1
| | | | | | | | | | | | | | It appears some (or all) mkv files with EAC3 are muxed in a way that breaks FFmpeg's spdifenc. I suspect it's because either dependent substream packets are localted in their own packets, or the reverse. Or possibly this is case where the muxer did not respect packet boundaries at all. Enabling the EAC3 parser seems to fix this anyway, because why waste your precious time on retarded Dolby bullshit technology? (Which idiot came up with this shitty substream garbage?) Observed with dolby_digital_plus_channel_check_lossless-DWEU.mkv. Fixes #5578.
* README: mention some semi-required FFmpeg dependencieswm42018-03-031-0/+4
| | | | | | | | I think DASH playback tends to work much better with FFmpeg's DASH demuxer, which requires libxml2. For nvdec, FFmpeg git master now requires the external nvidia headers, since the builtin ones were removed.
* demux_edl: fix undefined behavior if mp4 init segment is not providedwm42018-03-031-1/+1
| | | | param_names[n] is only valid for n<nparam.
* cocoa-cb: fix building with SDK 10.12 and earlierAkemi2018-03-011-1/+1
| | | | | | | | | the NSWindowButton enum was moved to be a member of NSWindow and renamed to ButtonType in SDK 10.13. apparently that wasn't documented anywhere. not even in the SDK changes Document and the official Documentations makes it look like it was always like this. the old NSWindowButton enum though is still around on SDK 10.13 or at least got a typealias. so we will just use that.
* build: restore alphabetical sort order of file listswm42018-02-281-71/+71
|
* client API: deprecate opengl-cb API and introduce a replacement APIwm42018-02-2823-288/+1267
| | | | | | | | | | | | | | | | | | | | | | | | | The purpose of the new API is to make it useable with other APIs than OpenGL, especially D3D11 and vulkan. In theory it's now possible to support other vo_gpu backends, as well as backends that don't use the vo_gpu code at all. This also aims to get rid of the dumb mpv_get_sub_api() function. The life cycle of the new mpv_render_context is a bit different from mpv_opengl_cb_context, and you explicitly create/destroy the new context, instead of calling init/uninit on an object returned by mpv_get_sub_api(). In other to make the render API generic, it's annoyingly EGL style, and requires you to pass in API-specific objects to generic functions. This is to avoid explicit objects like the internal ra API has, because that sounds more complicated and annoying for an API that's supposed to never change. The opengl_cb API will continue to exist for a bit longer, but internally there are already a few tradeoffs, like reduced thread-safety. Mostly untested. Seems to work fine with mpc-qt.
* m_option: remove unneded compatibility featureswm42018-02-282-9/+2
| | | | | Aliases that set old options are not needed anymore. Also extend the total size of the aliases array for one of the following commits.
* vo_gpu: remove a dead declarationwm42018-02-281-1/+0
|
* client API: clarify license, fix some typoswm42018-02-282-3/+4
|
* osdep/atomic: add emulation for atomic_exchange()wm42018-02-281-0/+7
|
* osdep/atomic: fix potential shadowing warningswm42018-02-281-8/+8
| | | | | | | The stdatomic emulation adds "_" to each variable used inside the macros, to avoid that compilers print -Wshadow warnings for identifiers that are also used in surrounding code. Do this more consistently, because new warnings have been showing up.
* cocoa-cb: make fullscreen resize animation duration configurableAkemi2018-02-283-2/+30
|
* cocoa-cb: fix stretched gl surface on window aspect ratio changeAkemi2018-02-282-2/+48
| | | | | | | | when resizing async it's possible that the layer, and the underlying gl surface, is stretched on an aspect ratio change. to prevent that we do an atomic resize (resize and draw at the same time). usually max one unique frame should be dropped but it's possible, depending on the performance, that more are dropped.
* cocoa-cb: change border and borderless window stylingAkemi2018-02-289-20/+158
| | | | | | | | | | | the title bar is now within the window bounds instead of outside. same as QuickTime Player. it supports several standard styles, two dark and two light ones. additionally we have properly rounded corners now and the borderless window also has the proper window shadow. Also make the earliest supported macOS version 10.10. Fixes #4789, #3944
* drm_common: Improve VT switching signal handling somewhatAnton Kindestam2018-02-261-1/+15
| | | | | | | | By blocking the VT switcher signal in the VO thread we get less races and other oddities. This gets rid of tearing (at least for me) when VT switching with --gpu-context=drm.
* vo_drm: Fix pageflip errors on VT switchAnton Kindestam2018-02-261-2/+5
| | | | | | | | crtc_setup gets called on VT reacquire as well as during normal setup. When called during VT reacquire p->front_buf might not be 0, so the maths was wrong, and could cause array OOB errors. Use mathematically correct (for negative numbers) modulo to always pick the farthest away buffer (should work even for larger values of BUF_COUNT).
* context_drm_egl: Repair VT switchingAnton Kindestam2018-02-261-2/+27
| | | | | | | | | | | | | The VT switcher was being set up, but it was being neither polled nor interrupted. Insert wait_events and wakeup functions based on those from vo_drm, and add return early in drm_egl_swap_buffers if p->active isn't set. This should get basic VT switching working, however there will likely still be some random glitches. Switching between mpv and X11/weston is unlikely to work satisfactorily until we can solve the problems with drmSetMaster and drmDropMaster.
* context_drm_egl: Introduce 30bpp supportAnton Kindestam2018-02-264-30/+103
| | | | | | | | | | | | | This introduces the option --drm-format (currently used only by context_drm_egl, vo_drm implementation is pending) which allows you to pick between a xrgb8888 or a xrgb2101010 visual for --gpu-context=drm. Requires a recent mesa (18.0.0_rc4 or later) to work. This also fixes a bug when using --gpu-context=drm on a 30bpp-enabled mesa (allow_rgb10_configs set to true). Previously it would've set up an XRGB8888 format at the DRM/GBM level, while a 30bpp EGLConfig would be picked, resulting in a garbled image.
* egl_helpers: mpegl_cb can now signal an error conditionAnton Kindestam2018-02-262-1/+8
| | | | | This can be used by client code that needs to fail when it cannot find a suitable EGLConfig.
* cocoa-cb: fix wrong fullscreen window sizeAkemi2018-02-252-11/+21
| | | | | | | | | | | | | | | | | | | even though the fullscreen animation has a shorter duration than the system wide animation (space sliding effect) there are still cases where it takes longer, eg performance issues (especially on init). furthermore the final size of the animation is usually different than the actual fullscreen size because of spect ratio differences. the actual resize to fullscreen is done automatically by cocoa itself when the actual transition to fullscreen happens (system event). so it could happen that the last animation resize happened after the actual resize to fullscreen leading to a wrongly sized frame after entering fullscreen. to prevent this we cancel the animation when entering fullscreen, we always set the proper frame size when in fullscreen and discard any other frame sizes, and to prevent some performance problems on init we push entering fullscreen to the end of the main queue to execute it when most of the init routines are done. Fixes #5525
* cocoa-cb: fix wrong drawing size on resizeAkemi2018-02-251-17/+12
| | | | | | on live resize, eg async resize, the layer's bounds size is not in sync with the actual surface size. this led to a wrongly sized frame and a perceived flicker. get and use the actual surface size instead.
* vo_gpu: fix mobius tone mapping when sig_peak <= 1.0Niklas Haas2018-02-251-0/+2
| | | | | | | Mobius isn't well-defined for sig_peak <= 1.0. We can solve this by just soft-clamping sig_peak to 1.0. Although, in this case, we can just skip tone mapping altogether since the limit of mobius as sig_peak -> 1.0 is just a linear function.
* vo_gpu: don't tone-map for pure gamut reductionsNiklas Haas2018-02-251-3/+0
| | | | | | | | | Based on testing with real-world non-HDR BT.2020 clips, clipping the color space looks better than attempting to gamut map using a tone mapping shader that's (by now) optimized for HDR content. If anything, we'd have to develop a separate gamut mapping shader that works in LCh space.
* stream_file: add mode for reading appended fileswm42018-02-212-7/+61
| | | | | | | | | | | | | Do this because retrying reading on higher levels (like the demuxer) usually causes tons of problems. A hack like this is simpler and could allow to remove some of the higher level retry behavior. This works by trying to detect whether the file is appended. If we reach EOF, check if the file size changed compared to the initial value. If it did, it means the file was appended at least once, and we set the p->appending flag. If that flag is set, we simply retry reading more data every time we encounter EOF. The only way to do this is polling, and we poll for at most 10 times, after waiting for 200ms every time.
* audio: improve behavior if filters output nothing during probingwm42018-02-212-1/+9
| | | | | | | | | | Just bail out immediately (and disable audio) if format probing has no result, instead of doing nothing and then apparently freezing. This can happen with bogus filters, cases where the first audio frame is essentially dropped by filters (can happen with large resampling factors), and if the audio track contains no packets at all, or all packets fail to decode.
* cocoa-cb: fix invalid framebuffer operation errorAkemi2018-02-211-1/+5
| | | | | | | | | in certain circumstances the returned fbo for drawing is 0, but that fbo is solely used internally by the CAOpenGLLayer for its drawing and should never be used. in that case we fallback to 1 or the last used fbo instead if it was not 0. Fixes #5546
* drm_vo: pixel aspect from --monitoraspectMarco Migliori2018-02-211-1/+7
| | | | | | | | | | | | | | | | | When pixels are non-square, the appropriate value of vo->monitor_par is necessary to determine the destination rectangle, which in turn tells how to scale the video along the x and y axis. Before this commit, the drm driver only used --monitorpixelaspect. For example, to play a video with the right aspect on a 4:3 screen and 640:400 pixels, --monitorpixelaspect=5:6 had to be given. With this commit, vo->monitor_par is determined from the size of the screen in pixels and the --monitoraspect parameter. The latter is usually easier to determine than --monitorpixelaspect, since it is simply the proportion between the width and the height of the screen, in most cases 16:9 or 4:3. If --monitoraspect is not given, --monitorpixelaspect is used if given, otherwise pixel aspect is assumed 1:1.
* vf_vapoursynth: fix freezewm42018-02-201-5/+7
| | | | | | | Commit 59f9547fb56b missed this case, in which we can't make new progress and have to exit. Fixes #5548.
* vo_gpu: introduce --target-peakNiklas Haas2018-02-204-7/+49
| | | | | | | | | | | | | This solves a number of problems simultaneously: 1. When outputting HLG, this allows tuning the OOTF based on the display characteristics. 2. When outputting PQ or other HDR curves, this allows soft-limiting the output brightness using the tone mapping algorithm. 3. When outputting SDR, this allows HDR-in-SDR style output, by controlling the output brightness directly. Closes #5521
* vo_gpu: correctly parametrize the HLG OOTF by the display peakNiklas Haas2018-02-201-20/+31
| | | | | | | | | | | | | | The HLG OOTF is defined as a one-parameter family of OOTFs depending on the display's peak luminance. With the preceding change to OOTF scale and handling, we no longer have any issues with outputting values in whatever signal range we need. So as a result, it's easy for us to support a tunable OOTF which may (drastically) alter the display brightness. In fact, this is also the only correct way to do it, because the HLG appearance depends strongly on the OOTF configuration. For the OOTF, we consult the mastering display's tagging (via src.sig_peak). For the inverse OOTF, we consult the output display's target peak.
* vo_gpu: simplify and correct color scale handlingNiklas Haas2018-02-203-33/+40
| | | | | | | | | | | | | | | | | | | | | | | | | The primary need for this change is the fact that the OOTF was incorrectly scaled, due to the fact that the application of the OOTF can itself change the required normalization peak. (Plus, an oversight in pass_inverse_ootf meant we forgot to normalize at the end of it) The linearize/delinearize functions still normalize the scale since it's used in a number of places throughout gpu/video.c, but the color management function now converts to absolute scale right away, instead of in an awkward way inside the tone mapping branch. The OOTF functions now work in absolute scale only. In addition, minor changes have been made to the way normalization is handled for tone mapping - we now divide out the dst_peak *after* peak detection, in order to make the scale of the peak detection buffer consistent even if the dst_peak were to (hypothetically) change mid-stream. In theory, we could also do this for desaturation, but doing the desaturation before tone mapping has the advantage of preserving much more brightness than the other way around - and even mid-stream changes are not that drastic here. Finally, some preparation work has been done for allowing the user to customize the `dst.sig_peak` in the future.
* vo_mediacodec_embed: fix forgotten VO_CAP_NOREDRAW→VO_CAP_NORETAINJan Ekström2018-02-201-1/+1
| | | | Fixes compilation of this module.
* video: fix --video-rotate in some caseswm42018-02-181-1/+1
| | | | Which idiot wrote this code? [Yeah, me.]
* cocoa-cb: fix hwdec when drawing off-screenAkemi2018-02-171-0/+1</