summaryrefslogtreecommitdiffstats
path: root/player
Commit message (Collapse)AuthorAgeFilesLines
* player/loadfile: remove blank line on exitKacper Michajłow2023-11-081-1/+0
|
* Revert "player: cut off status line on terminal width"Kacper Michajłow2023-11-081-5/+0
| | | | | | | No longer needed, wrapped status line is supported now. Also this didn't work correctly if status were decorated with module name or time. This reverts commit ab6fac43b4bc34949bd9c4da8e911fc9f3489a32.
* Revert "player: don't print status line again when quitting"Kacper Michajłow2023-11-081-5/+2
| | | | | | This workaround is not longer needed. This reverts commit cdc05c33b33d958a8877851bd5942adbb856f5e4.
* stats.lua: disable ASS formatting when printing to terminalKacper Michajłow2023-11-081-1/+1
|
* vo: replace VOCTRL_HDR_METADATA with direct VO params readKacper Michajłow2023-11-082-8/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently VOCTRL are completely unusable for frequent data query. Since the HDR parameter addition to video-params, the parameters can change each frame. In which case observe on those parameter would be triggered constantly. The problem is that quering those parameters involves VOCTRL which in turn involves whole render cycle of delay. Instead update VO params on each draw_frame. This requires changes to VO reconfiguration condition, but in practice it should only be triggered when image size or data layout changes. In other cases it will be handled internal by VO driver. I'm not quite happy with this solution, but don't see better one without changing observe/notify logic significantly. There is no good way currently to handle VOCTRL that are constantly queried. This adds unfortunate synchronization of player command with VO thread, but there is not way around that and if too frequent queries of this param becomes a problem we can thing of other solutions. Changes the way to get data from VO driver added by a98c5328dc Fixes: 84de84b Fixes: #12825
* stats.lua: remove unused variableGuido Cella2023-11-071-3/+0
| | | | 056072bf95 deleted the only use of property_list.
* console.lua: don't print the console log to the OSD when switching VOGuido Cella2023-11-071-1/+8
| | | | Fixes #12735, fixes #12839.
* player/command: handle force window on runtime vo changesDudemanguy2023-11-071-0/+1
| | | | | Without this, changing the vo at runtime with --force-window --idle would kill the vo.
* stats: don't overwrite color and alpha of `osd-back-color`Christoph Heinrich2023-11-071-4/+6
|
* console: don't overwrite color and alpha of `osd-back-color`Christoph Heinrich2023-11-071-2/+3
|
* player/command: fix typo in sig-peak value computationKacper Michajłow2023-11-071-1/+1
| | | | Fixes: 73fbe09a49d3ed00c6e19fdcc658802f28974ae2
* console: wrap rows at the topChristoph Heinrich2023-11-071-8/+6
| | | | | | | | | | The previous commit was already a big improvement, but it was still somewhat slow on the lua interpreter. By wrapping the table at the top we loose the consistent placement of items while resizing (at least as long as the column count didn't change), but we avoid taking all the off screen items into account. The fewer items fit on screen the faster this becomes.
* console: optimize table generationChristoph Heinrich2023-11-071-20/+32
| | | | | | | | | | | Showing all properties was terribly slow. Instead of starting at one row and increasing the row count until it fits, the column count can be increased until it doesn't fit anymore. That alone already reduces the required iterations, but from the column count an upper and lower bound for the row count can be calculated. For large tables this dramatically reduces the amount of iterations.
* console: enable completions without a prefixChristoph Heinrich2023-11-071-4/+4
| | | | | | This way it is possible to get a list of all options or all properties, instead of having to guess the first letter before any suggestions are shown.
* console.lua: complete raw propertiesGuido Cella2023-11-071-1/+1
|
* console: avoid redundant completion appendageChristoph Heinrich2023-11-071-2/+36
| | | | | | So far completing something like `${some-pro}` with the cursor between `o}` would result in `${some-property}}`. Adding that superfluous `}` can be avoided by checking if it's already in the string after the cursor.
* sub: adjust offsets when sub seeking/steppingDudemanguy2023-11-061-6/+6
| | | | | | | | | | | | | | | | | | | | | In the sub seek code path, there was an arbitrary small offset added to the pts before the seek. However when seeking backwards, the offset was an additional subtraction. de6eace6e984be3cd2515e9be6362a0cf04b7457 added this logic 10 years ago and perhaps it made sense then, but the additional subtraction when seeking backwards causes the subtitle seek to go too far to the previous subtitle if the durations overlap. This should always be an addition to work correctly. Additionally, the sub stepping code path also could use this offset for the same reason (duration overlaps). However, it is only applicable to sd_ass not sd_lavc. sd_lavc has step_sub support but on a sample it didn't even work anyway. Perhaps it only works for certain kinds of subtitles (patches welcome). Anyways instead of keeping this offset as a magic number, we can define it in sd.h which is handy for this. For sd_ass, we add the offset when sub stepping, and the offset is always added for sub seeking like it was before. Update the comment to be a little more relevant to what actually happens today. Fixes #11445.
* ytdl_hook: fix mixed thumbnail.preference availabilityChristoph Heinrich2023-11-061-1/+1
|
* video: reset `display_sync_error` when resetting statellyyr2023-11-061-0/+1
| | | | | | | | | | This would cause mpv to, in some very specific scenarios, have a negative vsync_offset after seeking which would result in mpv requesting a pts before the first frame to libplacebo. Fix it by setting it to 0 when we reset state, such as after seeking. Fixes: https://github.com/mpv-player/mpv/issues/12813
* player/command: add video-params and siblings to MPV_EVENT_TICKKacper Michajłow2023-11-051-1/+1
| | | | It contains metadata that may change per frame.
* ALL: use pl_hdr_metadata and nuke sig_peakKacper Michajłow2023-11-052-6/+1
| | | | | | | | This commit replaces all uses of sig_peak and maps all HDR metadata. Form notable changes mixed usage of maxCLL and max_luma is resolved and not always max_luma is used which makes vo_gpu and vo_gpu_next behave the same way.
* player/command: remove hdr-metadata propertyKacper Michajłow2023-11-051-37/+0
| | | | | It is now included in video-out-params and was never released in stable version, so we can safely remove it.
* csputils: add pl_hdr_metadata to mp_colorspace and deprecate sig_peakKacper Michajłow2023-11-052-6/+25
| | | | | Note this commit does not change all uses of sig-peak, this is for future refactoring.
* player/command: use pl_hdr_metadata_containsKacper Michajłow2023-11-051-5/+3
|
* csputils: change mp_hdr_metadata to pl_hdr_metadataKacper Michajłow2023-11-051-1/+1
|
* mp_thread: add win32 implementationKacper Michajłow2023-11-052-2/+0
|
* mp_thread: prefer tracking threads with idKacper Michajłow2023-11-053-10/+9
| | | | | | | | | | | | | | This change essentially removes mp_thread_self() and instead add mp_thread_id to track threads and have ability to query current thread id during runtime. This will be useful for upcoming win32 implementation, where accessing thread handle is different than on pthreads. Greatly reduces complexity. Otherweis locked map of tid <-> handle is required which is completely unnecessary for all mpv use-cases. Note that this is the mp_thread_id, not to confuse with system tid. For example on threads-posix implementation it is simply pthread_t.
* ALL: use new mp_thread abstractionKacper Michajłow2023-11-056-140/+137
|
* sub: redecode cached packets on UPDATE_SUB_HARD or UPDATE_SUB_FILTDudemanguy2023-11-051-5/+4
| | | | | | | | | | | | | | | | UPDATE_SUB_HARD causes all of the ass objects to reset in order to apply the new style. UPDATE_SUB_FILT doesn't actually reset the sd, but it should in order to update the actual filters so that was added here. Doing this causes the current subtitle to be dropped. In the paused cause, this concidentally works because command.c forces a video refresh which then reloads the subtitle essentially. But while playing, the subtitle will be dropped and you won't get anything until the next one appears. Instead of using video refreshes, what we can do is just always save the last two subtitle packets in a cache and redecode them if needed. This is much easier and also allows us to get rid of all the video refresh logic in command.c. Fixes #12386.
* lua: remove a ton of unneeded parenthesesDudemanguy2023-11-025-147/+146
| | | | | | | | | | | For whatever reason, some of the lua code (particularly the osc and ytdl_hook) is full of a bunch of stuff like if (foo), if not (foo == nil), etc. The parenthesis aren't needed in lua and actually just look weird since nobody actually writes lua like this. You can see most of the other conditionals are written normally. So cleanup the style to match when the parenthesis clearly aren't doing anything. Not directly related, but also add some spaces on a few math operations while we're at it.
* console.lua: complete file pathsGuido Cella2023-11-021-0/+44
|
* console.lua: complete list option verbsGuido Cella2023-11-021-0/+18
|
* console.lua: inline mp.optionsGuido Cella2023-11-021-2/+1
| | | | | | This avoids a "Redefined local `options`" LSP warning in list_option_list() after the previous commit. It still works, but reusing names for local variables is error-prone.
* console.lua: complete list optionsGuido Cella2023-11-021-0/+22
|
* console.lua: complete profilesGuido Cella2023-11-021-0/+12
|
* console.lua: complete commands after helpGuido Cella2023-11-021-1/+9
| | | | And complete help itself.
* console: complete infinite cycle-values argumentsChristoph Heinrich2023-11-011-24/+4
| | | | | cycle-values already completed the first two arguments, but the command accepts infinitely many arguments, so enable completion for all of them.
* player/main: set main thread name as mpvKacper Michajłow2023-11-011-1/+1
| | | | | Now that we don't prepend `mpv/` to all thread names, `main` is too ambiguous and since it is main thread it can be seen as process name.
* player/video: loosen logic checks for adjust_syncDudemanguy2023-10-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the av sync change calculation was only done if the audio_status was STATUS_PLAYING, but there is at least one or two more states where this should be done. player/audio is capable of adding delay if the state is anything besides STATUS_EOF. This means that while calling adjust_sync, the delay value could have changed from the audio side of the equation from the previous playloop, and it doesn't necessarily mean that the current audio_status is STATUS_PLAYING either. So the old code would technically skip this case. In practice, this is just one frame so it hardly matters, but it should be taken into account. For example, STATUS_READY is definitely possible here in adjust_sync. I'm not sure if it's actually possible for STATUS_SYNCING to happen but the audio code can change add delay with that status, so it doesn't hurt. STATUS_DRAINING is probably not relevant, but again include it to mirror the audio code logic. Of course, STATUS_EOF is obviously a no-no since that means no audio at all, so we return from there. I didn't take hard measurements or anything, but this does seem to result in slightly smaller av sync fluctuations on discontinuities (like seeking) which makes sense because we're now making an additional correction that wasn't previously done. Another change is to always try adjust_sync as long as the frame_time is nonzero. The old logic only did this if the video_status was playing or greater, but it is possible to get new frames with a different PTS that do not have that status. The audio is still playing so logically it should be adjusted as well. Again, this happens for just one frame, so it doesn't really matter in practice but it should make more sense. A zero frame_time is skipped since that would mean the pts did not advance and the previous playloop should have done the adjustment for that time already.
* player/video: don't reset ao on video chain reinitDudemanguy2023-10-301-8/+4
| | | | | | | | | | | | | | | | | | | | 3038e578af5b06129c2dd98cffeede7cdf8db700 recently changed the logic here so it wouldn't trigger on still images, but after thinking about the code here some more, I don't believe it's needed at all. Doing an ao reset when you flip the video track is very disruptive and not really desirable at all. Since the ao no longer adds bogus delay values while the video is off, there should be no need to do a full reset for syncing reasons. The delay value will be zero, so we can let the audio just play normally and let the video code do its thing. There is one slight trick here however. When using a display sync mode, part of the syncing code will try to update the audio and video playback speed. This can cause an audio underrun if we're just turning the video back one. An easy way to avoid most of these is to not update the speed if we are in the STATUS_SYNCING state for video. This isn't quite perfect and underruns are still possible, but it actually seems to depend on the AO. e.g. I couldn't trigger an underrun with alsa but I could with pipewire. In any case, the audio artifact here is much less noticeable than doing a full ao reset, so it's still an improvement.
* ytdl_hook: reverse thumbnail orderChristoph Heinrich2023-10-301-1/+2
| | | | | | ytdl lists thumbnails in ascending order according to height/preference. all_formats=yes adds formats from best to worst, so the same should also be done for thumbnails.
* ytdl_hook: support the preference field of thumbnailsChristoph Heinrich2023-10-301-1/+4
| | | | | | | yt-dlp has a preference field for it's thumbnails, and not all of it's listed thumbnails have fields with their dimensions. Therefore prefere the preference field when available and fall back to height if it's not.
* ytdl_hook: add thumbnail optionChristoph Heinrich2023-10-301-12/+6
| | | | | Opening speed could be improved with the "async" prefix, but then the tracks would be out of order.
* ytdl_hook: support thumbnailsEva2023-10-301-3/+36
| | | | | | Similar to "write-sub=", adding "write-thumbnail=" to raw-options will add the highest resolution thumbnail as a video track. Closes #7041
* scripting: add 'script' to messagesKacper Michajłow2023-10-271-2/+2
|
* scripting: rename backend names for concise namingKacper Michajłow2023-10-273-5/+4
|
* mp_threads: rename threads for consistent naming across all of themKacper Michajłow2023-10-273-4/+6
| | | | | | | | I'd like some names to be more descriptive, but to work with 15 chars limit we have to make some sacrifice. Also because of the limit, remove the `mpv/` prefix and prioritize actuall thread name.
* player/lua: use mp_msg_find_level in check_loglevelKacper Michajłow2023-10-271-4/+3
| | | | | Fixes off by one error. Allows to use MSGL_STATS, but since this is internal value, this is mostly cosmetic change.
* player/audio: fix incorrect check on adding delayDudemanguy2023-10-261-1/+1
| | | | | | | | | | | | dac977193cccbf7e2e999cf0c4b0292314839c4c changed adding delay to only when the video is playing but this isn't correct. The video frames adjust themselves based on the audio, so if we still have audio processing while the video itself happens to be in some non-playing state (such as STATUS_READY), the delay still needs to be taken into account. The correct thing to check is to make sure that it is not STATUS_EOF. STATUS_EOF covers the case where we have still image, and of course no video at all is STATUS_EOF. So having a massive bogus delay value is still avoided.
* javascript: use --js-memory-report option instead of MPV_LEAK_REPORTDudemanguy2023-10-261-2/+1
| | | | | | | | The MPV_LEAK_REPORT environment variable was previously read in order to determine whether or not to enable memory reporting for javascript scripts. This is kind of weird and deviates from the norm of exposing an option to the user. So let's just add --js-memory-report and disable it by default instead.
* options: rename --watch-later-directory to --watch-later-dirDudemanguy2023-10-251-1/+1
| | | | Same logic as the previous commit.
* options: rename --screenshot-directory to --screenshot-dirDudemanguy2023-10-251-1/+1
| | | | | Less characters is better? Other options use -dir for directory so consistency I guess.
* player: don't calculate av delay if there's no audio or videoDudemanguy2023-10-252-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The point of the mpctx->delay field is for calculating a/v sync and adjusting the frame timings appropriately. However, the frame_time was always subtracted from mpctx->delay regardless of the audio status. This meant that for a video with no audio, every single frame had a subtraction with nothing ever added to it meaning that you get massive negative delay times. For weird videos where the audio starts way later, the massive delay leads to the VO sleeping for basically about as long as the video was previously playing without audio. This results in nothing being rendered during that brief period of time and just overall badness. When using display-sync, it happens to work since the video doesn't adjust itself based on audio and it renders anyway. The fix is to simply not touch mpctx->delay in player/video.c unless there's actually audio playing. This is what the rest of the code already does aside from setting it to 0 on resets or EOFs. Move the calculation into adjust_sync after the audio status check. It works exactly the same as before except that we don't constantly subtract bogus values when there's no audio playing. The reverse situation in player/audio.c also has the same issue. For something that is only audio, mpctx->delay is always added to but nothing will ever subtract from it. It's not really clear if this particular version could ever cause a real bug, but logically it needs to be guarded in the same way. The field here should only be updated if the video is actually playing. Fixes #12025.
* console.lua: complete choice and flag optionsGuido Cella2023-10-251-4/+46
|
* console.lua: remove unused capture from completion patternsGuido Cella2023-10-251-12/+12
| | | | | | The end position of the word to be completed is never used because all patterns end with $. Remove it or it would complicate implementing completers with more patterns.
* console.lua: use string.match()Guido Cella2023-10-251-3/+3
| | | | Avoids the 2 unneeded return values of string.find().
* console.lua: generate completion lists lazilyGuido Cella2023-10-251-25/+37
| | | | | | This will allow providing more nested completions without pre-generating an enormous amount of completions, and it is more efficient since it only generates the completions needed for each completion attempt.
* console.lua: remove repetition from build_completers()Guido Cella2023-10-251-11/+16
|
* console.lua: remove unnecessary copyGuido Cella2023-10-251-4/+1
|
* sub: update subtitles if current track is an imageDudemanguy2023-10-231-1/+1
| | | | | | | Any track that has attached picture is also always considered an image. Not every image is neccesarily an attached picture though. So change the check here to capture more possible cases where we should be updating the subtitle. With the previous commits, this fixes #12387.
* m_option: initialize m_option_value union properlyKacper Michajłow2023-10-232-6/+8
| | | | | | | | | C standard says that `= {0}` activates and initializes first member of union. We expect whole union to be zeroed, it is used as default value. Initialize union with one zeroed default instance to ensure proper init. Fixes: #12711
* meson: make libplacebo a required dependencyllyyr2023-10-231-4/+0
| | | | | | | Make it not possible to build mpv without the latest libplacebo anymore. This will allow for less code duplication between mpv and libplacebo, and in the future also let us delete legacy ifdefs and track libplacebo better.
* stats.lua: disable tonemapping plot by defaultDudemanguy2023-10-221-1/+1
| | | | | | Nobody except a chosen few (I'm not one of them) even knows what it means. Multiple people thought it was actually some kind of rendering bug. Just disable it by default. Closes #12671.
* ytdl_hook: remove extra playlist insertDudemanguy2023-10-211-1/+0
| | | | | | b388c735408af1a78e8f6165fa3af31bc623ef8f should have deleted this line since the insert is done a little below it instead, but it was missed during review.
* ytdl_hook: parse the separate cookies fieldUmar Getagazov2023-10-211-1/+104
| | | | | https://github.com/yt-dlp/yt-dlp/security/advisories/GHSA-v8mc-9377-rwjj https://github.com/yt-dlp/yt-dlp/commit/1ceb657bdd25
*