aboutsummaryrefslogtreecommitdiffhomepage
path: root/player/sub.c
Commit message (Collapse)AuthorAge
* video: make decoder wrapper a filterGravatar wm42018-01-30
| | | | | | | | | | | | | | | | | | | | | | | | | 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 codeGravatar wm42018-01-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 placeGravatar wm42018-01-02
| | | | | | | | | | | | | | | | | 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 LGPLGravatar wm42017-06-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 tooGravatar wm42016-10-31
| | | | | | | | | | | 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 progressGravatar wm42016-10-30
| | | | | | 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 usedGravatar wm42016-10-26
| | | | | | | | | | | | | | | | | | | | | 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 switchesGravatar wm42016-09-24
| | | | | | | | | | | | | | | | | | | | | | | | 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 codeGravatar wm42016-03-08
| | | | | | 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 robustGravatar wm42016-03-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 decoderGravatar wm42016-03-03
| | | | | | | | | | | | | | | | | 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 seekingGravatar wm42016-02-28
| | | | | | | | | | | | | | | | | | | 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/disabledGravatar wm42016-02-25
| | | | | 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 completelyGravatar wm42016-01-22
| | | | | | | | | | | | 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_videoGravatar wm42016-01-17
| | | | | | | | | | | | | | 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_subGravatar wm42016-01-17
| | | | The same is going to happen to d_video and d_audio later.
* video: decouple filtering/decoding slightly moreGravatar wm42016-01-14
| | | | | | | | | | | | | | | | | | | 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 decoderGravatar wm42016-01-14
| | | | | | | | | | 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_subGravatar wm42016-01-12
| | | | | | | | | | 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.hGravatar Dmitrij D. Czarkoff2016-01-11
| | | | This change helps avoiding conflict with talloc.h from libtalloc.
* sub: change how subtitles are readGravatar wm42015-12-29
| | | | | | | | 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 initializationGravatar wm42015-12-27
| | | | | | | | 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 setGravatar wm42015-12-27
| | | | | | | | | 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 subsGravatar wm42015-12-26
| | | | | | | 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 reinitGravatar wm42015-12-26
| | | | | | | 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 streamGravatar wm42015-12-26
| | | | | | | | | | | | 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 listGravatar wm42015-12-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 headersGravatar wm42015-12-18
| | | | | | | 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 advanceGravatar wm42015-12-05
| | | | | | | | | | | | | | | | | | | | | | | 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 pathGravatar wm42015-11-17
| | | | | | | | | | | | | | | | | | | 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 handlingGravatar wm42015-11-16
| | | | | | | | | 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 onceGravatar wm42015-07-13
| | | | | | | | | | | | | 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 stateGravatar wm42015-07-06
| | | | | | | | | | | | | | | | | | | 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 headersGravatar Marcin Kurczewski2015-04-13
| | | | Signed-off-by: wm4 <wm4@nowhere>
* build: fix warnings with --disable-libassGravatar wm42015-03-04
| | | | This crap seems to break every other fullmoon.
* player: enable cache and demuxer thread for subtitles tooGravatar wm42015-02-18
| | | | | | | | | 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-sidGravatar wm42015-01-13
| | | | Fises #1463.
* player: fix random crashes on uninitializationGravatar wm42014-12-27
| | | | | | | | | | | 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 functionGravatar wm42014-12-27
| | | | | Something which has this many important sideffects shouldn't start have a "get" prefix.
* sub: reset sub decoder correctly when cycling subtitlesGravatar wm42014-12-21
| | | | | | | | | | 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 aroundGravatar wm42014-12-21
| | | | Separate commit to reduce noise in the following one.
* build: fix --disable-libassGravatar wm42014-12-08
| | | | | | Still supported, but obviously untested. You shouldn't use this option anyway.
* sub: remove assertionGravatar wm42014-12-07
| | | | | | | | | | | 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 subtitlesGravatar wm42014-11-23
| | | | | | Recent regression. It turns out the assertion was completely unneeded. Fixes #1285.
* sub: workaround braindead libass APIGravatar wm42014-11-15
| | | | | | | | | | | | | | | | 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()Gravatar wm42014-11-01
| | | | | Trades one strange thing against another, but seems slightly less strange.
* sub: be more flexible about changes to how subtitles are renderedGravatar wm42014-10-31
| | | | | | | | | 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.cGravatar wm42014-10-03
| | | | | | | | | | | | | | | 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 messGravatar wm42014-10-03
| | | | | | | | | | | | | | 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 modeGravatar wm42014-09-25
| | | | | | | | | | | | | | | | | | | | | | 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.