summaryrefslogtreecommitdiffstats
path: root/player/loadfile.c
Commit message (Collapse)AuthorAgeFilesLines
* player/loadfile: rewrite sub autoselection logicDudemanguy2024-02-241-51/+28
| | | | | | | | | There's too many dumb options related to subtitles which have annoying edge cases. Try to rewrite this completely so it hopefully behaves normally in every expected scenario. A key goal here is be smarter while looping through the tracks and avoid selecting the subtitle if it doesn't meet user's passed options as opposed to clearing the pick after the fact. Fixes #13280 and fixes #13263.
* player: add forced choice to subs-with-matching-audioDudemanguy2024-01-131-2/+5
| | | | | | | | | | fe875083b3d30b06ef77745f40570e8f63afec2 confused things a bit and made --no-subs-with-matching-audio actually mean what it says: no subtitles if the languages match. However, the option actually meant no non-forced subtitles not no subtitles at all. This isn't really intuitive so instead of changing the behavior back to the old way (we already have a release since then), add a third option "forced" which is equivalent to the old meaning of --no-subs-with-matching audio. Fixes #13151.
* various: add some missing error checksKacper Michajłow2023-11-181-1/+1
|
* loadfile: remove some dead codeDudemanguy2023-11-181-4/+1
| | | | | | 034f75dacd01bd0b7c6c03e39b193f891f0d5ef2 removed the loop that could cause !next to actually happen here. This code would never be executed and is not needed.
* player: don't remove all selected sub tracks in mp_dselect_trackkarelrooted2023-11-141-0/+2
| | | | fix secondary sub disappear after sub-reload, sub-remove.
* player/loadfile: remove blank line on exitKacper Michajłow2023-11-081-1/+0
|
* ALL: use new mp_thread abstractionKacper Michajłow2023-11-051-11/+11
|
* player: remove unused mutate argument in mp_next_fileDudemanguy2023-10-051-5/+4
| | | | | | e277fadd60350caad1fc31e92a5076692e61dcc9 originally added this but it never actually did anything in the function... wm4 probably changed his mind but forget to delete it so just remove it here.
* loadfile: fix an old wonky playlist heuristicDudemanguy2023-10-051-12/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Revert "demux: improve stream selection state"Dudemanguy2023-09-301-3/+3
| | | | | | | | The stream selection state wasn't improved. I didn't realize this messed with caches. All in all, just not a good idea. Back to drawing board I guess. This reverts commit f40bbfec4fcd2d9a787a4d98ec7698a646e5607e.
* playloop: make chapter property more accurate when seeking chaptersMike Will2023-09-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | When seeking chapters, `last_chapter_seek` acts as a projection of what the current chapter will be once mpv has a chance to seek to it. This allows for more accurate results from the `chapter` property. It works by comparing the projection to the actual current chapter and returning the larger of the two indexes, but this only works when seeking forward. If we want it to work for both forward and backward chapter seeking, we can instead use a boolean called `last_chapter_flag`, which gets switched on when a chapter seek request is made, and then switched off when the seek has been performed. We should also check to ensure that we don't allow the chapter index to be set to -1 unless there is a span of time between the very beginning of the track and the start of the first chapter. Since the new approach to resetting `last_chapter_seek` no longer depends on `last_chapter_pts`, that member variable can be removed.
* demux: improve stream selection stateDudemanguy2023-09-271-3/+3
| | | | | | | | | | | | | | | | | | | | | | | This replaces the previous commit and makes more sense. The internal demux marked tracks as eager depending on their type and for subtitles it would always lazily read them unless there happened to be no available av stream. However, we want the sub stream to be eager if the player is paused. The existing subtitle is still preserved on the screen, but if the user changes tracks that's when the problem occurs. So to handle this case, propagate the mpctx->paused down to the stream selection logic. This modifies both demuxer_refresh_track and demuxer_select_track to take that boolean value. A few other parts of the player use this, but we can just assume false there (no change in behavior from before) since they should never be related to subtitles. The core player code is aware of its own state naturally, and can always pass the appropriate value so go ahead and do so. When we change the pause state, a refresh seek is done on all existing subtitle tracks to make sure their eager state is the appropriate value (i.e. so it's not still set to eager after a pause and a track switch). Slightly invasive change, but it works with the existing logic instead of going around it so ultimately it should be a better approach. We can additionally remove the old force boolean from sub_read_packets since it is no longer needed.
* options: remove deprecated --record-file optionDudemanguy2023-09-211-99/+0
| | | | | | No wonder wm4 wanted to get rid of this. This option requires touching a bunch of crap in the core player code. --stream-record works perfectly fine and is a lot nicer so there's no need for this to exist anymore.
* player: redo --subs-fallback-forcedDudemanguy2023-09-091-8/+18
| | | | | | | | | | | | | In the never ending quest of trying to satisfy every possible user request for subtitle autoselection, I ended up redoing how --subs-fallback-forced works. The old behavior had it as strictly a fallback-type option when there were no lang matches, but now we can make it an active part of compare_track and it works along with slang to select the desired track. Since it's a three state option, the no option still works to avoid selecting any forced subtitle tracks. The meaning of always slightly changes to mean "only select forced subtitle tracks" and yes remains essentially the same (no special priority given besides the audio matching subtitle language case).
* loadfile: fix forced subtitles not respecting slangDudemanguy2023-09-011-2/+7
| | | | | | | | | | | | | | fbe8f9919428a7ed24a61899bfd85bbb7680e389 made it possible for mpv to autoselect forced subtitles again (it was bugged and would ignore without slang being specified). Unfortunately, I forgot to take slang into account here, so it would always autoselect the subtitles if they are available. Fix this by checking both that it matches the lang and that the previous track pick wasn't already matched (os_langs being true is essentially equivalent to there not being any specified slang). This way, it still respects the order of languages in your slang list. Probably someone out there will be upset that forced subtitles aren't always preferred regardless of the order, but that can be another option for later I guess.
* loadfile: fix --no-subs-with-matching-audio with --slangDudemanguy2023-08-291-2/+4
| | | | | | | | | If --slang was set to some language and it matched the subtitle track, then --no-subs-with-matching-audio would do nothing. Fix the logic by doing the --no-subs-with-matching-audio step at the end to ensure that it always "wins" over whatever --slang or --subs-fallback has set. Clarify the docs a bit to make it clearer that this is the intended behavior. Fixes fbe8f9919428a7ed24a61899bfd85bbb7680e389.
* player: rename --sub-forced-only to --sub-forced-events-onlyDudemanguy2023-08-291-1/+1
| | | | | | | | The old name is pretty bad and users mistakenly think it has something to do with selecting forced subtitles (that would be --subs-fallback-forced). Instead of giving it such a generic name, make it clearer that this has to do specifically with forced sub events which is only relevant for a small minority of subtitles.
* player: remove auto choice from sub-forced-onlyDudemanguy2023-08-291-10/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | First of all, this never worked. Or if it ever did, it was in some select few scenarios. c9474dc9ed6172a5f17f66f4b7d367da6b077909 is what originally added support for the auto choice. However, that commit worked by propagating a value to a fake option used internally. This shouldn't have ever worked because the underlying m_config_cache was never updated so the value shouldn't have been preserved when accessed in sd_lavc. And indeed with some testing, the value there is always 0 unsurprisingly. This was later rewritten in ba7cc071068f4f57ae354e77f64552712fda6855 along with a lot of other sub changes, but with that, it was still mostly broken. The reason is because one of the key parts of having to hit this logic (prefer_forced) required `--no-subs-with-matching-audio` to be set. If the audio language matches the subtitle language (the requirement also excludes forced subs), the option makes no subtitle selection in the first place so pick->forced_only_def is not set to true and nothing even happens. Another way around this would be to attempt to change your OS language (like with the LANG environment variable) so that the subtitle track gets selected but then audio_matches mistakenly becomes false because it compares the OS language to the audio language which then make preferred_forced 0, so nothing happens. I don't think there's a scenario where pick->forced_only_def is actually set to true (thus meaning `auto` is useless), but maybe someone could contrive something very strange. Regardless, it's definitely not something even remotely common. fbe8f9919428a7ed24a61899bfd85bbb7680e389 changed track selection again but didn't consider this particular case. The net result is that DVD/PGS subs become equivalent to --sub-forced-only being yes, so this a change in behavior and probably not a good one. Note that I wasn't able to actually observe any difference in a PGS sample. It still displayed subtitles fine but that sample probably didn't have the right flags to hit the sub-forced-only logic. Anyways, the auto feature is extremely questionable at best and in my view, not actually worth it. It is meant to be used with `--no-subs-with-matching-audio` to display forced pictures in subtitle tracks that are not marked as forced, but that contradicts that particular option's purpose and description in the manual (secretly selecting a track under certain conditions even though it says not to). Instead of trying to shove all this logic into select_default_track which is already insanely complicated as it is, recognize that this is a trivial lua script. If you absolutely want to turn --sub-forced-only on under these certain conditions (DVD/PGS subtitles, matching audio and subtitle languages, etc.), just look at the current-tracks property and do your thing. The very, very niche behavior that this option tried to accomplish basically never worked, no user even knows what this option does, and well it's just not worth supporting in core mpv code. Drop all this code for sanity's sake and change --sub-forced-only back to a bool.
* player: add always to --subs-fallback-forcedDudemanguy2023-08-281-2/+4
| | | | | | In general, forced tracks should only be shown if they match the language of the audio. However some people do want them no matter what, so add an always option to this so such tracks are always selected.
* player: add --subs-match-os-language optionDudemanguy2023-08-281-11/+21
| | | | | | | This is the replacement for the previous auto option for slang. It behaves similar however it never overrides slang if that is set and will instead try to pick the subtitle that matches the user's language if appropriately flagged by the file.
* loadfile: simplify default track selection a bitDudemanguy2023-08-281-36/+22
| | | | | | | | | | | | | | What was previously there is extremely complicated and really confusing. Poorly named variables like "prefer_forced" that don't neccesarily have anything to do with prefering forced tracks didn't help either. Try to rewrite a few things to be saner. The idea is that after you loop through the tracks, the special sub-specific options (like subs-fallback and so on) should be handled and the track should be deselected if appropriate. Another change is to remove the "prefered_forced" argument in compare_track. This actually was both not neccessary and caused bad behavior by always depriortizing forced tracks even when it didn't apply (e.g. forced video tracks were never selected even though the flag should simply be ignored for anything that's not a subtitle track).
* player: remove special auto option from alang/slang/vlangDudemanguy2023-08-281-7/+2
| | | | | | | | | | | | This proved to be too problematic. Depending on the value of --subs-with-matching-audio, you could either end up with cases where --slang wasn't respected and users didn't get subtitles or alternatively cases where subtitles were given and the user didn't ask for them. Fundamentally, the OS language functionality doesn't really map well to slang (and for alang/vlang it makes zero sense; not that anyone actually used it). Instead of trying to shove it in an option where it doesn't belong, we should split this off into something else. So for now, just remove the special handling of "auto" and flip slang back to NULL.
* playlist: remove unused code to track redirectsGuido Cella2023-08-281-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* loadfile: avoid infinite playlist loading loopsDudemanguy2023-08-161-0/+28
| | | | | | | | | | | | | There are a number of ways one can craft a playlist file that refers to itself or cleverly goes around in a loop to other playlist files. There is obviously no use for this, but mpv spins around forever trying to load the files so you have to just SIGTERM/SIGKILL it. We can be smarter about this and attempt to detect it. The condition for detecting this is surprisingly simple: the filename of the first entry in the playlist must match a previous playlist path we stored. If we get this, we can then log an error and stop playback. If there is a "real" file loaded at any point in time, then we know it's not an infinite loop and clear out the saved playlist paths. Fixes #3967.
* player: add playlist-path propertiesDudemanguy2023-08-131-0/+1
| | | | | | | | | | | | 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.
* loadfile: make get_audio_lang function staticllyyr2023-07-171-1/+1
| | | | This fixes a build warning about missing prototypes
* loadfile: compute audio lang for sub selection when using lavfi-complexrcombs2023-07-161-3/+30
| | | | | | | | When using lavfi-complex, no single track populates current_track for audio. We work around this by iterating over the list of tracks and using the first non-null language from a selected track. If multiple tracks are selected (i.e. used by the filter) and have conflicting language tags, we'll ignore them all and maintain the previous behavior (null).
* player: delete watch later redirect entries againGuido Cella2023-07-141-0/+2
| | | | | | | | | | 6a365b258a broke deleting redirect entries for resuming playback. If you do mpv dir1 dir2, quit-watch-later on a file in dir1, then later quit-watch-later on a file in dir2, mpv dir1 dir2 would not resume from dir2 because the redirect entry for dir1 is never deleted. Fix this by deleting watch later config files for directory/playlist entries.
* player: delete watch_later file after successful loadDudemanguy2023-07-081-1/+4
| | | | | | | | | | Currently, mpv immediately deletes the watch_later file after an attempt at playing the file is made. This is not really ideal because the file may fail to load for a variety of reasons (including not even existing), but the state is cleared anyway unconditionally. Instead, just wait until after playback is successfully initialized before deleting it. This way silly mistakes like forgetting to mount the drive doesn't result in deleting your watch_later data. Fixes #3427.
* loadfile: fix leak due to setting NULL parentNRK2023-06-281-2/+3
| | | | | | | | in the first iteration, *out will be null and thus the steal and the strdup both sets the parent to NULL - leaking the allocation later on (caught via LeakSanitizer). let append_lang() take care of setting the parent instead.
* loadfile: insert missing parenthesesPhilip Langdale2023-06-261-2/+2
| | | | | Impressively, gcc's parentheses warning has caught a situation where the missing parentheses were really needed.
* loadfile: expose auto-forced-only when printing stream inforcombs2023-06-251-1/+9
|
* sub: rewrite auto-forced-only supportrcombs2023-06-251-5/+11
| | | | | - No longer has a fake "option" used only internally (which didn't always get propagated properly) - Always overrideable during playback
* player: add more precise sub fallback optionsrcombs2023-06-251-10/+38
|
* loadfile: support "auto" as a language optionrcombs2023-06-251-3/+48
| | | | This uses the user's OS-level preferred set of languages
* loadfile: use mp_match_lang_singlercombs2023-06-251-2/+4
| | | | | This adds basic support for IETF language tags, as well as matching 2-letter language codes against 3-letter ones (and vice versa).
* loadfile: take a const char* in match_langrcombs2023-06-251-1/+1
|
* loadfile: short-circuit early on null stream languagercombs2023-06-251-0/+2
|
* loadfile: strongly prefer that all streams are from the same programrcombs2023-03-031-2/+10
| | | | | | In raw OTA MPEGTS, different programs can be entirely different virtual channels. In web streams, different programs can be different variant bitrates, so using streams from different programs can waste large amounts of bandwidth.
* loadfile: report hls_bitrate and program_id in struct trackrcombs2023-03-031-0/+2
|
* options: transition options from OPT_FLAG to OPT_BOOLChristoph Heinrich2023-02-211-1/+1
| | | | | | 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-201-1/+0
| | | | | | Most sources don't need config.h. The inclusion only leads to lots of unneeded recompilation if the configuration is changed.
* filters: lavfi: allow hwdec_interop selection for filtersPhilip Langdale2022-09-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Today, lavfi filters are provided a hw_device from the first hwdec_interop that was loaded, regardless of whether it's the right one or not. In most situations where a hardware based filter is used, we need more control over the device. In this change, a `hwdec_interop` option is added to the lavfi wrapper filter configuration and this is used to pick the correct hw_device to inject into the filter or graph (in the case of a graph, all filters get the same device). Note that this requires the use of the explicit lavfi syntax to allow for the extra configuration. eg: ``` mpv --vf=hwupload ``` becomes ``` mpv --vf=lavfi=[hwupload]:hwdec_interop=cuda-nvdec ``` or ``` mpv --vf=lavfi-bridge=[hwupload]:hwdec_interop=cuda-nvdec ```
* player: make deprecated track/chapter/metadata events internalsfan52021-12-151-6/+6
| | | | | We still need these to track or notify of modifications to certain properties, but they're now gone from the libmpv ABI.
* player: add track-list/N/image sub-propertyGuido Cella2021-10-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | This exposes whether a video track is detected as an image, which is useful for profile conditions, property expansion and lavfi-complex. The lavf demuxer sets image to true when the existing check detects an image. When the lavf demuxer fails, the mf one guesses if the file is an image by its extension, so sh->image is set to true when the mf demuxer succeds and there's only one file. The mkv demuxer just sets image to true for any attached picture. The timeline demuxer just copies the value of image from source to destination. This sets image to true for attached pictures, standalone images and images added with !new_stream in EDL playlists, but it is imperfect since you could concatenate multiple images in an EDL playlist (which should be done with the mf demuxer anyway). This is good enough anyway since the comment of the modified function already says it is "Imperfect and arbitrary".
* Revert "player: add track-list/N/image sub-property"Jan Ekström2021-10-021-1/+0
| | | | | | | | Unfortunately, this functionality in large part based on a struct member that was made private in FFmpeg/FFmpeg@7489f632815c98ad58c3db71d1a5239b5dae266c in May. Unfortunately, this was not noticed during review. This reverts commit 0862664ac952d21fef531a8923a58ae575268fc5.
* player: add track-list/N/image sub-propertyGuido Cella2021-10-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |