summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* demux: improve and optimize cache pruning and seek range determinationwm42017-11-044-85/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | The main purpose of this commit is avoiding any hidden O(n^2) algorithms in the code for pruning the demuxer cache, and for determining the seekable boundaries of the cache. The old code could loop over the whole packet queue on every packet pruned in certain corner cases. There are two ways how to reach the goal: 1) commit a cardinal sin 2) do everything incrementally The cardinal sin is adding an extra field to demux_packet, which caches the determined seekable range for a keyframe range. demux_packet is a rather general data structure and thus shouldn't have any fields that are not inherent to its use, and are only needed as an implementation detail of code using it. But what are you gonna do, sue me? In the future, demux.c might have its own packet struct though. Then the other existing cardinal sin (the "next" field, from MPlayer times) could be removed as well. This commit also changes slightly how the seek end is determined. There is a note on the manpage in case anyone finds the new behavior confusing. It's somewhat cleaner and might be needed for supporting multiple ranges (although that's unclear).
* demux: reduce overhead when searching over keyframe rangeswm42017-11-041-31/+37
| | | | | | | | | | The demuxer cache seeking mechanism looks at keyframe ranges to determine the earlierst PTS of a packet. Instead of looping over all packets twice (once to find the next keyframe, a second time to find the seek PTS), do it in one go. For that basically turn recompute_keyframe_target_pts() into an iteration functionn. Functionality should be unchanged with this commit.
* player: log if NDEBUG is definedwm42017-11-041-0/+3
| | | | I sure want to know whether assert()s were unexpectedly not compiled in.
* demux: avoid excessive readahead after cache seekwm42017-11-041-1/+3
| | | | | | | | | | | | The base_ts field is used to guess the decoder position, and when set to NOPTS, it just read ahead arbitrarily. Also demux_add_packet() sets base_ts to the new timestamp when appending a packet, which would also make it readahead by a too large amount. Fix this by setting base_ts after a seek. This assumes that normally, a cached seek target will always have the timestamp set. This is actually not quite clear (as it calls recompute_keyframe_target_pts(), which looks at multiple packets), but maybe it works well enough.
* demux: make pruning more efficient for unseekable demuxer cachewm42017-11-041-19/+24
| | | | | | | | | Don't do any of the extra work related to pruning the backbuffer if demuxer cache seeking is disabled. As a small extra, always prune packets with no timestamps immediately, or queue heads that are not keyframes. (Both of them would be pruned from the backbuffer by the normal logic anyway.)
* demux: on queue overflow wake up reader thread on EOF onlywm42017-11-031-1/+1
| | | | This seems to make more sense.
* demux: don't show queue overflow warning when merely prefetchingwm42017-11-031-6/+7
| | | | | | | | | | | | | If fulfilling --demuxer-readahead-secs requires more memory than allowed by --demuxer-max-bytes, the queue obviously overflows. But the warning is normally only for the case when trying to find the next video or audio packet fails, and decoding can't continue. Use a separate variable for determining whether to prefetch, and if the queue has overflown, skip the message. In fact, skip the EOF setting and waking up the decoder thread as well, because the EOF flag should not be (have been) set in this situation, and waking up the reader thread helps only if the EOF state changed.
* vo_gpu: don't re-render hwdec frames when repeating frameswm42017-11-031-19/+11
| | | | | | | | | | | | | Repeating frames (for display-sync) is not supposed to render the entire frame again. When using hardware decoding, it unfortunately did: the renderer uses the frame ID to check whether the frame data changed, and unmapping the hwdec frame clears it. Essentially reverts commit 761eeacf5407cab07. Back then I probably thought it would be a good idea to release the hwdec image quickly in order to return it to the decoder, but they're referenced anyway. This should increase the performance and reduce GPU work.
* demux: don't allow subtitles to mess up buffered time displaywm42017-11-031-1/+2
| | | | | | | | | | | In a shit show of subtle corner case interactions, making the demuxer cache buffer the entire file can display a small buffered time if subtitles are enabled. The reason is that some subtitle decoders may read in advance infinitely, i.e. they read the entire subtitle stream. Then, since the other streams (audio/video) have logically reached EOF, and the subtitle stream is set to ds->active==true. This will have to be fixed properly later to account buffering for subtitle-only files (another corner case) correctly, but for now this is less annoying.
* osc: make cycling visibility an input.conf key bindingwm42017-11-032-1/+2
| | | | | As builtin script, it should not register global key bindings, and add them to input.conf instead. This is similar to what stats.lua does.
* demux: add option to create CC tracks eagerlywm42017-11-032-15/+58
| | | | | | | | | | | | We don't hope to auto-detect them at load time, as that would be too much of a pain - even FFmpeg requires fetching and parsing of video packets, and exposes the information only via deprecated API. But there still needs to be a way to select them by default. This is also needed to get the first CC packet at all (without seeking back). This commit also attempts to clean up locking a bit, which is a PITA, but it's better be careful & clean.
* vo_gpu: ra_gl: fix minimum GLSL version to 120wm42017-11-031-1/+1
| | | | Not sure why there was 110, or why there is even a default.
* vo_gpu: fix mobius tone mapping compatibility to GLSL 120wm42017-11-031-1/+1
| | | | | | | | | Normally such code is didsabled by have_mglsl==false in check_gl_features(), but apparently not this one. Just fix it. Seems also more readable. Fixes #5069.
* vo_gpu: ra_gl: fix crash trying to use glBindBufferBase on GL 2.1wm42017-11-031-2/+7
| | | | | | | Apparently this is required, but it doesn't check for it. To be fair, this was tested by creating a compatibility context and pretending it's GL 2.1. GL_ARB_shader_storage_buffer_object actually requires GL 4.0 or up, but GL_ARB_uniform_buffer_object requires only GL 2.0.
* wscript: use pkg-config for vulkan checkMartin Herkt2017-11-031-1/+1
|
* demux_mkv: add V_SNOW tag to mkv_video_tagsNicolas F2017-11-031-0/+1
| | | | | Apparently, and to nobody's surprise, mkv can contain snow. It does so with the V_SNOW tag. We can now play back snow-inside-mkv in mpv.
* osc: render seek ranges a bit less uglyChrisK22017-11-021-1/+1
|
* osc: render seek rangeswm42017-11-021-0/+26
| | | | | | Pretty fucking ugly, but I'm not a UI designer. Of course only does something with --demuxer-seekable-cache.
* stream_libarchive: stop reading on ARCHIVE_FATALwm42017-11-021-4/+41
| | | | | | | | | | | | | | | | According to https://github.com/libarchive/libarchive/pull/773#issuecomment-334892291 we're not allowed to "continue reading" (post above) or performing "more operations" (comments in archive.h header), whatever that means. Assume closing and freeing the archive is still ok. Since the codec already includes logic for closing and reopening the archive for seeking in unseekable archives, this probably isn't too bad. Untested due to lack of crashing sample (I lost my original test case, and as recently user-provided one didn't crash).
* screenshot: create directories from templateNicolas F2017-11-021-0/+5
| | | | | screenshot-template could be set to e.g. "%F/%04n", so we want to make sure that the path generated from the template actually exists.
* osd: don't skip leading whitespace on the first line eitherwm42017-11-021-1/+1
| | | | Stupid libass.
* vd_lavc: restore --hwdec-image-format and d3d11 opaque modewm42017-11-022-1/+6
| | | | | When the ifdeffery for the frame_params API was added, the new code accidentally didn't include this.
* build: fix cuda testwm42017-11-021-1/+1
|
* build: garbage => upstreamwm42017-11-011-2/+2
| | | | | "garbage" is considered offensive. The result will still be pretty bad though (currently build failures).
* build: make it easier to force FFmpeg upstreamwm42017-11-014-22/+18
| | | | | | | | | | | Apparently some people want this. Actually making it compile is still their problem, though, and I expect that build with FFmpeg upstream will occasionally be broken (as it is right now). This is because mpv also relies on API provided by Libav, and if FFmpeg hasn't merged that yet, it's not our problem - we provide a version of FFmpeg upstream with those changes merged, and it's called ffmpeg-mpv. Also adjust the README which still talked about FFmpeg releases.
* vo_gpu: potentially fix icc-profile-auto updatingwm42017-11-011-1/+1
| | | | | | | | | | | vo_gpu.c will call gl_video_icc_auto_enabled() to check whether it should retrieve the ICC profile. But the value returned by this function will be outdated, because gl_video_update_options() is not called yet. Change the order of function calls so that this is done after updating the options. (This is fairly chaotic, but I guess this code will be refactored a dozen of times anyway in the future.)
* vd_lavc: clean out more hwdec legacy codewm42017-10-313-39/+5
| | | | | | | | All this code used to be required by the old variants of the libavcodec hw decoding APIs. Almost all of that is gone, although the mediacodec API unfortunately still pulls in some old stuff (but not all of it). (mediacodec build/functionality is untested, but should work.)
* vd_lavc: remove more dead legacy codewm42017-10-314-108/+2
| | | | | | | | | | | | | | All of this was dead code and completely unused. get_buffer2_hwdec() is the biggest chunk. One unfortunate thing about it is that, while it was active, it could perform a software fallback much faster, because it didn't have to wait until a full frame is decoded (it actually decoded a full frame, but the current code has to decode many more frames due to the codec delay, because the current code waits until the API returns a decoded frame.) We should probably restore the latter, although since it's an optional optimization, and the current behavior doesn't change with the removal of this code, don't actually do anything about it.
* videotoolbox: use generic code for dummy hwdevice initwm42017-10-313-76/+19
| | | | | And move the remaining code (just 2 struct constant definitions) to vd_lavc.c.
* vd_lavc: remove dead legacy codewm42017-10-312-22/+0
|
* d3d: remove some legacy codewm42017-10-311-42/+0
| | | | See #5062.
* vd_lavc: makre sure required headers are included early enoughwm42017-10-312-1/+1
| | | | Should fix #5062.
* osd: don't strip leading whitespace in messageswm42017-10-301-0/+7
| | | | Do this by replacing the first space after a line break with "\h".
* vd_lavc: move display mastering data stuff to mp_imagewm42017-10-304-42/+22
| | | | | | | | | | | This is where it should be. It only wasn't because of an old libavcodec bug, that returned the side data only on every IDR. This required some sort of caching, which is now dropped. (mp_image wouldn't have been able to do this kind of caching, because this code is stateless.) We don't support these old libavcodec versions anymore, which is why this is not needed anymore. Also move initialization of rotation/stereo stuff to dec_video.c.
* Bump libav* API usewm42017-10-307-280/+50
| | | | (Not tested on Windows and OSX.)
* vo_gpu: remove a redundant ifdefwm42017-10-301-2/+0
|
* vd_lavc: make --hwdec=nvdec-copy actually workwm42017-10-302-3/+32
| | | | | | | | | | | | This simply didn't work. Unlike cuda-copy, this is a true hwaccel, and obviously we need to provide it a device. Implement this in a relatively generic way, which can probably reused directly by videotoolbox (not doing this yet because it would require testing on OSX). Like with cuda-copy, --cuda-decode-device is ignored. We might be able to provide a more general way to select devices at some later point.
* vd_lavc: remove need for duplicated cuda GL interop backendwm42017-10-304-20/+7
| | | | | | | This is just a dumb consequence of HWDEC_ types somehow being part of both decoder and VO. Obviously, the VO should only care about supporting specific hardware surface types or providing specific device types, but until they are separated, stupid unintuitive mismatches will occur.
* m_option: pretty print mpv_node for OSDwm42017-10-303-6/+41
| | | | | | Somewhat useful for debugging. Unfortunately libass (or something else) strips leading whitespace, making it look slightly more ugly than necessary. Still an improvement.
* demux: refactor to export seek rangeswm42017-10-303-43/+49
| | | | | | | | | | | | | | | | | | | | Even though only 1 seek range is supported at the time. Other than preparation for possibly future features, the main gain is actually that we finally separate the reporting for the buffering, and the seek ranges. These can be subtly different, so it's good to have a clear separation. This commit also fixes that the ts_reader wasn't rebased to the start time, which could make the player show "???" for buffered cache amount in some .ts files and others (especially at the end, when ts_reader could become higher than ts_max). It also fixes writing the cache-end field in the demuxer-cache-state property: it checked ts_start against NOPTS, which makes no sense. ts_start was never used (except for the bug mentioned above), so get rid of it completely. This also makes it convenient to move the segment check for last_ts to the demux_add_packet() function.
* Get rid of deprecated AVFrame accessorswm42017-10-304-6/+6
| | | | | | Fist we were required to use them for ABI compat. reasons (and other BS), now they're deprecated and we're supposed to access them directly again.
* manpage: fix/improve --msg-level descriptionwm42017-10-301-1/+3
| | | | Fixes #5055.
* hwdec_drmprime_drm: fix segv with --hwdecRyo Munakata2017-10-301-1/+4
|
* lavc_conv: make disable_styles fasterOleg Oshmyan2017-10-301-2/+3
| | | | | | | | | | | | | | The current invocation of bstr_cut is as good as no cutting at all. Almost the entire header is reread in every iteration of the loop. I don't know how many styles libavcodec tends to generate, but if (now or in the future) it generates many, then this loop is slow for no good reason. If anything, the code would be more clear and have the same performance if it didn't call bstr_cut at all. The intention here (and the sensible thing regardless) seems to be to skip the part of the string that bstr_find has already looked through and found nothing. This commit additionally skips the whole substring, because overlapping matches are impossible.
* demux_lavf: return AVERROR_EOF on file endDaniel Kucera2017-10-301-1/+1
| | | | | | | Signed-off-by: Daniel Kucera <daniel.kucera@gmail.com> Signed-off-by: wm4 <wm4@nowhere> Uses different style and different logic from original PR.
* vd_lavc: add support for nvdec hwaccelwm42017-10-286-1/+46
| | | | | | | | See manpage additions. (In ffmpeg-mpv and Libav, this is still called "cuvid". Libav won't work yet, because it has no frame params support yet, but this could get fixed soon.)
* demux_mkv: don't probe start time by defaultwm42017-10-271-1/+0
| | | | | | | It isn't all that reliable, and improving it would make startup slower and require more complexity. There isn't even a good reason to do this (other than semi-broken mkv files), so don't do it. Also see previous commit.
* lavc_conv: clamp timestamps to positive, fixes idiotic ffmpeg issuewm42017-10-271-0/+2
| | | | | | | | | | | In some cases, demux_mkv will detect a start time slightly above 0, but there might still be a subtitle starting at exactly 0. When the player rebases the timestamps to assumed start time, the subtitle will have a slightly negative timestamp in the end. libavcodec's subtitle converter turns this into a larger number due to underflow. Fix by clamping subtitles always to 0, which may or may not be what you want. At least it fixes #5047.
* travis: correctly remove ffmpeg-stable from build matrixwm42017-10-271-1/+0
|
* travis: adjust ffmpeg URLwm42017-10-272-7/+3
| | | | No idea if this is correct.
* lavfi: fix warnings with newer libavfilter versionswm42017-10-271-2/+2
| | | | | Most likely will cause new warnings with avfilter_graph_alloc_filter() on old libavfilter versions. Ingore that part.
* build: require our own ffmpeg repowm42017-10-271-3/+11
| | | | | | | | | This is required now. Can't have FFmpeg upstream randomly break us and then not fix it (like this recent EOF issue). Upstream FFmpeg is of course still supported, but you will need to edit the build scripts. Official support is only with the master branch of our own repo.
* vd_lavc: use avcodec_fill_hw_frames_parameters() APIwm42017-10-273-2/+118
| | | | | | | | This removes the need for codec- and API-specific knowledge in the libavcodec hardware acceleration API user. For mpv, this removes the need for vd_lavc_hwdec.pixfmt_map and a few other things. (For now, we still keep the "old" parts for the sake of supporting older Libav, and FFgarbage.)
* vo_gpu: fix ra_tex_upload_pbo for 2D texturesNiklas Haas2017-10-271-1/+5
| | | | | | params->rc was ignored in the calculation for the buffer size. I fucking hate this stupid ra_tex_upload signature where *rc is randomly relevant or not.
* vo_gpu: osd: simplify some codewm42017-10-271-5/+5
| | | | | | Coverity complains about this, but it's probably a false positive. Anyway, rewrite it in a slightly more readable way. Now it's more obvious that it is correct.
* audio/out: initialize an array to avoid confusing static analyzerwm42017-10-271-1/+1
| | | | | | | I _think_ this confuses Coverity and it thinks there is uninitialized data to be read. Initialize the array to change/remove the warning, or if there's a real problem, to make it easier to detect. (Basically apply defensive coding.)
* af_lavfi: fix small memory leakwm42017-10-271-6/+10
| | | | Plus restructure the error path to make this simpler.
* audio: fix small memory leakwm42017-10-271-0/+1
| | | | | Most commonly happened with --end, in which case that field tends to be set.
* command: change demuxer-cache-state property to return multiple rangeswm42017-10-264-26/+57
| | | | | | | | | | | | | | | | | | Even if the demuxer cache does not multiple ranges yet. This is to reduce the pain should caching of multiple ranges ever be implemented. Also change it from the sub properties stuff to return a mpv_node directly, which is less roundabout. Sub-property access won't work anymore, though. Remove the seekable-start/-end fields as well, as they're redundant with the ranges. All this would normally be considered an API change, but since it's been only a few days with no known users, change it immediately. This adds some node.c helpers as well, as the code would be too damn fugly otherwise.
* vd_lavc: more aggressive frame dropping for intra only codecswm42017-10-262-5/+15
| | | | | | | | Should speed up seeks. (Unfortunately it's useless for backstepping. Backstepping is like precise seeking, except we're unable to drop frames, as we can't know the previous frame if we drop it.)
* demux_timeline: don't use segments for DASHwm42017-10-261-1/+1
| | | | | Recent regression. Crashes because it sets the segmented flag, without actually setting the fields required for segmentation.
* vo_gpu: change --tone-mapping-desaturate algorithmNiklas Haas2017-10-253-17/+20
| | | | | | | | | | | | | | | Comparing mpv's implementation against the ACES ODR reference samples and algorithms, it seems like they're happy desaturating highlights _way_ more aggressively than mpv currently does. And indeed, looking at some example clips like The Redwoods (which is actually well-mastered), the current desaturation produces unnatural-looking brightness fringes where the sky meets the treeline. Adjust the algorithm to make it apply to a much larger, more gradual brightness region; and change the interpretation of the parameter. As a bonus, the new parameter is actually sanely scaled (higher values = more desaturation). Also, make it scale based on the signal level instead of the luminance, to avoid under-desaturating bright blues.
* demux: better computation of seek start targetwm42017-10-251-8/+24
| | | | | | | | | | | | Avoids that cache seeking is not possible with files that have audio frames with no timestamps (such as avi, sometimes mkv sub-packets from lacing). These would set back_pts (first seekable PTS)