summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* stream_dvb: Factor out logic to determine program and card.Oliver Freyermuth2019-10-022-47/+75
| | | | | | | | This is now treated in dvb_parse_path consistently instead of logic scattered over various functions. This is a requirement to sensibly re-evaluate config after options have been changed, since we have two ways to configure the stream (decorated URI and config parameters).
* stream_dvb: Use separated out options struct.Oliver Freyermuth2019-10-022-27/+33
| | | | | This also allows the use of m_config_cache_alloc which allows to watch config updates.
* demux_lavf: remove recently added author name from license headerwm42019-10-011-1/+0
| | | | | | | | | | | | | | | | | This was added in 585f9ff42f3195c by @bbarenblat (github handle). We don't do this. This file alone probably has multiple dozen of authors (I didn't count, but it has a history of 15 years). If everyone added their names with each small change, this project would have giant lists of contributing authors on every source file. Neither copyright law nor any of the used licenses require listing authors in the license header. Authorship is recorded in the git log. So don't start with this, and remove this recent case to avoid setting a precedent. Some files still have an author in the header. These cases are grandfathered, and usually are the actual authors of the original code.
* DOCS/contribute.md: split into sections, random changeswm42019-10-011-17/+61
| | | | | | | | Still trying to get people to read it. Even though I wanted to make it less of a wall of text and more readable, it got bigger. Oops. While I'm at it, violate my own rules and mix these mostly cosmetic changes with some actual rule changes and clarifications.
* github: try to get contributors to read contribute.mdwm42019-10-011-5/+4
| | | | | | | | | | | | | | | | | How hard can it be? I know contribute.md is a shitty wall of text, but that doesn't make it less important, and each violation will make it take longer by adding another review round anyway. And we really don't need lazy pull requests. If you can't be assed to follow a few simple rules, your code is probably shit or you wanted to be quick and lazy. Why should we accept it? We're the ones who have to maintain it and fix bugs in it, and if the contributor is lazy, the chance of you maintaining it is probably slim as well. On the other hand, WE the maintainers are not obligated to anything. Don't say that though, the first contact doesn't need to be negative. I don't know if the "lazy pull requests" is still too strong, but I can't tell.
* demux_mkv: better behavior/warnings on partial files/unseekable streamswm42019-10-011-5/+8
| | | | | | | | | | | | | | demux_mkv may seek to the end of the file to read certain headers (which should probably be called "footers", but in theory they are just headers that have been placed at the end of the file unfortunately). This commit changes behavior not to seek if the stream is not marked as seekable. Before this, it only checked whether the stream size was unknown (end negative). In practice it doesn't make much of a difference, since seekable usually equals known stream size. Also improve the wording, and distinguish between actual incomplete files, and unseekable ones.
* vo_gpu/d3d11: add adapter name validation and listing with "help"Jan Ekström2019-09-294-9/+75
| | | | Not the prettiest way to get it done, but seems to work.
* vo_gpu/d3d11: refactor pthread_once d3d11 loading to functionJan Ekström2019-09-291-6/+15
| | | | Lets us reuse this in the future.
* vo_gpu/d3d11: utilize the passed adapter nameJan Ekström2019-09-291-5/+77
| | | | | | Normalize nullptr and an empty string both to nullptr to simplify handling. API users cannot set a value back to nullptr, so both an empty string as well as nullptr should behave the same.
* vo_gpu/d3d11: add an option for the adapter nameJan Ekström2019-09-292-0/+6
| | | | Set it from the adapter name in the d3d11 options.
* video/d3d11: add adapter selection by name into d3d11 optionsJan Ekström2019-09-293-0/+15
| | | | | This lets the user define an adapter name that can then be passed further into the internals.
* vo_gpu/d3d11_helpers: also load up CreateDXGIFactory1Jan Ekström2019-09-291-4/+13
| | | | Just a factory, without a device, is required for listing of devices.
* stream_lavf: add support for gopherLeonardo Taccari2019-09-291-1/+1
|
* vo_drm: fix flickering when setting pan/scanAnton Kindestam2019-09-291-4/+0
| | | | | | | | Turns out clearing all frambuffers in reconfig isn't such a great idea when you also end up here when setting pan/scan. I guess this is just a leftover from a previous iteration of vo_drm where doing this made sense.
* demux: make --record-file/cache dump command work with disabled streamswm42019-09-291-5/+18
| | | | | | | | | | | | | | | | This passed all streams to mp_recorder_create(), even disabled ones. The disabled streams never get packets, so recorder.c eventually errors out with unrelated-looking errors. The reason is that recorder.c waits for packets to appear on other streams, which in turn is because libavformat refuses to mux empty streams anyway. recorder.c could call demux_stream_is_selected(), which would have made the patch much smaller. But this feels like a bad idea, since recorder.c should use sh_stream only for metadata (and not in an "active" way), nor should it care what demux.c is currently doing with it. So make the API user (demux.c) pass only the streams it really wants. Fixes: #6999
* loadfile: make prefetching actually workwm42019-09-291-1/+3
| | | | | | | | | | | | | | | | Looks like this didn't actually work. Prefetching will do nothing if there isn't a thread to "drive" it, and the demuxer thread needs to be explicitly enabled. (I guess I did the worst possible job in verifying whether this actually worked when I implemented it. On the other hand, the user didn't confirm back whether it worked, so who cares.) Like in the previous commit, bad factoring makes everything worse. It duplicates logic and implementation of enable_demux_thread(), since the opener thread cannot access the mpctx->opts field freely. But it's deep night, so fuck it. Fixes: c1f1a0845e03885e Fixes: #6753
* loadfile: don't always accidentally always prefetchingwm42019-09-292-11/+16
| | | | | | | | | | | | | | demux_start_prefetch() was called unconditionally in two cases. This is completely wrong. I'm not sure what part of my brain died off that something this obviously wrong went in. The prefetch case is a bit more complicated. It's a different thread, so you can't access just access mpctx->opts there. So add an explicit field for this, which is the simplest way to get this done. (Even if it's bad factoring.) Fixes: c1f1a0845e03885eebe63 Fixes: 556e204a112ee286972e5
* recorder: don't use a magic index for mp_recorder_get_sink()wm42019-09-294-8/+16
| | | | | | | | | | | | | | | | | | | Although this was sort of elegant, it just seems to complicate things slightly. Originally, the API meant that you cache mp_recorder_sink yourself (which would avoid the mess of passing an index around), but that too seems slightly roundabout. In a later change, I want to change the set of streams passed to mp_recorder_create(), and then I'd have to keep track of the index for each stream, which would suck. With this commit, I can just pass the unambiguous sh_stream to it, and it will be guaranteed to match the correct stream. The disadvantages are barely worth discussing. It's a new linear search per packet, but usually only 2 to 4 streams are active at a time. Also, in theory a user could want to write 2 streams using the same sh_stream (same metadata, just writing different packets or so), but in practice this is never done.
* stream: rearrange open functionswm42019-09-294-56/+96
| | | | | | | | | | | | | | | | Add yet another variant of the stream open function. This time, make it so that it's possible to add new open parameters in an extendable way, which should put an end to having to change this every other year. Effectively get rid of the overly special stream_create_instance() function and use the new one instead, which requires changes in stream_concat.c and stream_memory.c. The function is still in private in stream.c, but I preferred to make the mentioned users go through the new function for orthogonality. The error handling (mostly logging) was adjusted accordingly. This should not have any functional changes. (To preempt any excuses, I didn't actually test stream_concat and stream_memory.)
* demux: sort filenames naturally when playing a directory / archivePhilip Sequeira2019-09-295-2/+95
|
* build: lower version requirement for EGLMarvin Schmidt2019-09-291-1/+1
| | | | | | | | `egl.pc` can be provided either by mesa or libglvnd. The latter doesn't follow the same version scheme as mesa but instead uses the API version that the library exposes, which is 1.5 for EGL[1] [1] https://github.com/NVIDIA/libglvnd/commit/0dfaea2bcb7cdcc785f95e244223bd004a2d7fba#diff-b58a140c00ea99fb9a708e15afaade62R8
* vo_gpu: hwdec_cuda: Synchronise OpenGL InteropPhilip Langdale2019-09-283-0/+8
| | | | | | | | | | | | | | | | | | | | | Previously, there appeared to be implicit synchronisation in the GL interop path, and we never observed any visual glitches. However, recently, I started seeing stuttering in the GL path and on closer examination it looked like read-before-write behaviour where GL would display an old frame again rather than the current one. After verifying that disabling hwdec made the problem go away, I tried adding a cuStreamSynchronize() after the memcpys and that also resolved the problem, so it's clearly sync related. cuStreamSynchronize() is a CPU sync and so more heavy-weight than you want, but it's the only tool we have. There is no mechanism defined for synchronising GL to CUDA (It looks like there is a way to synchronise CUDA to EGL but it appears one way and so wouldn't directly address this problem). Anyway, empirically, the output now looks the same as with hwdec off.
* build: silence OpenGL deprecation warnings on macOS for C/objCRodger Combs2019-09-281-1/+2
| | | | | We know of the deprecation since 10.14, and thus we do not need to be reminded of it with each compiled file.
* vo_drm: support controlling swapchain depth using swapchain-depth optionAnton Kindestam2019-09-281-10/+13
|
* vo: make swapchain-depth option generic for all VOsAnton Kindestam2019-09-2811-24/+21
| | | | In preparation for making vo_drm able to use swapchain-depth
* drm: refactor page_flipped callbackAnton Kindestam2019-09-284-109/+71
| | | | | Avoid duplicating the same callback function in both context_drm_egl and vo_drm.
* vo_drm: Implement N-buffering and presentation feedbackAnton Kindestam2019-09-281-39/+215
| | | | | | | | | | | Swapchain depth currently hard-coded to 3 (4 buffers). As we now avoid redrawing on repeat frames (we simply requeue the same fb again), this should give a nice performance boost when playing videos with a lower FPS than the display FPS in video-sync=display-resample mode. Presentation feedback has also been implemented to help counter the significant amounts of jitter we would otherwise be seeing.
* vo_drm: fix more than 2 buffersAnton Kindestam2019-09-281-1/+1
| | | | Now we can increase BUF_COUNT. Yay.
* drm: move struct vsync_tuple into drm_common as drm_vsync_tupleAnton Kindestam2019-09-282-9/+8
| | | | This struct will be useful in vo_drm as well.
* stream_cb: add cancel_fn callbackAman Gupta2019-09-274-1/+27
| | | | | | | | This allows stream_cb backends to implement blocking behavior inside read_fn, and still get notified when the user wants to cancel and stop playback. Signed-off-by: Aman Gupta <aman@tmm1.net>
* audio: fix copy&paste errorwm42019-09-271-1/+1
| | | | | | | This wasn't used at all in my tests, because it simply passed the frame directly to libswsresample. (And, by the way, will always do that, because s64 is so obscure literally NOTHING uses it except a sample specifically created to test this code. Screw FFmpeg.)
* ad_lavc: log on failure to read AVFramewm42019-09-271-1/+3
| | | | | | | | This can be due to unsupported sample formats (see previous commits), minor allocation failures, and similar things. For identifying the exact cause it's buried too deep in abstractions. But most time it doesn't happen anyway, since it's extremely rare that new audio formats are added.
* audio: add support for AV_SAMPLE_FMT_S64*wm42019-09-273-0/+8
| | | | | | | | | | What an idiotic format. It makes no sense, and should have been converted to S32 in the demuxer, rather than plague everyone with another extremely obscure nonsense format. Why doesn't ffmpeg add S24 instead? That's an actually useful format. May cause compilation failure with old FFmpeg or Libav libs, but I don't care.
* context_drm_egl: define EGL_PLATFORM_GBM_MESA, EGL_PLATFORM_GBM_KHR if not ↵Anton Kindestam2019-09-271-0/+8
| | | | | | | in system headers To account for oddball setups where EGL_PLATFORM_GBM_MESA or EGL_PLATFORM_GBM_KHR might not be defined for whatever reason.
* wscript: check tvOS define's value to be nonzeroJan Ekström2019-09-271-1/+4
| | | | | | TARGET_OS_TV seems to always be defined, but set according to the build configuration. This fixes all Apple configurations being mis-identified as tvOS.
* video: add pure gamma TRC curves for 2.0, 2.4 and 2.6.Wessel Dankers2019-09-276-0/+36
|
* ci: remove --enable-zsh-compPhilip Sequeira2019-09-271-2/+1
| | | | | This option no longer exists, as zsh completion is installed unconditionally now.
* zsh completion: move generation to runtime and improvePhilip Sequeira2019-09-275-307/+253
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The completion function itself now parses --list-options on the first tab press and caches the results. This does mean a slight delay on that first tab press, but it will only do this if the argument being completed looks like an option (i.e. starts with "-"), so there is never a delay when just completing a file name. I've also put some effort into making it reasonably fast; on my machine it's consistently under 100 ms, more than half of which is mpv itself. Installation of zsh completion is now done unconditionally because it's nothing more than copying a file. If you really don't want it installed, set zshdir to empty: `./waf configure --zshdir= ...` Improvements in functionality compared to the old script: * Produces the right results for mpv binaries other than the one it was installed with (like a dev build for testing changes). * Does not require running mpv at build time, so it won't cause problems with cross compilation. * Handles aliases. * Slightly nicer handling of options that take comma-separated values and/or sub-options: A space is now inserted at the end instead of a comma, allowing you to immediately start typing the next argument, but typing a comma will still remove the automatically added space, and = and : will now do that too, so you can immediately add a sub-option. * More general/flexible handling of values for options that print their possible values with --option=help. The code as is could handle quite a few more options (*scale, demuxers, decoders, ...), but nobody wants to maintain that list here so we'll just stick with what the old completion script already did.
* options: add M_OPT_FILE to some more options that take filesPhilip Sequeira2019-09-273-10/+10
|
* vo_gpu: hwdec_drmprime_drm: add hwdec ctxJonas Karlman2019-09-272-1/+15
| | | | | | | This allows to use drm hwaccels that require a hwdevice. Tested with v4l2request hwaccel and cedrus driver on an allwinner device running mpv with --vo=gpu --gpu-context=drm --hwdec=drm.
* hwdec_vaapi_gl: add missing compatibility defineswm42019-09-271-0/+6
| | | | | | | | | | | At first, this code used only 1 plane, so the compatibility stuff was sufficient. But then use of planes 1 and 2 was added, without extending the compatibility stuff. I think I've seen a case recently where this broke the build and caused users to apply invalid fixes, but I don't remember where. It's possible that I didn't get all defines that are needed.
* stream_cb: fix a typo in a commentwm42019-09-271-1/+1
|
* ao_pulse: add the newly added mappings for TrueHD/DTS-HD formatsJan Ekström2019-09-271-6/+11
| | | | | Originally DTS-HD was mapped to PA_ENCODING_DTS_IEC61937 which I'm actually not sure if it ever worked.
* vo_gpu: vulkan: add Android contextsfan52019-09-273-0/+99
|
* context_android: move common code to a separate filesfan52019-09-275-52/+153
| | | | | | In preparation for a Vulkan Android context. This also replaces querying for EGL_WIDTH and EGL_HEIGHT with equivalent ANativeWindow calls.
* DOCS: don't lie about the keybind commanddudemanguy2019-09-261-2/+1
| | | | | It turns out you can actually bind keybind to another keybind. Just be careful with all the quotes.
* wscript: detect tvOS and disable posix-spawn usageAman Gupta2019-09-261-1/+5
| | | | | | cc #5331 Signed-off-by: Aman Gupta <aman@tmm1.net>
* vo_gpu: d3d11: don't reset frame stats after pauseJames Ross-Gowan2019-09-261-9/+0
| | | | | | | | | | | | | | | | | | | | | | I think I was wrong about having to reset the stats when mpv stops producing frames, eg. when it's paused. As long as the swapchain doesn't underflow, last_queue_display_time will still be accurate, because the next frame produced should still be presented one vsync after the last one in the swapchain. If the swapchain underflows (which is the common case for when mpv is paused for more than 150ms,) the next predicted frame time should be in the past. It should be fine to leave last_queue_display_time unset in this case, since vo.c will use the current time instead, which is a decent guess (though it doesn't take vsync phase into account.) last_sync_refresh_count and last_sync_qpc_time should be kept on swapchain underflow as well. Assuming the display refresh rate doesn't change while mpv is paused, they'll only provide a more accurate guess of the vsync duration when mpv starts playing again. Also, vsync_duration_qpc never needs to get reset. It will get overwritten immediately in most cases, and when it doesn't, it's still a better guess of the vsync duration than nothing.
* player: document FFmpeg ABI rules we intentionally violatewm42019-09-261-0/+2
| | | | | | | | | | That's just a single one. It used to be more, when FFmpeg still required using pointless accessors for tons of fields, which historically broke compatibility with Libav. (I think I wrote the patch to deprecate that crap and to allow direct access myself.) There may be more exceptions, but I forgot about them. Another point is that we don't really trust FFmpeg ABI stability, though.
* audio: make playback end with --end and --audio-spdifwm42019-09-261-0/+3
| | | | | | | | | | | | | In spdif mode, there are hacks that try to cut audio on frame boundaries (blame spdif, which is a hack in itself). The "alignment" is used in a bunch of places, but --end does not respect it. This leads to some audio that can't be pushed because the alignment is off (I don't know why, not do I care), which puts audio into an underrun state forever. Fix this by discarding unusable extra samples if no new data can be expected. Fixes: #6935
* DOCS/contribute.md: talk about non-standard and C11 language featureswm42019-09-261-3/+4
| | | | | | | | | | | The C11 situation is complicated. For example, MinGW doesn't seem to have a full C11 implementation, but we pretty much rely on C11 atomics. Regarding "#pragma once": they say it's not standard because of unsolved (admittedly valid) issues. Btu still, fuck writing include guards, I just can't be bothered with this crap. (Does anyone even read this document?)
* client API: be explicit about usage rules and deadlocks some morewm42019-09-262-0/+9
| | | | | | | I think a popular libmpv application did exactly this: enabling advanced control, and then receiving deadlocks. I didn't confirm it, though. In any case, the API docs should avoid tricking users into making this easy mistake.
* client API: fix potential deadlock problems by throwing more shit at itwm42019-09-267-32/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The render API (vo_libmpv) had potential deadlock problems with MPV_RENDER_PARAM_ADVANCED_CONTROL. This required vd-lavc-dr to be enabled (the default). I never observed these deadlocks in the wild (doesn't mean they didn't happen), although I could specifically provoke them with some code changes. The problem was mostly about DR (direct rendering, letting the video decoder write to OpenGL buffer memory). Allocating/freeing a DR image needs to be done on the OpenGL thread, even though _lots_ of threads are involved with handling images. Freeing a DR image is a special case that can happen any time. dr_helper.c does most of the evil magic of achieving this. Unfortunately, there was a (sort of) circular lock dependency: freeing an image while certain internal locks are held would trigger the user's context update callback, which in turn would call mpv_render_context_update(), which processed all pending free requests, and then acquire an internal lock - which the caller might not release until a further DR image could be freed. "Solve" this by making freeing DR images asynchronous. This is slightly risky, but actually not much. The DR images will be free'd eventually. The biggest disadvantage is probably that debugging might get trickier. Any solution to this problem will probably add images to free to some sort of queue, and then process it later. I considered making this more explicit (so there'd be a point where the caller forcibly waits for all queued items to be free'd), but discarded these ideas as this probably would only increase complexity. Another consequence is that freeing DR images on the GL thread is not synchronous anymore. Instead, it mpv_render_context_update() will do it with a delay. This seems roundabout, but doesn't actually change anything, and avoids additional code. This also fixes that the render API required the render API user to remain on the same thread, even though this wasn't documented. As such, it was a bug. OpenGL essentially forces you to do all GL usage on a single thread, but in theory the API user could for example move the GL context to another thread. The API bump is because I think you can't make enough noise about this. Since we don't backport fixes to old versions, I'm specifically stating that old versions are broken, and I'm supplying workarounds. Internally, dr_helper_create() does not use pthread_self() anymore, thus the vo.c change. I think it's better to make binding to the current thread as explicit as possible. Of course it's not sure that this fixes all deadlocks (probably not).
* command: fix bitrate rounding errorStefan Pöschel2019-09-261-2/+2
| |