summaryrefslogtreecommitdiffstats
path: root/common
Commit message (Collapse)AuthorAgeFilesLines
* msg: move central msg lock to mp_log_rootwm42020-01-301-34/+36
| | | | | | | | | | | | This is a central lock (that is to stay and has no reason to go away), and it was simply made global. This reduces complexity when the original MPlayer code was changed from single thread + global state to a context handle. Having the global lock was still a bit silly if there were multiple mpv instances in the process, because it would make the instances wait for each other for no reason. So move it to the per-instance context, which is trivial enough.
* msg: fix some locking issueswm42020-01-301-7/+8
| | | | | | | | | | | | | | | | | | | | | | The wakeup_log_file callback was still assuming that mp_msg_lock was used to control the log file thread, but this changed while I was writing this code, and forgot to update it. (It doesn't change any state, which is untypical for condition variable usage. The state that is changed is protected by another lock instead. But log_file_lock still needs to be acquired to ensure the signal isn't sent while the thread is right before the pthread_cond_wait() call, when the lock is held, but the signal would still be lost.) Because the buffer's wakeup callback now acquires the lock, the wakeup callback must be called outside of the buffer lock, to keep the lock order (log_file_lock > mp_log_buffer.lock). Fortunately, the wakeup callback is immutable, or we would have needed another dumb leaf lock. mp_msg_has_log_file() made a similar outdated assumption. But now access to the log_file field is much trickier; just define that it's only to be called from the thread that manages the msg state. (The calling code could also just check whether the log-file option changed instead, but currently that would be slightly more messy.)
* msg: make --log-file buffered through a threadwm42020-01-292-53/+170
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now --log-file performed a blocking write to the log file, which made any calling thread block for I/O. It even explicitly flushed after every line (to make it tail-able, or to ensure a hard crash wouldn't lose any of the output). This wasn't so good, because it could cause real playback problems, which made it infeasible to enable it by default. Try to buffer it through a ring buffer and a thread. There's no other choice but to use a thread, since async I/O on files is generally a big and unportable pain. (We very much prefer portable pain.) Fortunately, there's already a ring buffer (mp_log_buffer, normally for the client API logging hook). This still involves some pretty messy locking. Give each mp_log_buffer its own lock to make this easier. This still makes calling threads block if the log buffer is full (unlike with client API log buffers, which just drop messages). I don't want log messages to get lost for this purpose. This also made locking pretty complicated (without it, mp_log_buffer wouldn't have needed its own lock). Maybe I'll remove this blocking again when it turns out to be nonsense. (We could avoid wasting an entire thread by "reusing" some other thread. E.g. pick some otherwise not real time thread, and make it react to the log buffer's wakeup callback. But let's not. It's complicated to abuse random threads for this. It'd also raise locking complexity, because we still want it to block on a full buffer.)
* command: add a playlist-unshuffle commandwm42019-12-282-0/+26
| | | | | | Has a number of restrictions. See: #2491, #7294
* playlist: change from linked list to an arraywm42019-12-282-122/+131
| | | | | | | | | | | | | | | | | | | Although a linked list was ideal at first, there are cases where it sucks, and became increasingly awkward (with the mpv command API preferring integer indexes to access the list). In future, we probably want to add more playlist-related functionality, so better change it to an array now. An array isn't always ideal either. Since playlist entries are still separate objects (because in some cases you need a stable "iterator" to it), but you still need to efficiently get the next/previous playlist entry, there's a pl_index field, that needs to be maintained. E.g. adding an entry at the start of the playlist => update the pl_index field for all other entries. Well, it's not really worth to do something more complicated to avoid these things. This commit is probably buggy as shit. It's not like I bothered to test everything. That's _your_ role.
* stream, demux: redo origin policy thingwm42019-12-203-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mpv has a very weak and very annoying policy that determines whether a playlist should be used or not. For example, if you play a remote playlist, you usually don't want it to be able to read local filesystem entries. (Although for a media player the impact is small I guess.) It's weak and annoying as in that it does not prevent certain cases which could be interpreted as bad in some cases, such as allowing playlists on the local filesystem to reference remote URLs. It probably barely makes sense, but we just want to exclude some other "definitely not a good idea" things, all while playlists generally just work, so whatever. The policy is: - from the command line anything is played - local playlists can reference anything except "unsafe" streams ("unsafe" means special stream inputs like libavfilter graphs) - remote playlists can reference only remote URLs - things like "memory://" and archives are "transparent" to this This commit does... something. It replaces the weird stream flags with a slightly clearer "origin" value, which is now consequently passed down and used everywhere. It fixes some deviations from the described policy. I wanted to force archives to reference only content within them, but this would probably have been more complicated (or required different abstractions), and I'm too lazy to figure it out, so archives are now "transparent" (playlists within archives behave the same outside). There may be a lot of bugs in this. This is unfortunately a very noisy commit because: - every stream open call now needs to pass the origin - so does every demuxer open call (=> params param. gets mandatory) - most stream were changed to provide the "origin" value - the origin value needed to be passed along in a lot of places - I was too lazy to split the commit Fixes: #7274
* msg: fix "terminal-default" logging modewm42019-12-161-2/+5
| | | | | | | | | | | | | | | | | | | | | | | console.lua uses "terminal-default" logging, which is supposed to return all messages logged to the terminal to the API. Internally, this is translated to MP_LOG_BUFFER_MSGL_TERM, which is MSGL_MAX+1, because it's not an actual log level (blame C for not having proper sum types or something). Unfortunately, this unintentionally raised the internal log level to MSGL_MAX+1. It still functioned as intended, because log messages were simply filtered at a "later" point. But it led to every message being formatted even if not needed. More importantly, it made mp_msg_test() pointless (code calls this to avoid logging in "expensive" cases and if the messages would just get discarded). Also, this broke libplacebo logging, because the code to map the log messages did not expect a level higher than MSGL_MAX (mp_msg_level() returned MSGL_MAX+1 too). Fix this by not letting the dummy level value be used as log level. Messages at terminal log level will always make it to the inner log message dispatcher function (i.e. mp_msg_va() will call write_msg_to_buffers()), so log buffers which use the dummy log level don't need to adjust the actual log level at all.
* msg: show how many messages were droppedwm42019-11-221-1/+3
| | | | Although repl.lua will probably not use this.
* msg: drop old instead of new messages on overflowwm42019-11-221-43/+57
| | | | | | | | | | | | It did that because there was no other way. It used a lock-free ring buffer, which does not support this. Use a "manual" ring buffer with explicit locks instead, and drop messages from the start. (We could have continued to use mp_ring, but it was already too late, and although mp_ring is fine, using it for types other than bytes looked awkward, and writing a ring buffer yet again seemed nicer. At least it's not C++, where mp_ring would have been a template, and everything would have looked like shit soup no matter what.)
* msg: fix missing wakeup callback in terminal-default log levelwm42019-11-221-0/+2
| | | | | | | | | In the referenced commit, I forgot about this part, and a client which tried to use this was actually not woken up when needed. (Also why the hell does the subject line of that commit say "removed"?) Fixes: 8c2d73f11205
* player: remove mechanisms for better logging with repl.luawm42019-11-182-1/+61
| | | | | | | | | | | | | | | | | | | | | | As preparation for making repl.lua part of the core (maybe), add some mechanisms which are supposed to improve its behavior. Add a silent mode. Calling mpv_request_log_messages() with the log level name prefixed with "silent:" will disable logging from the API user's perspective. But it will keep the log buffer, and record new messages, without returning them to the user. If logging is enabled again by requesting the same log level without "silent:" prefix, the buffered log messages are returned to the user at once. This is not documented, because it's far too messy and special as that I'd want anyone to rely on this behavior, but it will be perfectly fine for an internal script. Another thing is that we record early startup messages. The goal is to make the repl.lua script show option and config parsing file errors. This works only with the special "terminal-default" log level. In addition, reduce the "terminal-default" capacity to only 100 log messages. If this is going to be enabled by default, it shouldn't use too much resources.
* options: remove M_OPT_FIXEDwm42019-11-101-15/+15
| | | | | | | | | | | | | | | | | | | | | | | Options marked with this flag were changed to strictly read-only after initialization (mpv_initialize() in the client API, after option parsing and config file loading with the CLI player). This used to be necessary, because there was a single option struct that could be accessed by multiple threads. For example, --config-dir sets MPOpts.force_configdir, which was read whenever anything accessed the mpv config dir (which could be on different threads, e.g. font initialization tries to lookup fonts.conf from an arbitrary thread). This isn't needed anymore, because threads now access these in a thread safe way. In the case of --config-dir, the path is actually just copied on init. This M_OPT_FIXED mechanism is thus not strictly needed anymore. It still prevents writing to some options that cannot take effect at runtime, but even that can be dropped. In general, all mpv options can be changed any time at runtime, even if they never take effect, and there's no need to make an exception for a very low number of options. So just get rid of it.
* msg: try to document purpose of log levels betterwm42019-11-071-8/+9
| | | | (But I bet nobody ever reads this anyway.)
* common: add a helper to round up to next power of 2wm42019-11-062-0/+15
| | | | | | This is something relatively frequently needed, and there must be half a dozen ad-hoc implementations in mpv. The next commit uses this, the suspected duplicate implementations are hiding.
* common: add mp_log2()wm42019-10-312-0/+20
| | | | | | | | | | | To be used in the next commit. According to compiler explorer, __builtin_clz is very widely available, and it barely makes sense to provide a fallback. clang also eats this (and identifies at least as GCC 4). Actually, there's doubt that a fast log2 implementation is needed at all (I guess UTF-8 parsing needs it, but something UTF-8-specific would probably make it faster than using log2). So the fallback is just something naive.
* Replace uses of FFMIN/MAX with MPMIN/MAXwm42019-10-312-9/+9
| | | | And remove libavutil includes where possible.
* msg: always use terminal control codes for status linewm42019-10-241-6/+3
| | | | | | | | | | | Before this commit, the status line used terminal control codes only if stderr was a terminal. I'm not sure why this was done, and git blame tracks it back to a huge commit by me, which changed all of the terminal handling. A user complained, so just stop treating this specially for no reason. Fixes: #6617
* player: accept compatible later FFmpeg library runtime versionswm42019-10-111-1/+2
| | | | | | | | | | | | | | | | | | mpv warned if the FFmpeg runtime library version was not exactly the same as the build version. This seemed to cause frequent conflicts. At this point, most mpv code probably adheres to the FFmpeg ABI rules, and FFmpeg stopped breaking ABI "accidentally". Another source of problems were mixed FFmpeg/Libav installations, something which nobody does anymore. It's not "our" job to check and enforce ABI compatibility either. So I guess this behavior can be removed. OK, still check for incompatible libraries (according to FFmpeg versioning rules), i.e. different major versions, or if the build version is newer than the runtime version. For now. The comment about ABI problems is still true. In particular, the bytes_read field mentioned in the removed comment is still accessed, and is still an ABI violation. Have fun.
* av_log: use proper FFmpeg version extraction macroswm42019-10-111-1/+3
| | | | Though not like they will or can never change them.
* recorder: don't use a magic index for mp_recorder_get_sink()wm42019-09-292-5/+12
| | | | | | | | | | | | | | | | | | | 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.
* recorder: always mux all packets on discont/closewm42019-09-191-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the muxer used by all 3 stream recording features (why are there so many?). It tried hard to avoid writing broken files. In particular, it buffered packets until it new there was a keyframe packet (which, in mpv's/FFmpeg's definition, mean seek points from which decoding can resume), or final EOF. The danger that was probably considered here was that due to video frame reordering, not muxing some trailing, missing packets of a keyframe range could lead to broken decoding or skipped frames, so better discard packets belonging to an incomplete range. Sounds like a good idea so far. Unfortunately, this will drop an entire keyframe range even if the current packet run is complete and mp_recorder_mark_discontinuity() is called, simply because recorder.c can not know that the next packet would have been a keyframe. It seems better to mux all packets to avoid losing valid data, even if it means that sometimes packets/frames will be missing from the file. It benefits especially the dump-cache command, which will call the function to signal a discontinuity after every range. Before this commit, it discarded the last packets, even if they were perfectly fine. (An alternative solution for dump-cache would have been a second discontinuity marker function, that communicates that the current packet range is complete. But this commit's solution is simpler and overall more robust, at the danger of producing more semi-broken files.) This may make some of the complex buffering/waiting logic in recorder.c pointless. Untested (in this final form).
* recorder: use shared PTS macroswm42019-09-191-9/+7
| | | | | | | | These macros explicitly honor MP_NOPTS_VALUE, instead of implicitly relying on the fact that this value is the lowest allowed value. In addition, this changes one case to use MP_NOPTS_VALUE instead of INFINITY, also a cosmetic change.
* msg: remove unnecessary conditionwm42019-09-191-4/+0
| | | | Atomics were made mandatory some time ago.
* common: add macro for checking whether a value is a power of twowm42019-09-191-0/+1
| | | | | | | I think I repeated this inline in some places (or maybe not), and some experimental but discarded code used it. Add it anyway, maybe it'll be useful. Or it'll give someone a chance to get a contribution into mpv by removing an unused macro.
* common: add MP_IS_ALIGNED macrowm42019-09-191-0/+1
|
* demux: move timestamp helper macros to common.hwm42019-09-191-0/+8
| | | | These are probably generally useful.
* demux: use no overlapping packets for lossless audiowm42019-09-192-0/+9
| | | | | | Worthless optimization, but at least it justifies that the --audio-backward-overlap option has an "auto" choice. Tested with PCM and FLAC.
* encode: set sample_aspect_ratio on AVStream structekisu2019-08-141-0/+5
| | | | | Some libavformat muxers (e.g. matroskaenc.c) expect this field to be set on the AVStream struct, and not only in the AVCodecParameters.
* vo_gpu: vulkan: use libplacebo insteadNiklas Haas2019-04-212-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | This commit rips out the entire mpv vulkan implementation in favor of exposing lightweight wrappers on top of libplacebo instead, which provides much of the same except in a more up-to-date and polished form. This (finally) unifies the code base between mpv and libplacebo, which is something I've been hoping to do for a long time. Note: The ra_pl wrappers are abstract enough from the actual libplacebo device type that we can in theory re-use them for other devices like d3d11 or even opengl in the future, so I moved them to a separate directory for the time being. However, the rest of the code is still vulkan-specific, so I've kept the "vulkan" naming and file paths, rather than introducing a new `--gpu-api` type. (Which would have been ended up with significantly more code duplicaiton) Plus, the code and functionality is similar enough that for most users this should just be a straight-up drop-in replacement. Note: This commit excludes some changes; specifically, the updates to context_win and hwdec_cuda are deferred to separate commits for authorship reasons.
* demux: add another stream recording featurewm42018-12-061-2/+1
| | | | | | --record-file is nice, but only sometimes. If you watch some sort of livestream which you want to record, it's actually much nicer not to record what you're currently "seeing", but anything you're receiving.
* Merge commit '559a400ac36e75a8d73ba263fd7fa6736df1c2da' into ↵Anton Kindestam2018-12-055-18/+12
|\ | | | | | | | | | | wm4-commits--merge-edition This bumps libmpv version to 1.103
| * player: get rid of mpv_global.optswm42018-05-243-14/+4
| | | | | | | | | | | | | | | | This was always a legacy thing. Remove it by applying an orgy of mp_get_config_group() calls, and sometimes m_config_cache_alloc() or mp_read_option_raw(). win32 changes untested.
| * path: don't access global option structwm42018-05-241-0/+1
| | | | | | | | | | | | | | The path functions need to access the option that forces non-default config directories. Just add it as a field to mpv_global - it seems justified. The accessed options were always enforced as immutable after init, so there's not much of a change.
| * demux: get rid of free_demuxer[_and_stream]()wm42018-05-241-1/+1
| | | | | | | | | | | | | | Them being separate is just dumb. Replace them with a single demux_free() function, and free its stream by default. Not freeing the stream is only needed in 1 special case (demux_disc.c), use a special flag to not free the stream in this case.
| * command: make loadlist command async and abortablewm42018-05-242-3/+6
| | | | | | | | | | | | | | | | | | | | Don't allow it to freeze everything when loading a playlist from network (although you definitely shouldn't do that, but whatever). This also affects the really obscure --ordered-chapters-files option. The --playlist option on the other hand has no choice but to freeze the shit, because there's no concept of aborting the player during command line parsing.
* | encode: simplify encode_lavc_add_packetJan Ekström2018-10-011-2/+0
| | | | | | | | | | We're doing the same thing as the primary path - just that we log and set 'failed' to true.
* | encode: fix AVPacket deinitialization logicNiklas Haas2018-10-011-3/+4
|/ | | | | | | | | | | Since this function is called with packets on the stack, trying to free them makes no sense. Instead, it should unref (which is what `av_interleaved_write_frame` does anyway, rather than freeing). Also, the calling code tried unreffing the packet a second time, even after it was "freed" by the callee in the failure case - and after ownership was taken over by `av_interleaved_write_frame` in the successful case. Both of these cases were wrong.
* encode: get rid of the output packet queuewm42018-05-033-73/+85
| | | | | | | | | | | | Until recently, ao_lavc and vo_lavc started encoding whenever the core happened to send them data. Since audio and video are not initialized at the same time, and the muxer was not necessarily opened when the first encoder started to produce data, the resulting packets were put into a queue. As soon as the muxer was opened, the queue was flushed. Change this to make the core wait with sending data until all encoders are initialized. This has the advantage that we don't need to queue up the packets.
* encode: remove old timestamp handlingwm42018-05-032-12/+7
| | | | | This effectively makes --ocopyts the default. The --ocopyts option itself is also removed, because it's redundant.
* encode: restore 2-pass modewm42018-05-031-2/+7
| | | | | | | | | | While I'm not sure whether it really works, at least it writes the pass1 log correctly now. How 2-pass stat output is supposed to interact with the new decode API is rather fishy. ffmpeg.c does the same, and before this change, the log was not written on EOF (when at least libvpx actually outputs its stats).
* common: add missing %f time formatwm42018-05-011-0/+1
| | | | | | | | It was documented for --screenshot-template, but apparently never implemented. This value is not explicitly rounded, other than for printf() %f default formatting (which rounds to 6 digits).
* common: round all integer times to millisecondswm42018-05-011-2/+6
| | | | | | | | | This means that a time of 4.5678 is displayed as "00:00:04.568" when the format string is "%H:%M:%S.%T". Likewise, 59.99999 will be displayed as "00:01:00.000". Before this change, the sub-ms times were just truncated. Requested by TheAMM.
* f_lavfi: support setting common filter options like "threads"wm42018-04-292-2/+10
| | | | | | | | | AVFilterContext instances support some additional AVOptions over the actual filter. This includes useful options like "threads". We didn't support setting those for the "direct" wrapper (--vf=yadif:threads=1 failed). Change this. It requires setting options on the AVFilterContext directly, except the code for positional parameters still needs to access the actual filter's AVOptions.
* encode: rewrite half of itwm42018-04-294-706/+557
| | | | | | | | | | | | | The main change is that we wait with opening the muxer ("writing headers") until we have data from all streams. This fixes race conditions at init due to broken assumptions in the old code. This also changes a lot of other stuff. I found and fixed a few API violations (often things for which better mechanisms were invented, and the old ones are not valid anymore). I try to get away from the public mutex and shared fields in encode_lavc_context. For now it's still needed for some timestamp-related fields, but most are gone. It also removes some bad code duplication between audio and video paths.
* encode: get rid of AVDictionary setter helperwm42018-04-291-73/+13
| | | | | | | | | | | | Removes a good hunk of weird code. This loses qscale "emulation", some logging, and the fact that duplicate keys for values starting with +/- were added with AV_DICT_APPEND. I don't assign those any importance, even if they are user-visible changes. The new M_OPT_ flag is just