summaryrefslogtreecommitdiffstats
path: root/player/sub.c
Commit message (Collapse)AuthorAgeFilesLines
* player: avoid busy looping during reinit_subDudemanguy8 days1-4/+12
| | | | | | | | | | | | | | | | | | If the player is paused, switching subtitle track requires us to read subs packets for an indefinite amount of time in order to actually display the subtitles. The problem with this is that it puts a blocking loop in the play thread which can be slow in cases where it takes a long time to fetch the subtitle (e.g. over a network). 9e27b1f523071db184443d78f7144cb599dd0829 alleviates this when a pause happens because of buffering, but it's not complete. One could encounter this if the user pauses the video first manually and then switches the subtitle track. To solve this better, make it so the loop has a time out (totally arbitrary number) so the player isn't blocked forever. If subtitles are not fetched within that time, we flag the track and try again later in the playloop.
* player/sub: avoid wasteful subtitle redrawsDudemanguy2024-02-151-22/+45
| | | | | | | | | | | | | | | | | This only affects two special cases: printing subtitles to the terminal and printing subtitles on a still picture. Previously, mpv was very dumb here and spammed this logic on every single loop. For terminal subtitles, this isn't as big of a deal, but for the image case this is pretty bad. The entire VO constantly redrew even when there was no need to which can be very expensive depending on user settings. Instead, let's rework sub_read_packets so that it also tells us whether or not the subtitle packets update in some way in addition to telling us whether or not to read more. Since we cache all packets thanks to the previous commit, we can leverage this information to make a guess whether or not the current subtitle packet is supposed to be visible on the screen. Because the redraw now only happens when it is needed, the mp_set_timeout_hack can be removed.
* options: add --secondary-sub-poskarelrooted2023-12-131-1/+0
| | | | The default value is 0 (on the top of the screen)
* sub: don't busy loop if the player is paused for cacheDudemanguy2023-12-121-1/+2
| | | | | | | | | When updating subtitles while paused, mpv waits until a packet is available. However in the case of a network stream, it is possible that mpv will pause itself when buffering for cache reasons. This makes that particular loop do a busy loop and can take a long time depending on network streams. Simply just don't do the loop here if we are paused for cache reasons. Fixes #13077.
* 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.
* Revert "demux: improve stream selection state"Dudemanguy2023-09-301-1/+1
| | | | | | | | 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.
* demux: improve stream selection stateDudemanguy2023-09-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | 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.
* sub: fix switching tracks while pausedDudemanguy2023-08-111-2/+4
| | | | | | | | Internal subtitles were not shown when switching between tracks while mpv was paused. The reason for this is simply because the demuxer data isn't available yet when the track switch happens. Fixing it is basically just retrying until the packet is actually available when the player is paused. Fixes #8311.
* sub: rewrite auto-forced-only supportrcombs2023-06-251-1/+1
| | | | | - No longer has a fake "option" used only internally (which didn't always get propagated properly) - Always overrideable during playback
* 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.
* sub: align ytdl-hook secondary subs to the topGuido Cella2021-08-111-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 29e15e6248 prefixed youtube-dl's subs url with an edl prefix to not download them until they're selected, which is useful when there are many sub languages. But this prefix broke the alignment of secondary subs, which would overlap the primary subs instead of always being placed at the top. This can be tested with --sub-file='edl://!no_clip;!delay_open,media_type=sub;secondary_sub.srt' When a sub is added, sub.c:reinit_sub() is called. This calls in init_subdec() -> dec_sub.c:sub_create() -> init_decoder() -> sd_ass:init(). Then reinit_sub() calls sub_control(track->d_sub, SD_CTRL_SET_TOP, &(bool){!!order}) which sets sd_ass_priv.on_top = true for secondary subs. But for EDL subs the real sub is initialized again when in dec_sub.c:sub_read_packets() is_new_segment() returns true and update_segment() is called, or when sub_get_bitmaps() calls update_segment(). update_segment() then calls init_decoder(), which calls sd_ass:init(), so sd_ass_priv is reinitialized, and its on_top property is left false. This commit sets it to true again. For URLs that need to be downloaded it seems that the update_segment() call that reinitializes sd_ass_priv is always the one in sub_read_packets(), but with local subs sub_get_bitmaps() is usually called earlier (though there shouldn't be a reason to use the EDL URL for local subs), so I added the order parameter to sub_create(), rather than adding it to all of update_segment(), sub_read_packets() and sub_get_bitmaps(). Also removes the cast to bool in the other sub_control call, since sub/sd_ass.c:control already casts arg to bool when cmd is SD_CTRL_SET_TOP.
* sub: fix subs/lyrics on music files with sub-past-video-end=norcombs2021-06-271-1/+3
| | | | Regressed in 11423acf3
* sub: by default, don't render timestamps after video EOFrcombs2021-06-231-1/+2
| | | | | | | | | This fixes a long-standing apparent issue where mpv would display the last frame with no subtitles at EOF. This is caused by sub rendering switching from video timestamps to audio timestamps when the video ends, and audio streams often running past the timestamp of the last video frame. However, authoring tools (most notably Aegisub) don't tend to provide easy ways to add meaningful subtitles after the end of the video, so this is rarely actually useful.
* command: add property to return text subtitles in ASSwm42020-05-141-2/+5
| | | | | | | | | See manpage additions. This was requested, sort of. Although what has been requested might be something completely different. So this is speculative. This also changes sub_get_text() to return an allocated copy, because the buffer shit was too damn messy.
* player: slightly improve use of secondary track selection limitswm42020-04-151-3/+3
| | | | | | Apparently, this was a bit of a mess, which caused the bug fixed by commit ec7f2388af2df. Try to improve this, and only use track selection entries that exist.
* player: partially fix backward playback display of cached text subtitleswm42020-02-041-5/+2
| | | | | | | | | | | | | | This simply didn't set the direction flag in most situations, which meant the timestamps used in the subtitle renderer were nonsense, leading to invisible subtitles. This works only for text subtitles that are cached in the ASS_Track state. Reading new subtitles is broken because the demuxer layer has trouble returning subtitle packets backwards, and I think for rendering bitmap subtitles, the pruning direction would have to be adjusted. (Not sure if reversing the timestamps before the subtitle renderer backend is even the right thing to do. At least for sd_ass.c, it seems to make sense, because it caches subtitles with "normal" timestamps.)
* player: ensure backward playback state is propagated on track switchingwm42019-09-191-1/+3
| | | | | | | | Track switching doesn't run reset_playback_state(), so a track enabled at runtime during backward playback would lead to a messed up state. This commit just does a bad code monkey fix to this. It feels like there needs to be a much better way to propagate this state.
* sub: fix typo in commentwm42019-09-191-1/+1
|
* player: don't cache subtitles across deselectionwm42018-06-301-1/+5
| | | | | This means reselection triggers full reinit. This is better if you have options that "edit" subtitles or whatever.
* video: make decoder wrapper a filterwm42018-01-301-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes a source filter. vd.h mostly disappears, because mp_filter takes care of the dataflow, but its remains are in struct mp_decoder_fns. One goal is to simplify dataflow by letting the filter framework handle it (or more accurately, using its conventions). One result is that the decode calls disappear from video.c, because we simply connect the decoder wrapper and the filter chain with mp_pin_connect(). Another goal is to eventually remove the code duplication between the audio and video paths for this. This commit prepares for this by trying to make f_decoder_wrapper.c extensible, so it can be used for audio as well later. Decoder framedropping changes a bit. It doesn't seem to be worse than before, and it's an obscure feature, so I'm content with its new state. Some special code that was apparently meant to avoid dropping too many frames in a row is removed, though. I'm not sure how the source code tree should be organized. For one, video/decode/vd_lavc.c is the only file in its directory, which is a bit annoying.
* video: rewrite filtering glue codewm42018-01-301-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Get rid of the old vf.c code. Replace it with a generic filtering framework, which can potentially handle more than just --vf. At least reimplementing --af with this code is planned. This changes some --vf semantics (including runtime behavior and the "vf" command). The most important ones are listed in interface-changes. vf_convert.c is renamed to f_swscale.c. It is now an internal filter that can not be inserted by the user manually. f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is conceptually easy, but a big mess due to the data flow changes). The existing filters are all changed heavily. The data flow of the new filter framework is different. Especially EOF handling changes - EOF is now a "frame" rather than a state, and must be passed through exactly once. Another major thing is that all filters must support dynamic format changes. The filter reconfig() function goes away. (This sounds complex, but since all filters need to handle EOF draining anyway, they can use the same code, and it removes the mess with reconfig() having to predict the output format, which completely breaks with libavfilter anyway.) In addition, there is no automatic format negotiation or conversion. libavfilter's primitive and insufficient API simply doesn't allow us to do this in a reasonable way. Instead, filters can use f_autoconvert as sub-filter, and tell it which formats they support. This filter will in turn add actual conversion filters, such as f_swscale, to perform necessary format changes. vf_vapoursynth.c uses the same basic principle of operation as before, but with worryingly different details in data flow. Still appears to work. The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are heavily changed. Fortunately, they all used refqueue.c, which is for sharing the data flow logic (especially for managing future/past surfaces and such). It turns out it can be used to factor out most of the data flow. Some of these filters accepted software input. Instead of having ad-hoc upload code in each filter, surface upload is now delegated to f_autoconvert, which can use f_hwupload to perform this. Exporting VO capabilities is still a big mess (mp_stream_info stuff). The D3D11 code drops the redundant image formats, and all code uses the hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a big mess for now. f_async_queue is unused.
* sub: move all subtitle timestamp messing code to a central placewm42018-01-021-3/+0
| | | | | | | | | | | | | | | | | It was split at least across osd.c and sd_ass.c/sd_lavc.c. sd_lavc.c actually ignored most of the more obscure subtitle timing things. There's no reason for this - just move it all to dec_sub.c (mostly from sd_ass.c, because it has some of the most complex stuff). Now timestamps are transformed as they enter or leave dec_sub.c. There appear to have been some subtle mismatches about how subtitle timestamps were transformed, e.g. sd_functions.accepts_packet didn't apply the subtitle speed to the timestamp. This patch should fix them, although it's not clear if they caused actual misbehavior. The semantics of SD_CTRL_SUB_STEP are slightly changed, which is the reason for the changes in command.c and sd_lavc.c.
* player: change license of most core files to LGPLwm42017-06-231-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These files have all in common that they were fully or mostly taken from mplayer.c. (mplayer.c was a huge file that contains almost all of the playback core, until it was split into multiple parts.) This was probably the hardest part to relicense, because so much code was moved around all the time. player/audio.c still does not compile. We'll have to redo audio filtering. Once that is done, we can probably actually provide an actual LGPL configure switch. Here is a relatively detailed list of potential issues: 8d190244: author did not reply, parts were made GPL-only in a previous commit. 7882ea9b: author could not be reached, but the code is gone. wscript still has --datadir switch, but I don't think this is relevant to copyright. f197efd5: unclear origin, but I consider the code gone anyway (replaced with generic OSD mechanisms). 8337d9c2: author did not reply, but only the option still exists (under a different name), other code was removed. d8fd7131: did not reply. Disabled in a previous commit. 05258251: same author as above. Both fields actually seem to have vanished (even when tracking renames), so no action taken. d459e644, 268b2c1a: author did not reply, but we reuse only the options (with different names and slightly or fully different semantics, and completely different implementations), so I don't think this is relevant for copyright. 09e742fe, 17c39c4e: same as above. e8a173de, bff4b3ee: author could not be reached. The commands were reworked to properties, and the code outside of the TV code were moved back to the TV code. So I don't think copyright applies to the current command.c parts (mp_property_tv_color, mp_property_tv_freq, mp_property_tv_scan). The TV parts remain GPL. 0810e427: could not be reached. Disabled in a previous commit. 43744a2d: unknown author, but this was replaced by dynamic alloc (if the change is even copyrightable). 116ca0c7: unknown author; reasoning see input.c relicensing commit. e7e4d1d8: these semantics still exist, but as generic code, and this code was fully removed. f1175cd9: the author of the cited patch is unknown, and upon inspection it turns out that I was only using the idea to pause the player on EOF, so I claim it's not copyright relevant. 25affdcc: author could not be reached (yet) - but it's only a function rename, not copyrightable. 5728504c was committed by Arpi (who agreed), but hints that it might be by a different author. In fact it seems to be mostly this patch: http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2001-November/002041.html The author did not respond, but it all seems to have been removed later. It's a terrible mess though. Arpi reverted the A-V sync code at first, but left the RTC code for a while. The following commits remove these changes 100%: 14b35442, 7181a091, 31482783, 614f8475, df58e822. cehoyos did explicitly not agree to LGPL, but was involved in the following changes: c99d8fc8: applied a patch and didn't modify it, the original author agreed. 40ac0d31: author could not be reached, but all code is gone anyway. The "af" command has a similar function, but works completely different and actually reuses a mechanism older than this patch. 54350436: applied a patch, but didn't modify it, except for adding a German translation, which was removed later. a2dda036: same situation as above 240b743e: this was made GPL-only in a previous commit 7b25afd7: same as above (for now) kirijua could not be reached, but was a regular patch contributor: c2c997fd: video equalizer code move; probably not copyrightable. Is GPL due to Nick anyway. be54f481: technically, this became the audio track property later. But all what is left is the fact that you pass a track ID to it, so consider the original coypright non-relevant. 2f376d1b: this was rewritten in b7052b43, but for now we can afford to be careful, so this was marked as GPL only in a previous commit. 43844d09: remaining parts in main.c were reverted in a previous commit. anders has mostly disagreed with the LGPL relicensing. Does not want libaf to become LGPL, but made some concessions. In particular, he granted us permission to relicense 4943e9c52c and 242aa6ebd4. We also consider some of his changes remaining in mpv not relevant for copyright (such as 735de602 - we won't remove the this option completely). We will completely remove his other contributions, including the entire audio filter chain. For now, this stuff is marked as GPL only. The remaining question is how much code in player/audio.c (based on the former mplayer.c and dec_audio.c) is under his copyright. I made claims about this in a previous commit. Nick(ols) Kurshev, svn username "nick" and "nickols_k", could not be reached. He had a lot of changes in early MPlayer. It seems all of that was removed, at least in mpv. His main work, like VIDIX or libswscale work, does not exist in mpv anymore, but the changes to mplayer.c and other core parts still deserve attention: a4119f6b, fb927549, ad3529b8, e11b23dc, 5f2178be, 93c371d5: removed in b43d67e0, d1628d12, 24ed01fe, df58e822. 0a83c6ec, 104c125e, 4e067f62, aec5dcc8, b587a3d6, f3de6e6b: DR, VAA, and "tune" stuff was fully removed later on or replaced with other mechanisms. 340183b0: screenshots were redone later (the VOCTRL was even removed, with an independent implementation using the same VOCTRL a few years later), so not relevant anymore. Basically only the 's' shortcut remains (but not its implementation). 92c5c274, bffd4007, 555c6766: for now marked as GPL only in a previous commit. Might contain some trace amounts of "michael"'s copyright, who agreed to LGPL only once the core is relicensed. This will still be respected, but I don't think it matters at this in this case. (Some code touched by him was merged into mplayer.c, and then disappeared after heavy refactoring.) I tried to be as careful and as complete as possible. It can't be excluded that amends to this will be made later. This does not make the player LGPL yet.
* player: enable no-video subtitle display on coverart toowm42016-10-311-1/+1
| | | | | | | | | | | Coverart mode has the same issue as no-video mode, except that the video chain is fully active. It shows only 1 frame at the start, which would normally mean that only the subtitle at timestamp 0 is shown. Use the no-video subtitle rendering mode in this case instead. (This still doesn't handle subtitle display when playing cover-art without audio, or playing a single image. This is because there's nothing that will advance playback_pts.)
* player: don't try updating subtitles while playback PTS doesn't progresswm42016-10-301-2/+2
| | | | | | This code would just keep it busy while e.g. being paused. Even if it's not paused, it couldn't help with anything since we obviously still lock display to the externally updated PTS.
* player: show subtitles on VO if --force-window is usedwm42016-10-261-0/+13
| | | | | | | | | | | | | | | | | | | | | If a VO is created, but no video is playing (i.e. --force-window is used), then until now no subtitles were shown. This is because VO subtitle display normally depends on video frame timing. If there are no video frames, there can be no subtitles. Change this and add some code to handle this situation specifically. Set a subtitle PTS manually and request VO redrawing manually, which gets the subtitles rendered somehow. This is kind of shaky. The subtitles are essentially sampled at arbitrary times (such as when new audio data is decoded and pushed to the AO, or on user interaction). To make a it slightly more consistent, force a completely arbitrary minimum FPS of 10. Other solutions (such as creating fake video) would be more intrusive or would require VO-level API changes. Fixes #3684.
* player: fix instant subtitle refresh on track switcheswm42016-09-241-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | When switching a subtitle track, the subtitle wasn't necessarily updated, especially when playback was paused. Some awfully subtle and complex interactions here. First off (and not so subtle), the subtitle decoder will read packets only on explicit update_subtitles() calls, which, if video is active, is called only when a new video frame is shown. (A simply video frame redraw doesn't trigger this.) So call it explicitly. But only if playback is "initialized", i.e. not when it does initial track selection and decoder init, during which no packets should be read. The second issue is that the demuxer thread simply will not read new packets just because a track was switched, especially if playback is paused. That's fine, but if a refresh seek is to be done, it really should do this. So if there's either 1. a refresh seek requested, or 2. a refresh seek ongoing, then read more packets. Note that it's entirely possible that we overflow the packet queue with this in unpredicated weird corner cases, but the queue limit will still be enforced, so this shouldn't make the situation worse.
* osd: cleanup: make OSDTYPE_ constants private to OSD codewm42016-03-081-4/+2
| | | | | | No need to have them everywhere. The only exception/annoyance is MAX_OSD_PARTS, which is now basically duplicated (and at runtime initialization is checked with an assert()).
* sub: make preloading more robustwm42016-03-061-7/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Subtitles can be preloaded, which means they're fully read and copied into ASS_Track. This in turn is mainly for the sake of being able to do subtitle seeking (when it comes down to it, subtitle seeking is the cause for most trouble here). Commit a714f8e92 broke preloaded subtitles which have events with unknown duration, such as some MicroDVD samples. The event list gets cleared on every seek, so the property of being preloaded obviously gets lost. Fix this by moving most of the preloading logic to dec_sub.c. If the subtitle list gets cleared, they are not considered preloaded anymore, and the logic for demuxed subtitles is used. As another minor thing, preloadeding subtitles did neither disable the demux stream, nor did it discard packets. Thus you could get queue overflows in theory (harmless, but annoying). Fix this by explicitly discarding packets in preloaded mode. In summary, now the only difference between preloaded and normal demuxing are: 1. a seek is issued, and all packets are read on start 2. during playback, discard the packets instead of feeding them to the subtitle decoder This is still petty annoying. It would be nice if maintaining the subtitle index (and maybe a subtitle packet cache for instant subtitle presentation when seeking back) could be maintained in the demuxer instead. Half of all file formats with interleaved subtitles have this anyway (mp4, mkv muxed with newer mkvmerge).
* sub: pass all attachments to the subtitle decoderwm42016-03-031-1/+25
| | | | | | | | | | | | | | | | | Commit 8d4a179c made subtitle decoders pick up fonts strictly from the same source file (i.e. the same demuxer). It breaks some fucked up use-case, and 2 people on this earth complained about the change because of this. Add it back. This copies all attached fonts on each subtitle init. I considered converting attachments to use refcounting, but it'd probably be much more complex. Since it's slightly harder to get a list of active demuxers with duplicate removed, the prev_demuxer variable serves as a hack to achieve almost the same thing, except in weird corner cases. (In which fonts could be added twice.)
* demux: remove relative seekingwm42016-02-281-1/+1
| | | | | | | | | | | | | | | | | | | Ever since a change in mplayer2 or so, relative seeks were translated to absolute seeks before sending them to the demuxer in most cases. The only exception in current mpv is DVD seeking. Remove the SEEK_ABSOLUTE flag; it's not the implied default. SEEK_FACTOR is kept, because it's sometimes slightly useful for seeking in things like transport streams. (And maybe mkv files without duration set?) DVD seeking is terrible because DVD and libdvdnav are terrible, but mostly because libdvdnav is terrible. libdvdnav does not expose seeking with seek tables. (Although I know xbmc/kodi use an undocumented API that is not declared in the headers by dladdr()ing it - I think the function is dvdnav_jump_to_sector_by_time().) With the current mpv policy if not giving a shit about DVD, just revert our half-working seek hacks and always use dvdnav_time_search(). Relative seeking might get stuck sometimes; in this case --hr-seek=always is recommended.
* player: slightly simplify how demuxer streams are enabled/disabledwm42016-02-251-1/+0
| | | | | Instead of having reselect_demux_streams() look at all streams, make it look at the current stream that is being enabled/disabled.
* sub: change when/how subtitles are read completelywm42016-01-221-12/+8
| | | | | | | | | | | | Most text subtitles are read completely on loading (libavformat works this way, and there are good reasons to do it on the higher levels too). This leads to some messy problems. For example, the subtitle path is the only one which might read packets during decoder initialization. This is not neccessary; get rid of it. This fixes a potential problem of seeking to position 0 for image subtitles on init, and if the start position is not at the beginning of the timeline.
* player: refactor: eliminate MPContext.d_videowm42016-01-171-1/+2
| | | | | | | | | | | | | | Eventually we want the VO be driven by a A->V filter, so a decoder doesn't even have to exist. Some features definitely require a decoder though (like reporting the decoder in use, hardware decoding, etc.), so for each thing which accessed d_video, it has to be redecided if and how it can access decoder state. At least the "framedrop" property slightly changes semantics: you can now always set this property, even if no video is active. Some untested changes in this commit, but our bio-based distributed test suite has to take care of this.
* player: refactor: eliminate MPContext.d_subwm42016-01-171-35/+55
| | | | The same is g