summaryrefslogtreecommitdiffstats
path: root/common
Commit message (Collapse)AuthorAgeFilesLines
* command: fix segfault with playlist-{next,prev}-playlistGuido Cella2023-10-131-1/+1
| | | | | | | | | | | | | | | | | | | | This was wrongly assuming that playlist_path is always set for the current playlist entry, but it's only set when a file was added by expanding a playlist. The crash in playlist_get_first_in_next_playlist can be reproduced with mpv foo.mkv foo.zip, playlist-next, playlist-prev, playlist-next-playlist. You need to run playlist-next, playlist-prev first because foo.zip's playlist_path is NULL until you do that, which makes playlist_get_first_in_next_playlist return immediately. The crash in cmd_playlist_next_prev_playlist can be replicated with mpv --loop-playlist foo.zip foo.mkv, running playlist-next until foo.mkv, and playlist-play-next. Again, you need to open foo.zip first or its playlist_path is NULL which skips running strcmp(entry->playlist_path, mpctx->playlist->current->playlist_path). Fixes https://github.com/mpv-player/mpv/issues/12495#issuecomment-1760968608
* command: add playlist-next-playlist and playlist-prev-playlistGuido Cella2023-10-092-0/+72
| | | | | | | | | | | | playlist-prev-playlist goes to the beginning of the previous playlist because this seems more useful and symmetrical to playlist-next-playlist. It does not go to the beginning when the current playlist-path starts with the previous playlist-path, e.g. with mpv --loop-playlist foo/, which expands to foo/{1..9}.zip, the current playlist path foo/1.zip beings with the playlist-path foo/ of {2..9}.zip and thus playlist-prev-playlist goes to 9.zip rather than to 2.zip. Closes #12495.
* loadfile: fix an old wonky playlist heuristicDudemanguy2023-10-051-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2c6a3cb1f27e02b2e66390a2465ab648905a64d0 originally added this struct member and then 1be863afdbe9017aa227234e8525b209fb818224 later added some more logic to loadfile that uses this. There's been more changes since then of course, but bits using playback_short and playback_start have mostly stayed the same. It's a bit strange it's worked this way for so long since it makes an assumption on how long files should be and leads to weird, broken behavior on playlists with shorter videos. The main reason for playlist_short, as far as I can tell, is to deal with some fringe cases with short videos and trying to go back in the playlist. More specifically, if you use --loop=inf on a very short video (say less than 1 second) and try to go back in the playlist, you won't be able to without any of this special logic that deals with it. But the current approach has several side effects like going back multiple items in the playlist instead of just one if the video is less than one second. This is just bad so delete everything related to playlist_short and playlist_start. Instead, let's handle this by keeping track of playlist-prev attempts. Going forward in the playlist doesn't require any special handling since a bad/broken file will just advance to the next one. So it's only going backwards that requires some special consideration. If we're going backwards and the user isn't using force, then mark the playlist entry with a special flag. If the file loads successfully in play_current_file, we can just clear the flag and not worry about it. However if there's a failure, then we set a bool telling play_current_file that it should go back one more item in the playlist if possible and try again. This way, we avoid the previously mentioned --loop=inf edgecase and the user can still attempt to retry previously failed items in the playlist (like a url or such). Fixes #6576, fixes #12548.
* msg: use nanosecond precisionDudemanguy2023-09-291-3/+3
| | | | | | | | | | The timestamps when making a log file is actually dependent on MP_START_TIME. This is a 10 microsecond offset that was added to the timer as an offset. With the nanosecond change, this unit needs to be converted as well so the offset is the same as before. After doing that, we need to change the various mp_time_us calls in msg to mp_time_ns and do the right conversion. This fixes the logs timestamps (i.e. so they aren't negative anymore).
* win32/pthread: define _POSIX_TIMERS to notify they are not supportedKacper Michajłow2023-09-291-2/+1
|
* recorder: fix a couple of memory leaksDudemanguy2023-09-261-7/+16
| | | | Not sure how long these have been around but it leaked on every packet.
* options: remove a few options marked with .deprecation_messageDudemanguy2023-09-213-23/+0
| | | | | | | | | | | A bit different from the OPT_REPLACED/OPT_REMOVED ones in that the options still possibly do something but they have a deprecation message. Most of these are old and have no real usage. The only potentially controversial ones are the removal of --oaffset and --ovoffset which were deprecated years ago and seemingly have no real replacement. There's a cryptic message about --audio-delay but who knows. The less encoding mode code we have, the better so just chuck it.
* options: remove ancient option fallbacks/deprecationDudemanguy2023-09-211-7/+0
| | | | | | | | | | | | | We've got an ungodly amount of OPT_REPLACED and OPT_REMOVED sitting around in the code. This is harmless, but the vast majority of these are ancient. 26f4f18c0629998a9b91e94722d166866d8b80a3 is the last commit that touched the majority of these and of course that only changed how options were declared so all of this stuff was deprecated even before that. No use in keeping these, so just delete them all. As an aside, there was actually a cocoa_opts but it had only a single option which was replaced by something else and empty otherwise. So that entire thing was just simply removed. OPT_REPLACED/OPT_REMOVED declarations that were added in 0.35 or later were kept as is.
* various: add missing include in header fllesllyyr2023-09-211-0/+1
| | | | Mostly cosmetic
* vo: add --video-cropKacper Michajłow2023-08-312-0/+32
| | | | | | Just cropping by VO that works with hwdec. Fixes: #12222
* common: constify mp_rect_equalsKacper Michajłow2023-08-312-2/+2
|
* playlist: remove unused code to track redirectsGuido Cella2023-08-282-19/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out that the code to track redirects (playlists and directories) never worked correctly, only the last redirect is remembered and num_redirects is never greater than 1. You can see this by doing quit-watch-later with the old watch later system, before dbf244fd2f, on a m3u playlist of files and a m3u playlist of directories. Only in the first case a redirect entry for the m3u file is created, because in the second case the m3u redirect is replaced by the directory one. If you did mpv --directory-mode=lazy /foo it did create redirect entries for all subdirectories e.g. /foo/bar, /foo/bar/baz, /foo/bar/baz/qux, this made it seem like it worked correctly, but actually /foo/bar/bar/qux was the only redirect entry and thus it was considered as the first redirect, and mpv created redirect entries for each segment of the first redirect only. In the previous commit dbf244fd2f, rather than figuring out how to fix the code to track redirects, and since creating redirect entries for multiple redirects is overkill, I just used the new playlist-path property which does the same thing but only for the last redirect. By replacing the only other use of the old redirect code with playlist-path, we can remove it.
* player: add playlist-path propertiesDudemanguy2023-08-132-0/+10
| | | | | | | | | | | | A bit of a long standing pain with scripting is that when opening a file that gets interpreted as a playlist (like an m3u), the original path of the file gets thrown away later. Workarounds basically consist of getting the filename before mpv expands the path, but that's not really reliable. Instead of throwing it away, save the original playlist path by copying to the playlist entries when applicable (demuxer playlist and the playlist option). Then expose these as properties: playlist-path for the currently playing entry and playlist/N/playlist-path for each specific entry. Closes #8508, #7605.
* version: move NO_BUILD_TIMESTAMPS check to version.h.inKacper Michajłow2023-08-022-5/+5
|
* build: remove version.pyKacper Michajłow2023-08-022-0/+11
| | | | | | | | | | | | | After second thought version.py does not do anything useful. Meson has built-in function vcs_tag that mostly replicate what version.py did. For the build time we can just use __DATE__ and __TIME__. Of course this changes time string format a little, but in my opinion it looks nicer in fact. Also it will use local time, instead UTC. But I would argue that date string is only informative for users to check how old the specific mpv build is. It doesn't have to be precise, it weren't for years anyway before recent change.
* build: remove outdated generated directoryDudemanguy2023-07-311-1/+1
| | | | | | | | | | | | | | | | This only existed as essentially a workaround for meson's behavior and to maintain compatibility with the waf build. Since waf put everything in a generated subdirectory, we had to put make a subdirectory called "generated" in the source for meson so stuff could go to the right place. Well now we don't need to do that anymore. Move the meson.build files around so they go in the appropriate place in the subdirectory of the source tree and change the paths of the headers accordingly. A couple of important things to note. 1. mpv.com now gets made in build/player/mpv.com (necessary because of a meson limitation) 2. The macos icon generation path is shortened to TOOLS/osxbundle/icon.icns.inc.
* encode_lavc: fix leak of codecparsfan52023-07-261-0/+1
|
* msg: print MSGL_WARN and higher error messages to stderrDudemanguy2023-07-241-1/+2
| | | | | | | | mpv has a convention of printing everything to stdout. The reasons for this are pretty unclear and in certain situations rather unintuitive. It leads to some bad behavior in fringe cases with encoding mode and isn't the norm for programs so just adjust it so warnings and up are printed to stderr. Fixes #8608.
* path: simplify "cache" and "state" fallbacksfan52023-05-211-2/+0
| | | | Instead of having more global state just do it on-the-fly.
* player: use XDG_CACHE_HOME by defaultDudemanguy2023-05-091-0/+1
| | | | | | | | | | | | This adds cache as a possible path for mpv to internally pick (~/.cache/mpv for non-darwin unix-like systems, the usual config directory for everyone else). For gpu shader cache and icc cache, controlling whether or not to write such files is done with the new --gpu-shader-cache and --icc-cache options respectively. Additionally, --cache-on-disk no longer requires explicitly setting the --cache-dir option. The old options, --cache-dir, --gpu-shader-cache-dir, and --icc-cache-dir simply set an override for the directory to save cache files. If unset, then the cache is saved in XDG_CACHE_HOME.
* player: use XDG_STATE_HOME for watch_laterDudemanguy2023-05-091-0/+1
| | | | | | | | | | | | | | | | | | A pain point for some users is the fact that watch_later is stored in the ~/.config directory when it's really not configuration data. Roughly 2 years ago, XDG_STATE_DIR was added to the XDG Base Directory Specification[0] and its description, user-specific state data, actually perfectly matches what watch_later data is for. Let's go ahead and use this directory as the default for watch_later. This change only affects non-darwin unix-like systems (i.e. Linux, BSDs, etc.). The directory doesn't move for anyone else. Internally, quite a few things change with regards to the path selection. If the platform in question does not have a statedir concept, then the path selection will simply return "home" instead (old behavior). Fixes #9147. [0]: https://gitlab.freedesktop.org/xdg/xdg-specs/-/commit/4f2884e16db35f2962d9b64312917c81be5cb54b
* common/av_common: clean up mp_lavc_set_extradataJan Ekström2023-03-142-15/+0
| | | | | It no longer has any users, as the last ones (subtitle decoders) were switched to mp_set_avctx_codec_headers.
* common/av_common: constify mp_codec_params related gettersJan Ekström2023-03-142-6/+6
| | | | | | They should not be modifying the argument, so clearly marking it as const makes sure we don't do it in the future as well as allows for read-only optimizations.
* options: transition options from OPT_FLAG to OPT_BOOLChristoph Heinrich2023-02-212-9/+9
| | | | | | c78482045444c488bb7948305d583a55d17cd236 introduced a bool option type as a replacement for the flag type, but didn't actually transition and remove the flag type because it would have been too much mundane work.
* various: drop unused #include "config.h"Thomas Weißschuh2023-02-202-2/+0
| | | | | | Most sources don't need config.h. The inclusion only leads to lots of unneeded recompilation if the configuration is changed.
* msg: log-file set at mpv.conf: don't ignore early messagesAvi Halachmi (:avih)2023-01-231-9/+74
| | | | | | | | | | | | | | | | | Previously, if log-file was set not via a CLI option (e.g. set via mpv.conf or other config file, or set from a script init phase), then meaningful early log messages were thrown away because the log file name was unknown initially. Such early log messages include the command line arguments, any options set from mpv.conf, and possibly more. Now we store up to 5000 early messages before the log file name is known, and flush them once/if it becomes known, or destroy this buffer once mpv init is complete. The implementation is similar and adjacent, but not identical, to an existing early log system for mpv clients which request a log buffer.
* msg: log-file buffer size: don't use magic number (no-op)Avi Halachmi (:avih)2023-01-231-1/+3
|
* various: replace abort() with MP_ASSERT_UNREACHABLE() where appropriatesfan52023-01-121-1/+1
| | | | | | | | In debug mode the macro causes an assertion failure. In release mode it works differently and tells the compiler that it can assume the codepath will never execute. For this reason I was conversative in replacing it, e.g. in mpv-internal code that exhausts all valid values of an enum or when a condition is clear from directly preceding code.
* player: add video-sync=display-tempoChristoph Heinrich2023-01-091-0/+2
| | | | | | | | So far there was no way to sync video to display and have audio sync to video without changes in pitch. With this option the audio does not get resampled (pitch change) and instead the corrected audio speed is applied to audio filters.
* ffmpeg: update to handle deprecation of `av_init_packet`Philip Langdale2022-12-033-8/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This has been a long standing annoyance - ffmpeg is removing sizeof(AVPacket) from the API which means you cannot stack-allocate AVPacket anymore. However, that is something we take advantage of because we use short-lived AVPackets to bridge from native mpv packets in our main decoding paths. We don't think that switching these to `av_packet_alloc` is desirable, given the cost of heap allocation, so this change takes a different approach - allocating a single packet in the relevant context and reusing it over and over. That's fairly straight-forward, with the main caveat being that re-initialising the packet is unintuitive. There is no function that does exactly what we need (what `av_init_packet` did). The closest is `av_packet_unref`, which additionally frees buffers and side-data. However, we don't copy those things - we just assign them in from our own packet, so we have to explicitly clear the pointers before calling `av_packet_unref`. But at least we can make a wrapper function for that. The weirdest part of the change is the handling of the vtt subtitle conversion. This requires two packets, so I had to pre-allocate two in the context struct. That sounds excessive, but if allocating the primary packet is too expensive, then allocating the secondary one for vtt subtitles must also be too expensive. This change is not conditional as heap allocated AVPackets were available for years and years before the deprecation.
* common/av_log: move general FFmpeg version before library versionsJan Ekström2022-11-151-2/+1
| | | | | This way another library can be logged before FFmpeg without it looking weird.
* misc/random: add xoshiro random number implementationLeo Izen2022-08-171-1/+2
| | | | | | | Add xoshiro as a PRNG implementation instead of relying on srand() and rand() from the C standard library. This, in particular, lets us avoid platform-defined behavior with respect to threading.
* common/av_common: switch to AVChannelLayout when availableJan Ekström2022-06-121-0/+6
|
* player: rearrange video sync opts/enums/definesDudemanguy2022-04-111-0/+18
| | | | | | | | | | | | | | | | | The video sync logic for mpv lies completely within its core at essentially the highest layer of abstraction. The problem with this is that it is impossible for VOs to know what video sync mode mpv is currently using since it has no access to the opts. Because different video sync modes completely changes how mpv's render loop operates, it's reasonable that a VO may want to change how it renders based on the current mode (see the next commit for an example). Let's just move the video sync option to mp_vo_opts. MPContext, of course, can still access the value of the option so it only requires minor changes in player/video.c. Additionally, move the VS_IS_DISP define from to player/core.h to common/common.h. All VOs already have access to common/common.h, and there's no need for them to gain access to everything that's in player/core.h.
* common/av_log: explicitly include version.h for required librariesLeo Izen2022-03-171-0/+6
| | | | | | | | | | | FFmpeg recently split version.h into version.h and version_major.h, and no longer automatically includes version.h in avcodec.h (and the other libraries). This should allow mpv to build against ffmpeg git master. See FFmpeg/ffmpeg@f2da2e1458b76a1d6c068673430b46cf2850bc51 These headers are not new, so their inclusion should not affect backwards compatibility.
* encode_lavc: replace deprecated av_init_packet()sfan52022-01-102-5/+9
|
* build: add meson build supportDudemanguy2021-11-141-1/+2
| | | | | | Adds support for the meson build system as well as a bit of documentation. Compatibility with the existing waf build is maintained.
* recorder: add support for attachments (fonts)TheAMM2021-07-082-2/+37
| | | | | | Though, only when the output format is matroska, to avoid muxing errors. This is quite useful when the input has ASS subtitles, as they tend to rely on embedded fonts.
* recorder: ignore packet queue in mux_packets()TheAMM2021-07-081-19/+8
| | | | | | | | | | | | I've looked and studied the flow in the recorder, and to my understanding, the packet queue is moot after the initial sync, maybe even then - but that's beyond me right now. With the previous choice to mux trailing packets whatever the case, this doesn't result in any new ill effects (and some missing packets at the end is no big deal). Notably, since we don't have to hold onto the packets after we get muxing, we'll never run into any issues with veeery long GOPs filling up our queue (resulting in dropped packets and much user chagrin).
* av_common: trim FLAC extradata when copying codec paramsTheAMM2021-07-081-4/+15
| | | | | | | | | | | | | | | | For muxing, FFmpeg expects the FLAC extradata to be just the bare STREAMINFO, and passing the full FLAC extradata (fLaC header and block size, with any additional channel layout metadata) will result in malformed output, as ffmpeg will simply prefix another fLaC header in front. This can be considered to be a bug. FFmpeg's own demuxers only store the STREAMINFO, hence the naivety, while our common source of FLAC streams, the matroska demuxer, holds onto the full extradata. It has been deemed preferable to adjust the extradata upon muxing, instead of in the demuxer (ffmpeg's FLAC decoder knows to read the full fLaC extradata). This fixes muxing FLAC streams, meaning recorder.c or dump-cache.
* recorder: clear packet queue after they've been muxedTheAMM2021-07-081-1/+1
| | | | | | | | | | | | | In commit f7678575a5d7f598abf267cb303e0a74db276f27, wm4 chooses to mux all remaining packets when mp_recorder_mark_discontinuity() is called and adds a call to mux_packets(). However, it is called only after flush_packets(), which clears the packets before they can be muxed out. This has no ill effects per se - recordings end on keyframes, as before - but judging from his commit message, the intention explicitly was to output the inter frames, since long GOPs can mean several seconds of missing content from the output. So, clear the stream packet queues only after the final mux. Also, flushing can mean both discarding and committing. What a country!
* recorder: fix codec_tag / codec_id confusionTheAMM2021-05-261-2/+2
|
* recorder: clear codec_tag if no target format supportTheAMM2021-05-261-0/+6
| | | | | | | Avoiding blindly copying the codec_tag between different formats allows us to mux packets from, say, mpegts streams to matroska, making the recorder (dump-cache) much more usable as unsupported codec_tags can make the muxer reject the streams.
* build: address AVCodec, AVInputFormat, AVOutputFormat const warningssfan52021-05-013-7/+7
| | | | FFmpeg recently changed these to be const on their side.
* msg: fix really-quiet option to only affect terminal outputder richter2021-02-231-2/+2
| | | | | | | | | | | | if log-file and really-quiet options were used together it could lead to a completely empty log-file. this is unexpected because we need the log-file option to work in all cases and produces at least a log of verbosity -v -v. this is a regression of commit a600d152d21ef398eb72b008ee3fe266696eb638 move the really quiet check back up, so it's set before the evaluation of the actual log level, where check for log file, terminal, etc take place.
* msg: make --msg-time show time in secondswm42020-09-181-1/+1
| | | | | More readable, similar to what --log-file will use (although the terminal code shows microseconds and uses less left padding).
* encode: disable unsupported media types automaticallywm42020-09-032-18/+47
| | | | | | | If you encode to e.g. an audio-only format, then video is disabled automatically. This also takes care of the very cryptic error message. It says "[vo/lavc] codec for video not found". Sort of true, but obscures the real problem if it's e.g. an audio-only format.
* encode: remove early EOF failure handlingwm42020-09-032-27/+0
| | | | | | | I don't see the point of this. Not doing it may defer an error to later. That's OK? For now, it seems better to reduce the encoding internal API. If someone can demonstrate that this is needed, I might reimplement it in a different way.
* encode: undeprecatewm42020-08-291-2/+1
| | | | I guess the audio timestamp corruption problem is probably solved now.
* audio: refactor how data is passed to AOwm42020-08-293-20/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This replaces the two buffers (ao_chain.ao_buffer in the core, and buffer_state.buffers in the AO) with a single queue. Instead of having a byte based buffer, the queue is simply a list of audio frames, as output by the decoder. This should make dataflow simpler and reduce copying. It also attempts to simplify fill_audio_out_buffers(), the function I always hated most, because it's full of subtle and buggy logic. Unfortunately, I got assaulted by corner cases, dumb features (attempt at seamless looping, really?), and other crap, so it got pretty complicated again. fill_audio_out_buffers() is still full of subtle and buggy logic. Maybe it got worse. On the other hand, maybe there really is some progress. Who knows. Originally, the data flow parts was meant to be in f_output_chain, but due to tricky interactions with the playloop code, it's now in the dummy filter in audio.c. At least this improves the way the audio PTS is passed to the encoder in encoding mode. Now it attempts to pass frames directly, along with the pts, which should minimize timestamp problems. But to be honest, encoder mode is one big kludge that shouldn't exist in this way. This commit should be considered pre-alpha code. There are lots of bugs still hiding.
* build: change filenames of generated fileswm42020-06-041-1/+1
| | | | Force them into a more consistent naming schema.
* player: add --term-title optionwm42020-05-252-0/+11