path: root/player/sub.c
Commit message (Collapse)AuthorAgeFilesLines
* 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: 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 going to happen to d_video and d_audio later.
* video: decouple filtering/decoding slightly morewm42016-01-141-2/+2
| | | | | | | | | | | | | | | | | | | Lots of noise to remove the vfilter/vo fields from dec_video. From now on, video filtering and output will still be done together, summarized under struct vo_chain. There is the question where exactly the vf_chain should go in such a decoupled architecture. The end goal is being able to place a "complex" filter between video decoders and output (which will culminate in natural integration of A->V filters for natural integration of libavfilter audio visualizations). The vf_chain is still useful for "final" processing, such as format conversions and deinterlacing. Also, there's only 1 VO and 1 --vf option. So having 1 vf_chain for a VO seems ideal, since otherwise there would be no natural way to handle all these existing options and mechanisms. There is still some work required to truly decouple decoding.
* video: refactor: handle video format fixups closer to decoderwm42016-01-141-1/+1
| | | | | | | | | | Instead of handling this on filter chain reinit, do it directly after the decoder. This makes the code less entangled. In particular, this gets rid of the really weird "override params" concept in the video filter code. The last_format/fixed_formats have some redundance with decoder_output, but unfortunately the latter has a slightly different use.
* demux: merge sh_video/sh_audio/sh_subwm42016-01-121-3/+3
| | | | | | | | | | This is mainly a refactor. I'm hoping it will make some things easier in the future due to cleanly separating codec metadata and stream metadata. Also, declare that the "codec" field can not be NULL anymore. demux.c will set it to "" if it's NULL when added. This gets rid of a corner case everything had to handle, but which rarely happened.
* mpv_talloc.h: rename from talloc.hDmitrij D. Czarkoff2016-01-111-1/+1
| | | | This change helps avoiding conflict with talloc.h from libtalloc.
* sub: change how subtitles are readwm42015-12-291-54/+16
| | | | | | | | Slightly change how it is decided when a new packet should be read. Switch to demux_read_packet_async(), and let the player "wait properly" until required subtitle packets arrive, instead of blocking everything. Move distinguishing the cases of passive and active reading into the demuxer, where it belongs.
* sub: refactor initializationwm42015-12-271-16/+20
| | | | | | | | Just simplify by removing parts not needed anymore. This includes merging dec_sub allocation and initialization (since things making initialization complicated were removed), or format support queries (it simply tries to create a decoder, and if that fails, tries the next one).
* sub: minor refactor how video FPS for MicroDVD is setwm42015-12-271-4/+4
| | | | | | | | | So that the video FPs is not required at initialization, and can be set later. (As for whether this MicroDVD crap is worth the trouble to handle it "correctly": MicroDVD files are unfortunately still around, and in at least one case using the video FPS seemed to help indeed.)
* sub: destroy/recreate ASS_Renderer when disabling/enablings subswm42015-12-261-0/+2
| | | | | | | Keeping ASS_Renderers around for a potentially large number of subtitle tracks could lead to excessive memory usage, especially since the libass cache is broken (caches even unneeded data), and might consume up to ~500MB of memory for no reason.
* sub: always recreate ASS_Renderer on subtitle decoder reinitwm42015-12-261-98/+1
| | | | | | | This includes the case of switching ordered chapter boundaries. It will now be recreated on each timeline part switch. This shouldn't be much of a problem with modern libass. (Older libass versions use fontconfig for memory fonts, and will be very slow to reinitialize memory fonts.)
* sub: cache subtitle state per track instead of per demuxer streamwm42015-12-261-24/+10
| | | | | | | | | | | | Since commit 6d9cb893, subtitle state doesn't survive timeline switches (ordered chapters etc.). So there is no point in caching the state per sh_stream anymore (which would be required to deal with multiple segments). Move the cache to struct track. (Whether it's worth caching the subtitle state just for the situation when subtitle tracks get reselected is questionable. But for now, it's nice to have the subtitles immediately show up when reselecting a subtitle.)
* demux: remove weird tripple-buffering for the sh_stream listwm42015-12-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The demuxer infrastructure was originally single-threaded. To make it suitable for multithreading (specifically, demuxing and decoding on separate threads), some sort of tripple-buffering was introduced. There are separate "struct demuxer" allocations. The demuxer thread sets the state on d_thread. If anything changes, the state is copied to d_buffer (the copy is protected by a lock), and the decoder thread is notified. Then the decoder thread copies the state from d_buffer to d_user (again while holding a lock). This avoids the need for locking in the demuxer/decoder code itself (only demux.c needs an internal, "invisible" lock.) Remove the streams/num_streams fields from this tripple-buffering schema. Move them to the internal struct, and protect them with the internal lock. Use accessors for read access outside of demux.c. Other than replacing all field accesses with accessors, this separates allocating and adding sh_streams. This is needed to avoid race conditions. Before this change, this was awkwardly handled by first initializing the sh_stream, and then sending a stream change event. Now the stream is allocated, then initialized, and then declared as immutable and added (at which point it becomes visible to the decoder thread immediately). This change is useful for PR #2626. And eventually, we should probably get entirely of the tripple buffering, and this makes a nice first step.
* sub: remove unused video width/height headerswm42015-12-181-3/+0
| | | | | | | Apparently, this was replaced by the SD_CTRL_SET_VIDEO_PARAMS set dimensions. But I can't find out when this happened - possibly, these fields were never used by sd_lavc.c, and only by the (long removed) MPlayer dvdsub decoder.
* sub: allow feeding bitmap subs in advancewm42015-12-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | Until now, feeding packets to the decoder in advance was done for text subtitles only. This was possible because libass buffers all subtitle data anyway (in ASS_Track). sd_lavc, responsible for bitmap subs, does not do this. But it can buffer a small number of subtitle frames ahead. Enable this. Repurpose the sub_accept_packets_in_advance(). Instead of "can take all packets" it means "can take 1 packet" now. (The old meaning is still needed locally in dec_sub.c; keep it there.) It asks the decoder whether there is place for at least 1 subtitle packet. sd_lavc implements it and returns true if its internal fixed-size subtitle queue still has a free slot. (The implementation of this in dec_sub.c isn't entirely clean. For one, decode_chain() ignores this mechanism, so it's implied that bitmap subtitles do not use the subtitle filter chain in any advanced way.) Also fix 2 bugs in the sd_lavc queue handling. Subtitles must be checked in reverse, because the first entry will often have endpts==NOPTS, which would always match. alloc_sub() must cycle the queue buffer, because it reuses memory allocations (like sub.imgs) by design.
* player: remove OSD subtitle render pathwm42015-11-171-46/+7
| | | | | | | | | | | | | | | | | | | This was used with --no-sub-ass (aka --no-ass). This option (which is not yet removed) strips all styling from the subtitles, and renders them as plaintext only. For some reason, it originally seemed convenient to reuse all the OSD text rendering code (osd_libass.c). While this was indeed simple, it had a bad influence on the rest of the code. For example, it had to decide whether to go through the OSD code path, or the proper subtitle renderer in sd_ass.c. Kill the OSD subtitle renderer. Reimplement --no-sub-ass and also "secondary" subtitles in sd_ass.c. fill_plaintext() contains some rather minor code duplication with osd_libass.c for setting up a dummy ASS_Event and escaping the stripped text. Since sd_ass.c already has to handle "normal" text subtitles, and has code for stripping ASS tags, this remains all relatively simple. Remove all the unnecessary crap from the rest of the code.
* player: use demuxer ts offset to simplify timeline ts handlingwm42015-11-161-3/+1
| | | | | | | | | Use the demux_set_ts_offset() added in the previous commit to base each timeline segment to use timestamps according to its relative position within the overall timeline. As a consequence we don't need to care about these timestamps anymore, and everything becomes simpler. (Another minor but delicious nugget of sanity.)
* sub: call ass_set_fonts() only oncewm42015-07-131-10/+3
| | | | | | | | | | | | | ass_set_fonts() is called by mp_ass_configure_fonts(), which was called every time a subtitle renderer was initialized. I'm not sure why this was done - I can't find a good reason, and most likely there's none. However, it did cause problems with an experimental libass branch. It crashed some time after switching to a second subtitle track. The branch will hopefully be merged soon, and it seems unlikely that libass wants to fix its problems with its ridiculous API (rather it should normalize its API so that the issue doesn't happen in the first place), so just apply this change. It makes our code simpler too.
* sub: protect ASS_Renderer statewm42015-07-061-1/+4
| | | | | | | | | | | | | | | | | | | Each subtitle track gets its own decoder instance (sd_ass). But they use a shared ASS_Renderer. This is done mainly because of fontconfig. Initializing fontconfig is very slow when using it with memory fonts, so there's a practical need to cache this memory font state, which is done by not creating separate ASS_Renderers. This is very dirty and very evil, but we probably can't get rid of it any time soon. The shared ASS_Renderer was not properly synchronized. While the program logic guarantees that only one sd_ass instance is visible at a time, there are other interactions that require synchronization. In particular, I suspect concurrent execution of mp_ass_configure_fonts() and sd_ass.get_bitmaps cause issues in a newer libass development branch. So here's a shitty hack that hopefully fixes things, hopefully only until libass becomes less dependent on fontconfig.
* Update license headersMarcin Kurczewski2015-04-131-5/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* build: fix warnings with --disable-libasswm42015-03-041-2/+2
| | | | This crap seems to break every other fullmoon.
* player: enable cache and demuxer thread for subtitles toowm42015-02-181-0/+2
| | | | | | | | | Includes some logic for not starting the demuxer thread for fully read subtitles. (Well, the cache will still waste _lots_ of resources, and the cache always has to be created, because we don't know whether it'll be needed _before_ opening the file.) See #1597.
* player: fix crash wtih --secondary-sidwm42015-01-131-2/+3
| | | | Fises #1463.
* player: fix random crashes on uninitializationwm42014-12-271-0/+1
| | | | | | | | | | | On uninitialization, the player will unselect all subtitles, and then destroy the subtitle decoder. But it didn't correctly remove the subtitle decoder from the OSD state, so it could happen that it would access it after the decoder was destroyed. Could lead to random crashes when switching files often. Fixes #1389.
* player: cosmetics: rename a functionwm42014-12-271-4/+4
| | | | | Something which has this many important sideffects shouldn't start have a "get" prefix.
* sub: reset sub decoder correctly when cycling subtitleswm42014-12-211-3/+1
| | | | | | | | | | reset_subtitles() works in mpctx->d_sub[], which is set to NULL before calling it from uninit_sub(). This fixes resetting the subtitle when cycling subtitle tracks. Actually, this was probably a feature, because it's annoying if subtitles don't show up when cycling them. But it also can have unintended consequences, so get rid of it.
* player: cosmetics: move code aroundwm42014-12-211-15/+15
| | | | Separate commit to reduce noise in the following one.
* build: fix --disable-libasswm42014-12-081-2/+2
| | | | | | Still supported, but obviously untested. You shouldn't use this option anyway.
* sub: remove assertionwm42014-12-071-2/+1
| | | | | | | | | | | This should clearly be impossible, but it seems to happen with ordered chapters for a user. Since I can't tell what the actual bug is and it seems impossible to know the details without downloading possibly huge files, this is probably the best we can do. Should at least partially fix #1319.
* player: don't crash when using sub_seek without subtitleswm42014-11-231-2/+0
| | | | | | Recent regression. It turns out the assertion was completely unneeded. Fixes #1285.
* sub: workaround braindead libass APIwm42014-11-151-7/+14
| | | | | | | | | | | | | | | | libass won't use embedded fonts, unless ass_set_fonts() (called by mp_ass_configure_fonts()) is called. However, we call this function when the ASS_Renderer is initialized, which is long before the .ass file is actually loaded. (I'm not sure why it tries to keep 1 ASS_Renderer, but it always did this.) Fix by calling mp_ass_configure_fonts() after loading them. This also means this function will be called multiple times - hopefully this is harmless (it will reinit fontconfig every time, though). While we're at it, also initialize the ASS_Renderer lazily. Fixes #1244.
* sub: remove osd_get_sub()wm42014-11-011-4/+4
| | | | | Trades one strange thing against another, but seems slightly less strange.
* sub: be more flexible about changes to how subtitles are renderedwm42014-10-311-20/+32
| | | | | | | | | For example, if --force-window is used, and video is switched off during playback, then you need to redecide the rendering method to get subs displayed correctly. Do this by moving the state setup code into a function, and call it on every frame.
* player: move some libass setup code to sub.cwm42014-10-031-0/+94
| | | | | | | | | | | | | | | Also recreate ASS_Library on every file played. This means we can move the code out of main.c as well. Recreating the ASS_Library object has no disadvantages, because it literally stores only the message callback, the (per-file) font attachment as byte arrays, and the set of style overrides. Hopefully this thing can be removed from the libass API entirely at some point. The only reason why the player core creates the ASS_Renderer, instead of the subtitle renderer, is because we want to cache the loaded fonts across ordered chapter transitions, so this probably still has to stay around for now.
* player: remove central uninit_player() function and flags messwm42014-10-031-24/+27
| | | | | | | | | | | | | | Each subsystem (or similar thing) had an INITIALIZED_ flag assigned. The main use of this was that you could pass a bitmask of these flags to uninit_player(). Except in some situations where you wanted to uninitialize nearly everything, this wasn't really useful. Moreover, it was quite annoying that subsystems had most of the code in a specific file, but the uninit code in loadfile.c (because that's where uninit_player() was implemented). Simplify all this. Remove the flags; e.g. instead of testing for the INITIALIZED_AO flag, test whether mpctx->ao is set. Move uninit code to separate functions, e.g. uninit_audio_out().
* sub: approximate subtitle display in no-video modewm42014-09-251-0/+3
| | | | | | | | | | | | | | | | | | | | | | This makes subtitle display somewhat work if no video is displayed, but a VO window exists (--force-window or cover art display). The main problem with normal subtitle display is that it's locked to video: it uses the video PTS as reference, and the subtitles advance only if a new video frame is displayed. In audio-only mode on the other hand, no video frame is ever displayed (or only 1 in the cover art case). You would need a workaround to adjust the subtitle PTS, and you would have to decide with what frequency to update the display. In general, there is no "right" display FPS for subtitles. Some formats (ASS) have animations parameterized by time, and any refresh rate could be used. Sidestep these problems by enabling the text OSD-based subtitle mechanism. This is similar to --no-sub-ass, and updates and renders subtitles with plain OSD. It has some caveats: no bitmap subs, somewhat incorrect timing, no formatting. Timing in particular is a bit strange and depends how often the audio output asks for new data, or other events that happen to wakeup the playloop.
* sub: fix possible deadlock with --no-sub-ass and similarwm42014-09-061-6/+1
| | | | | | | | | | | | | | | This is a deadlock caused by a lock order issue: sub/osd.c locks the OSD first, then the subtitle decoder lock. player/sub.c does the reverse. Fix this by discussing away the requirement for locking (see below), which allows us to drop the broken sub lock. sub_get_text() still acquires and releases the sub decoder lock, but it's not held at the same time as the OSD lock anymore, so it should be fine. Originally, the sub lock was acquired because sub_get_text() returns a pointer to a mutable string. We simply declare that it's ok to call it unlocked, as long as only 1 thread accesses it, which works out fine in this case.
* player: use virtual time for --audio-file with ordered chapterswm42014-08-151-8/+1
| | | | | | | | | Apparently users prefer this behavior. It was used for subtitles too, so move the code to calculate the video offset into a separate function. Seeking also needs to be fixed. Fixes #1018.
* sub: add option to workaround broken mkv fileswm42014-08-141-1/+3
| | | | See additions to options.rst.
* sub: call sub_reset() on seeks onlywm42014-08-141-2/+0
| | | | | | | | | | | | | | | | | sub_reset() was called on cycling subtitle tracks and on seeking. Since we don't want that subtitles disppear on cycling, sd_lavc.c didn't clear its internal subtitle queue on reset, which meant that seeking with PGS subtitles could leave the subtitle on screen (PGS subtitles usually don't have a duration set). Call it only on seeking, so we can also strictly clear the subtitle queue in sd_lavc. (This still can go very wrong if you disable a subtitle, seek, and enable it again - for example, if used with libavformat that uses "SSA" style demuxed ASS subtitle packets. That shouldn't happen with newer libavformat versions, and the user can "correct" it anyway by executing a seek while the subtitle is selected.)
* sub: fix subtitle timing for TSwm42014-08-041-2/+6
| | | | | | | | The subtitle timing logic always used the demuxer's start time as video offset. This made external subtitle files "just work" with file formats like TS, which usually have a non-0 start time. But it was wrong for subtitles muxed with the TS, so adjust the time offset explicitly with external files only.
* sub: don't read packets if video and audio are disabledwm42014-08-041-1/+1
| | | | | | | | | Although disabling both video and audio is surely an obscure corner case, it's allowed, and we don't want the demuxer to skip arbitrary packets. Basically, make the heuristic for checking interleaved files affect external files only.
* player: split seek_reset()wm42014-07-301-0/+6
| | | | | | | | This also reduces some code duplication with other parts of the code. The changfe is mostly cosmetic, although there are also some subtle changes in behavior. At least one change is that the big desync message is now printed after every seek.
* player: fix desync when seeking and switching external trackswm42014-07-291-4/+1
| | | | | | | | | | | | If you for example use --audio-file, disable the external track, seek, and enable the external track again, the playback position of the external file was off, and you would get major A/V desync. This was actually supposed to work, but broke at some time ago (probably commit 2b87415f). It didn't work, because it attempted to seek the stream if it was already selected, which was always true due to reselect_demux_streams() being called before that. Fix by putting the initial selection and the seek together.
* sub: offset subtitle timing to video start PTSwm42014-07-221-1/+2
| | | | | | | | | | | | This allows using external subtitle files with e.g. transport stream files that don't start at time 0. Note that if the .ts file has timestamp resets, everything goes south. But I guess this was already the case before, unless there are external subtitle files that also include timestamp resets, which is unlikely. (On the other hand, you could for example expect that it works with embedded DVB subtitles, that were somehow captured from the same stream and use the same timestamps.)
* dvd, bluray, cdda: add demux_disc containing all related hackswm42014-07-051-41/+0
| | | | | | | | | | | | DVD and Bluray (and to some extent cdda) require awful hacks all over the codebase to make them work. The main reason is that they act like container, but are entirely implemented on the stream layer. The raw mpeg data resulting from these streams must be "extended" with the container-like metadata transported via STREAM_CTRLs. The result were hacks all over demux.c and some higher-level parts. Add a "disc" pseudo-demuxer, and move all these hacks and special-cases to it.
* sub: fix undefined behavior with dvd://wm42014-06-281-1/+1
| | | | | | The string could get reallocated. CC: @mpv-player/stable
* video: handle colorspace and aspect overrides separatelywm42014-05-021-1/+2
| | | | | Now the video filter code handles these explicitly, which should increase robustness (or at least find bugs earlier).
* sub: uglify OSD code path with lockingwm42014-01-181-17/+21
| | | | | | | | | | | | | | | Do two things: 1. add locking to struct osd_state 2. make struct osd_state opaque While 1. is somewhat simple, 2. is quite horrible. Lots of code accesses lots of osd_state (and osd_object) members. To make sure everything is accessed synchronously, I prefer making osd_state opaque, even if it means adding pretty dumb accessors. All of this is meant to allow running VO in their own threads. Eventually, VOs will request OSD on their own, which means osd_state will be accessed from foreign threads.
* sub: uglify sub decoder with lockingwm42014-01-171-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | The plan is to make the whole OSD thread-safe, and we start with this. We just put locks on all entry points (fortunately, dec_sub.c and all sd_*.c decoders are very closed off, and only the entry points in dec_sub.h let you access it). I think this is pretty ugly, but at least it's very simple. There's a special case with sub_get_bitmaps(): this function returns pointers to decoder data (specifically, libass images). There's no way to synchronize this internally, so expose sub_lock/sub_unlock functions. To make things simpler, and especially because the lock is sort-of exposed to the outside world, make the locks recursive. Although the only case where this is actually needed (although trivial) is sub_set_extradata(). One corner case are ASS subtitles: for some reason, we keep a single ASS_Renderer instance for subtitles around (probably to avoid rescanning fonts with ordered chapters), and this ASS_Renderer instance is not synchronized. Also, demux_libass.c loads ASS_Track objects, which are directly passed to sd_ass.c. These things are not synchronized (and would be hard to synchronize), and basically we're out of luck. But I think for now, accesses happen reasonably serialized, so there is no actual problem yet, even if we start to access OSD from other threads.
* Fix subtitle delay inversionMartin Herkt2014-01-061-1/+1
* player: add --secondary-sid for displaying a second subtitle streamwm42013-12-241-45/+80
| | | | | | | This is relatively hacky, but it's Christmas, so it's ok. This does two things: 1. allow selecting two subtitle tracks, and 2. include a hack that renders the second subtitle always as toptitle. See manpage additions how to use this.
* player: add infrastructure to select multiple tracks at oncewm42013-12-241-2/+2
| | | | | Of course this does not allow decoding multiple tracks at once; it just adds some minor infrastructure, which could be used to achieve this.
* player: redo demuxer stream selectionwm42013-12-241-5/+5
| | | | | | | Use struct track to decide what stream to select. Add a "selected" field and use that in some places instead of checking mpctx->current_track.
* sub/osd: mp_msg conversionswm42013-12-211-1/+1
* player: replace some overlooked mp_msgswm42013-12-191-5/+3
| | | | | There are still some using IDENTIFY, and some without context in configfiles.c.
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-171-2/+2
* Move options/config related files from mpvcore/ to options/wm42013-12-171-1/+1
| | | | | | | | | Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
* Rename mp_core.h to core.hwm42013-12-171-1/+1
| | | | Get rid of the mp_ prefix.
* Move mpvcore/player/ to player/wm42013-12-171-0/+233