summaryrefslogtreecommitdiffstats
path: root/player/command.c
Commit message (Collapse)AuthorAgeFilesLines
* vo: replace VOCTRL_HDR_METADATA with direct VO params readKacper Michajłow2023-11-081-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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.
* player/command: fix typo in sig-peak value computationKacper Michajłow2023-11-071-1/+1
| | | | Fixes: 73fbe09a49d3ed00c6e19fdcc658802f28974ae2
* 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.
* 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-051-1/+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-051-1/+22
| | | | | 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-051-1/+0
|
* mp_thread: prefer tracking threads with idKacper Michajłow2023-11-051-3/+3
| | | | | | | | | | | | | | 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-051-5/+6
|
* 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.
* m_option: initialize m_option_value union properlyKacper Michajłow2023-10-231-4/+4
| | | | | | | | | 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
* player/command: truncate anything < 1e-4 in pretty printerKacper Michajłow2023-10-181-2/+2
| | | | | | | | To avoid switching to scientific notation. Apparently it is "jarring" for some users. This preserves status quo from before 9dddfc4f where pretty printer were truncated to 3 decimal places.
* command: unbreak runtime play-dir changesDudemanguy2023-10-161-3/+5
| | | | | | | The whole mess with setting the option value explictly and saving the old stop_play value only needs to happen if we're at the end of file. Doing it in general is unneccessary and breaks other things. Fixes #12424.
* player/command: change how floating point number are printedKacper Michajłow2023-10-141-2/+7
| | | | | | | | Use "%.7g" to show 7 significant digits. Removes the trailing zeros, and in general makes it more readable, than fixed 3 decimal digits. For avsync use "%+.2g" to add plus sign, similar to display-sync values.
* command: fix fps property nameKacper Michajłow2023-10-141-1/+1
| | | | fps property was not renamed in events.
* command: early exit in some properties to avoid going through VOCTRLKacper Michajłow2023-10-141-18/+39
|
* command: fix segfault with playlist-{next,prev}-playlistGuido Cella2023-10-131-0/+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
* vo: remove vo_get_estimated_vsync_interval conversion to secondsDudemanguy2023-10-101-1/+1
| | | | | This is weird. The caller should be responsible for converting the value if desired. Move the conversion to player/command.c instead.
* command: add playlist-next-playlist and playlist-prev-playlistGuido Cella2023-10-091-0/+43
| | | | | | | | | | | | 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.
* vo_gpu_next: improve updating overlaysDudemanguy2023-10-051-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | fbe154831a8addfc18a4f81e1c4b9284c31acace added a new VOCTRL to signal when the OSD changed for gpu-next's handling of subtitles, but this is both not necessary and actually incomplete. The VOCTRL would signal OSD changes, but not all subtitle changes (like selecting another non-external sub track for example). VOCTRL_OSD_CHANGED was used to increment p->osd_sync which would then redraw the blended subtitles if the player was paused. But there's already a VOCTRL_PAUSE and VOCTRL_RESUME. Plus, the sub_bitmap_list object will have items in it if it changed in any way, so we don't need the VOCTRL_OSD_CHANGED method at all. That can be removed. The check that fp->osd_sync < p->osd_sync stays in place since that's an optimization while the video is playing, but we also check the pause state as well since the VO can know this. If we're paused, then always do update_overlays since core must be signalling a redraw to us if we get a draw_frame call here. Additionally in update_overlays itself, the p->osd_sync counter is incremented if we have any items since the frame signature will need that. As for the actual bug that is fixed, changing subtitle tracks while paused with blended subtitles now correctly works. Previously, it was never updated so the old subtitle stayed there forever until you deselected it (since VOCTRL_OSD_CHANGED triggered there). Also include some cosmetic code fixes that were noticed.
* player: remove unused mutate argument in mp_next_fileDudemanguy2023-10-051-1/+1
| | | | | | 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.
* af/vf-command: add ability to target a specific lavfi filterAshyni2023-10-051-6/+17
| | | | fixes: #11180
* win32/pthread: define _POSIX_TIMERS to notify they are not supportedKacper Michajłow2023-09-291-1/+1
|
* playloop: make chapter property more accurate when seeking chaptersMike Will2023-09-291-4/+4
| | | | | | | | | | | | | | | | | | | | | | 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.
* command: only warn shared-script-properties onceDudemanguy2023-09-271-2/+6
| | | | | | | Evidently I was wrong and mpv only actually warns once on deprecation (playlist-pos nor display-fps did not and warned every time, but those were outliers apparently). Someone complained so just hack it into command_ctx for now.
* command: deprecate shared-script-propertiesDudemanguy2023-09-271-0/+2
| | | | user-data is simply better.
* options: remove deprecated --record-file optionDudemanguy2023-09-211-3/+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.
* command: stop restarting playback when writing to playlist-posDudemanguy2023-09-211-5/+2
| | | | | | | | | e9e93b4dbe748cd341a6fbea355e6ba013ada81b added a warning about writing the same value to the playlist-pos property that in the future it would stop restarting playback. Instead, you should use the playlist-play-index command for that. Well go ahead and drop the old deprecated behavior now and do what wm4 wanted this to do: just ignore if the same value is written again.
* command: remove some old deprecated properitiesDudemanguy2023-09-211-20/+7
| | | | | | | | drop-frame-count and vo-drop-frame-count are ancient and have no reason to exist anymore. The other change is that support for writing to display-fps has been removed, and the property is strictly read-only now. 3a2dc8b22e9f947c9cd3a91445b0731b8df1d798 is what deprecated it with a warning to users, so we can remove it without much trouble.
* options: make video-crop validation more strictKacper Michajłow2023-09-201-2/+1
|
* demux: add crop to mp_codec_paramsKacper Michajłow2023-09-171-0/+5
|
* video: allow overriding container crop if it is presentKacper Michajłow2023-09-081-2/+6
| | | | | | Setting `--video-crop=0x0+0+0` applies full frame crop, ignoring the container one. Setting --video-crop=0 disables manual crop and restores container one if it is available.
* player/command: mark video-params/crop- unavailable if emptyKacper Michajłow2023-09-081-4/+5
|
* player/command: add video-params/crop-[w,h,x,y]Kacper Michajłow2023-08-311-0/+4
|
* vo: add --video-cropKacper Michajłow2023-08-311-1/+7
| | | | | | Just cropping by VO that works with hwdec. Fixes: #12222
* player/command: remove video-aspect propertyKacper Michajłow2023-08-311-63/+1
| | | | 4 years is enough of deprecation period.
* command: add hdr-metadata propertyKacper Michajłow2023-08-291-0/+35
|
* command: remove sub-forced-only-cur propertyDudemanguy2023-08-291-9/+1
| | | | | | Since we no longer have the auto choice, this is always exactly equal to the value of the option (sub-forced-events-only). Remove the property and alias it.
* player: rename --sub-forced-only to --sub-forced-events-onlyDudemanguy2023-08-291-2/+2
| | | | | | | | 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-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* command: add `sub-ass-extradata` propertyllyyr2023-08-271-0/+24
|
* player: make all autoload extensions configurableDudemanguy2023-08-261-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | --audio-file-auto, --cover-art-auto, and --sub-auto all work by using an internally hardcoded list that determine what file extensions get recognized. This is fine and people periodically update it, but we can actually expose this as a stringlist option instead. This way users can add or remove any file extension for any type. For the most part, this is pretty pretty easy and involves making sub_exts, etc. the defaults for the new options (--audio-file-auto-exts, --cover-art-auto-exts, and --sub-auto-exts). There's actually one slight complication however. The input code uses mp_might_be_subtitle_file which guesses if the file drag and dropped file is a subtitle. The input ctx has no access to mpctx so we have to be clever here. For this, the trick is to recognize that we can leverage the m_option_change_callback. We add a new flag, UPDATE_SUB_EXTS, which fires when the player starts up. Then in the callback, we can set the value of sub_exts in external_files to opts->sub_auto_exts. Whenever the option updates, the callback is fired again and sub_exts updates. That way mp_might_be_subtitle_file can just operate off of this global variable instead of trying to mess with the core mpv state directly. Fixes #12000.
* player: add playlist-path propertiesDudemanguy2023-08-131-5/+18
| | | | | | | | | | | | 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.
* player: make sub-pos a float valueDudemanguy2023-08-131-1/+1
| | | | | | | | mpv makes this option an integer, but the underlying ass API actually accepts doubles. From some testing, there is no meaningful precision difference between float or double (it seems to go in roughly 0.05 steps), so just make it a float. sd_lavc also can handle non-integer values here. Closes #11583.
* player/command: add video-params/aspect-nameKacper Michajłow2023-08-131-1/+45
| | | | With pretty printed aspect ratio and related format.
* command: don't print "unknown" on video tracksDudemanguy2023-08-111-1/+4
| | | | | | | | | | | When printing the name of the video track on the OSC, mpv almost always prefixes it with "unknown". This is referring to the language tag which essentially nobody ever does for the video track since it doesn't make any sense. Instead of putting unknown when there's no language, just make it an empty string instead. "Unknown" confuses can confuse users here and practically nobody would guess that it's referring to language. We still will print the language for a video track in case someone out there really does tag it, but that should be rare.
* command: show "no" for hwdec-current if hwdec failedDudemanguy2023-08-111-1/+1
| | | | | Now actually matches the documentation (was an empty string not null). Fixes #11464.
* command: fix some fringe play-dir behaviorDudemanguy2023-08-111-0/+6
| | | | | | | | | | | | | | | | | | | This is pretty obscure but if you screw around with the play-dir option to essentially create a ping-pong loop; mpv will get hit by an assertion error. What's happening here is that changing the play-dir always requires a seek. This is handled in player/command along with the other runtime option changes. However, queue_seek can actually clear the value of mpctx->stop_play if the file is ending. So while loadfile is terminating playback and the play-dir gets changed, the value of mpctx->stop_play gets cleared because of seek. This then hits that assertion later when mpv tries to finish the file. The fix is to just add some weird logic to play-dir in player/command. We have to be sure that mpctx->play_dir matches the new direction immediately when we get the change so explictly set it here and don't wait for it later. Secondly, keep the old value of mpctx->stop_play before the seek and restore it afterwards. This ensures that termination still happens cleanly and allows the ping-pong loop to work. Fixes #10782
* command: fix stack smashing when displaying aspect-ratiollyyr2023-08-111-11/+7
| | | | | | 1df0a42a8cb12005311f6a03f3a1c4329c798f8c changed aspect-ratio from floats to doubles, but forgot to change this function for pretty-printing them as fractions for the video-aspect-override property
* Revert "audio: add AOCONTROL_UPDATE_MEDIA_ROLE"Thomas Weißschuh2023-07-301-3/+0
| | | | | | | The only user of these APIs was ao_pipewire and the logic there got converted so drop the now dead code. This reverts commit 3167a77aa38b