summaryrefslogtreecommitdiffstats
path: root/sub
Commit message (Collapse)AuthorAgeFilesLines
* sub: always recreate ASS_Renderer on subtitle decoder reinitwm42015-12-264-38/+74
| | | | | | | 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-262-13/+4
| | | | | | | | | | | | 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.)
* sub: clear subtitle list when crossing timeline boundarywm42015-12-252-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When crossing timeline boundaries (such as switching to a new segment or chapter with ordered chapters), clear the internal text subtitle list. This breaks the sub-seek command, but is otherwise not too harmful. Fixes Sub-OC-test-final7.mkv. (The internal text subtitle list is basically a cache to make subtitles show up at the right time when seeking back.) I suspect this was caused by 76fcef61. The sample file times subtitles slightly before the video frame when it should show up. This is to avoid problems with subtitles showing up a frame later than intended. It also means that a subtitle which is supposed to show up on the start of a timeline part boundary actually might first be shown in a different part. Since we now manipulate the packet timestamps, instead of manipulating timestamps after the subtitle decoder, this means this subtitle event would have 2 timestamps, which our code of course does not handle. If the two parts come one after another, this would actually work (since the subtitle would have the same timestamps in the old and new part), but it breaks if the new part (which follows the old part in the physical file) is has a completely different start time in the timeline. Essentially, the trick used to time subtitles correctly is incompatible with the way we cache subtitles (to make them survive seeks). The simple solution is just clearing the cached subtitles when crossing chapter boundaries.
* sub: use macros to remove code duplicationwm42015-12-241-49/+31
| | | | Meh.
* sub: merge bitmap render functions into one for each kindwm42015-12-241-84/+45
| | | | | | | | | | Merge blend_src8_alpha and blend_src16_alpha into blend_src_alpha, and the same for blend_const_alpha. One thing that changes is that the vertical loop is now shared for both code paths. I think this is slightly easier to read, and it's a bit shorter as well.
* sub: remove "inaccurate" code pathwm42015-12-241-10/+0
| | | | | | The "accurate" one always has been enabled, and I can't find much evidence that the "inaccurate" one is much faster on my particular machine anyway.
* sub: find GBRP format automatically when rendering to RGBwm42015-12-241-12/+11
| | | | | | | | | | | | | | | | This removes the need to define IMGFMT_GBRAP, which fixes compilation with the current Libav release. This also makes it automatically pick up a GBRP format with the same bit width. (Unfortunately, it seems libswscale does not support conversion to AV_PIX_FMT_GBRAP16, so our code falls back to 8 bit, removing precision for video covered by subtitles in cases this code is used.) Also, when the source video is e.g. 10 bit YUV, upsample to 16 bit. Whether this is good or bad, it fixes behavior with alpha. Although I'm not sure if the alpha range is really correct ([0,2^16-1] vs. [0,255*256]). Keep in mind that libswscale doesn't even agree with the way we do it.
* sub: better alpha blending when rendering to alpha surfaceswm42015-12-241-1/+35
| | | | | | | | | | | This actually treats destination alpha correctly, and gives much better results than before. I don't know if this is perfectly correct yet, though. Slight difference with vo_opengl behavior suggests it might not be. Note that this does not affect VOs with true alpha support. vo_opengl does not use this code at all, and does the alpha calculations in OpenGL instead.
* dec_sub: avoid segfault on sub_init_decoder failureAman Gupta2015-12-221-1/+2
| | | | | | Broken by commit 687b552d. Signed-off-by: wm4 <wm4@nowhere>
* sd_ass: handle --sub-clear-on-seek correctly with non-ASS subswm42015-12-201-1/+3
| | | | | | Converted subtitles use a different method to avoid adding repeated packets as duplicate subtitle events. The state for this mechanism must be cleared as well if --sub-clear-on-seek is used.
* lavc_conv: fix invalid writewm42015-12-191-3/+2
| | | | | Well shit. Restructure it such that the returned list is always NULL- terminated with the same mechanism.
* video: switch from using display aspect to sample aspectwm42015-12-193-12/+6
| | | | | | | | | | | | | | | | MPlayer traditionally always used the display aspect ratio, e.g. 16:9, while FFmpeg uses the sample (aka pixel) aspect ratio. Both have a bunch of advantages and disadvantages. Actually, it seems using sample aspect ratio is generally nicer. The main reason for the change is making mpv closer to how FFmpeg works in order to make life easier. It's also nice that everything uses integer fractions instead of floats now (except --video-aspect option/property). Note that there is at least 1 user-visible change: vf_dsize now does not set the display size, only the display aspect ratio. This is because the image_params d_w/d_h fields did not just set the display aspect, but also the size (except in encoding mode).
* sub: remove unused video width/height headerswm42015-12-183-14/+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: rename sd_lavc_conv.c to lavc_conv.cwm42015-12-181-0/+0
| | | | | | | | The previous commit turned sd_lavc_conv from a sd_driver to free-standing functions. Do the rename to reflect this change separately to avoid confusing git's content tracking. (Or did git solve this, making separating renames and content changes unnecessary?)
* sub: remove subtitle filter chain conceptwm42015-12-186-293/+122
| | | | | | | | | | | | | It was stupid. The only thing that still effectively used it was sd_lavc_conv - all other "filters" were the subtitle decoder/renderers for text (sd_ass) and bitmap (sd_lavc) subtitles. While having a subtitle filter chain was interesting (and actually worked in almost the same way as the audio/video ones), I didn't manage to use it in a meaningful way, and I couldn't e.g. factor secondary features like fixing subtitle timing into filters. Refactor the shit and drop unneeded things as it goes.
* sub: do not clear subtitle list on seekingwm42015-12-184-28/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This affects non-ASS text subtitles (those which go through libavcodec's subtitle converter), which are muxed with video/audio. (Typically srt subs in mkv.) The problem is that seeking in the file can send a subtitle packet to the decoder multiple times. These packets are interlaved with video, and thus can't be all read when opening the file. Rather, subtitle packets can essentially be randomly skipped or repeated (by seeking). Until recently, this was solved by scanning the libass event list for duplicates. Then our builtin srt-to-ass converter was removed, and the problem was handled by fully clearing the subtitle list on each seek. This resulted in sub-seek not working properly for this type of file. Since the subtitle list was cleared on seek, it was not possible to do e.g. sub-seeks to subtitles before the current playback position. Fix this by not clearing the list, and intead explicitly rejecting duplicate packets. We use the packet file position was unique ID for subtitles; this is confirmed working for most file formats (although it is slightly risky - new demuxers may not necessarily set the file position to something unique, or at all). The list of seen packets is sorted, and the lookup uses binary search. This is to avoid quadratic complexity when subtitles are added in bulks, such as when opening a text subtitle file. In some places, the code has to be adjusted to pass through the packet file position correctly.
* sd_ass: remove dead codewm42015-12-173-65/+7
| | | | | | | | | | | | | | | | | | | | | | | | With the FFmpeg subtitle decoder used for _all_ non-ASS text subtitle format, this code is simply unused now. Ironically, the FFmpeg subtitle decoder does not handle things correctly in a bunch of cases. Should it turn out they actually matter, they will have to hack back. The extend_event one is a candidate, although even though there were allegedly files which need it, I couldn't get samples from the user who originally reported such files. As such, extend_event was only confirmed to handle trailing events with no (endless) duration like with MicroDVD and LRC, but FFmpeg "fudges" these anyway, so no special handling is needed. This code also had logic to handle seeking with muxed srt subtitles, which made the sub-seek command work. But this has been broken before this commit already. Currently, seeking with muxed srt subs will clear all subtitles, as the broken FFmpeg ASS format output by the libavcodec subtitle converters does not check for duplicates. Since the subtitles are all cleared, ass_step_sub() can not work properly and sub-seek can not seek to already seen subtitles.
* sub: detect charset in demuxerwm42015-12-171-42/+5
| | | | | | | | | | | | Slightly simpler, and removes the need to pre-read all subtitle packets. This still does the subtitle charset conversion on the packet level (instead converting when parsing the file), so in theory this still could provide a way to change the charset at runtime. But maybe even this should be removed, as FFmpeg is somewhat likely to get its own charset detection and conversion mechanism in the future. (Would have to keep the subtitle file in memory to allow changing the charset on the fly, I guess.)
* sub: remove sd_srt.cwm42015-12-152-479/+0
| | | | | | | | The FFmpeg subtitle converter does the same. There used to be some deficiencies in FFmpeg's code, but it seems at least some of them have been fixed. There also used to be the timestamp issue (see previous commit messages), but this doesn't matter anymore. So no reason to keep this code - get rid of it.
* sub: remove sd_microdvd.cwm42015-12-152-346/+0
| | | | | | | This can be dropped for the same reasons as in the previous commits. It removes MicroDVD conversion support on Libav, although MicroDVD files couldn't be read in the first place ever since demux_subreader.c was removed.
* sub: remove sd_lavf_srt.cwm42015-12-152-96/+0
| | | | | | | This restored timestamps when demuxing srt subtitles in Libav, which was important for avoiding slightly overlapping subtitles. Since the way this works was changed, there is no real reason to maintain proper timestamps anymore on this level - this can be dropped without issues.
* sub: remove sd_movtext.cwm42015-12-152-63/+1
| | | | | libavcodec's movtext-to-ass converter does the same and has more features. On Libav, this commit disables mp4 subtitle display.
* csputils: rename "yuv2rgb" functionswm42015-12-092-5/+5
| | | | | | They're not necessarily restricted to YUV aka YCbCr. vo_direct3d.c and demux_disc.c (DVD specific code) changes untested.
* csputils: remove obscure int_bits matrix scalingwm42015-12-092-12/+9
| | | | | | | This has no reason to be there. Put the functionality into another function instead. While we're at it, also adjust for possible accuracy issues with high bit depth YUV (matters for rendering subtitles into screenshots only).
* sub: increase gap/overlap fixing threshold to 210mswm42015-12-071-2/+2
| | | | Don't ask why.
* sd_ass: slightly better heuristic for applying --sub-fix-timingwm42015-12-061-1/+10
| | | | | | | | | | | Fixes a reported sample, that has a sign interrupted by a few frames (for which --sub-fix-timing would remove the wanted gap). The list of tags in has_overrides() is taken from libass. It has a similar function (which even checks whether the tag are within the { } delimiters). Unfortunately, this function is not public, so we just have a simpler one which does roughly the same. It doesn't matter that this function sometimes returns false positives.
* sub: another minor simplificationwm42015-12-061-6/+5
|
* sub: minor simplificationswm42015-12-051-30/+10
| | | | | | | | | | The awkward "preprocess" step of putting the subtitles through single filters before doing something else was made unnecessary by the recent changes. (Fun fact: I originally planned to move these extra things, like fixing subtitle gaps/overlaps, to filters - but this would suffer from various complications, and moving them to the renderers seems much simpler.)
* sub: move subtitle FPS adjustment to sd_ass.cwm42015-12-053-31/+28
| | | | | | | | | I feel like it's better there. Note that there is no reduced functionality, as bitmaps subs (i.e. not handled by sd_ass.c) were never fully read on init, and thus never went through sub_read_all_packets(). On the other hand, this might lead to confusion, as --sub-fps etc. will now also affect muxed subtitles (which makes not much sense).
* sub: move --sub-fix-timing handling to rendererwm42015-12-052-36/+69
| | | | | | | | | | | | | | | | | Instead of messing with the subtitle packet timestamps, do it on output. We work on the libass event list. If there is an unwanted gap or overlap, we render the timestamp at another position where there is no gap or overlap. This is somewhat more robust, and even works with demuxed subs (to some degree - depends whether the subs are prefected soon enough). It's active even for native ASS subs. I wonder if this is a problem with extended type setting. If it is, the heuristic that tries to avoid interrupting such cases has to be improved. While it probably would be ideal to do this after the subtitle decoder, certain aspects are at least currently handled better in this place.
* sd_lavc: remove small gaps between subtitleswm42015-12-053-2/+10
| | | | | Just like with text subtitles. Move the magic constants to a common place too.
* sd_lavc: discard empty subtitles and improve sub_seek behaviorwm42015-12-051-27/+49
| | | | | | | | | | | Image subtitles often use a "signaling" packet to set the end time of the previous subtitle. As far as the libavcodec API is concerned, such packets decode to empty AVSubtitles. Discard these after the end time of the previous subtitle has been set. Keep track of the per-subtitle end time better. This is for the sake of improving sub_step/sub_seek. Without this, it would seek to the sub before the previous sub, if the current sub has ended displaying.
* sd_lavc: implement sub_step/sub_seekwm42015-12-051-0/+76
| | | | | | | | | Works roughly the same as the one in sd_ass for text subtitles. While sub_step is very uninteresting, it comes for free with the support for sub_seek. The implementation is taken from ass_step_sub() from libass, with some modifications
* sub: allow feeding bitmap subs in advancewm42015-12-054-8/+44
| | | | | | | | | | | | | | | | | | | | | | | 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.
* sub: remove unused function, move another onewm42015-11-293-40/+24
| | | | | mp_ass_default_track() was not used by anything anymore (commit 5a89150a got rid of it). mp_ass_add_default_styles() is used by sd_ass.c only.
* osd: fix and cleanup font style managementwm42015-11-292-48/+62
| | | | | | | | | | | Commit 2b07d3eb merged progbar and OSD text renderer into one ASS_Track, but it confused the styles. Specifically, if both progbar and OSD are visible, the create_ass_track() call made by the progbar code will reset the style adjusted by the OSD text code. Change create_ass_track() not to add any styles. Instead let the caller manage the styles. They are now referenced by name, and lazily added if they don't exist yet. This is also much cleaner.
* osd: use the same ASS_Renderer for OSD text and progbarwm42015-11-284-32/+43
| | | | | | Reduces memory usage and startup times. The implementation is a bit weird, because both OSD parts have conflicting requirements on the used ASS styles.
* sd_ass: fix secondary subtitle modewm42015-11-221-1/+1
| | | | | | | If a second subtitle is shown, it should be forced to display on top of the screen. This was working only if --no-ass was passed, because otherwise the subtitle was rendered normally (i.e. usually on the bottom).
* player: remove OSD subtitle render pathwm42015-11-176-64/+78
| | | | | | | | | | | | | | | | | | | 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-162-2/+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: remove an unneeded old hack for MicroDVDwm42015-11-161-11/+0
| | | | This happens to be handled in a better way in another place now.
* sub: remove use of semi-deprecated libass fieldwm42015-10-281-1/+0
| | | | | In newer libass version, this does nothing, and will be removed on the next API/ABI bump.
* Replace deprecated av_free_packet() callswm42015-10-281-3/+3
| | | | | | av_free_packet() got finally deprecated. Use av_packet_unref() instead, which has almost the same semantics, has existed for a while, and is available in all FFmpeg and Libav versions we support.
* options: remove --use-text-osdwm42015-10-241-3/+0
|
* sd_lavc: take care of AVPicture deprecationwm42015-10-231-3/+12
|
* sub: adjust behavior on mismatching video/subtitle aspect mismatchwm42015-10-211-7/+2
| | | | | | | | | | | | | | | | If the aspect ratio of the video resolution and the subtitle resolution (the implied subtitle coordinate system) mismatch, the subtitles obviously can't be overlayed over the video perfectly. Either you get video that can't be covered by subtitles, or the subtitles could go beyond the video. We don't want to stretch the subtitle to compensate for the aspect ratio, because it would look terrible. Until now, mpv used to fit the subtitle rectangle into the video rectangle (letterboxing/pillarboxing). This looks odd with some sample files with subtitle canvas being wider than the video. Also, mpc-hc displays them in a better way. vlc stretches them, which looks bad. While you probably can't win this game with all those broken files around, pick the mpc-hc method to handle this.
* sd_lavc: extend subtitle resolution if images go outsidewm42015-10-211-0/+9
| | | | | | | | | | | | | | | Helps with broken vobsubs, which have an incorrect resolution header set. So we just extend the subtitle resolution to the video size, if the video size is larger. This helps somewhat with readability, or makes them visible at all. It should be a pretty safe change, because normally no sub pictures are supposed to go outside of the area. It should make a difference with broken files only. The sample in question had a video resolution of 1888x1072, and a subtitle resolution of 720x480. Note that always using video resolution as subtitle resolution would break other files.
* Take care of libavcodec convergence_duration deprecationwm42015-09-291-0/+2
| | | | | | This AVPacket field was a hack against the fact that the duration field was merely an int (too small for things like subtitle durations). Newer libavcodec drops this field and makes duration 64 bit.
* player: rename and move find_subfiles.cwm42015-09-202-319/+0
| | | | | | This was in sub/, because the code used to be specific to subtitles. It was extended to automatically load external audio files too, and moving the file and renaming it was long overdue.
* player: add opus to list of external audio file extensionswm42015-09-201-1/+1
| | | | Fixes #2336.
* osd: delay libass initialization as far as possiblewm42015-09-071-5/+9
| | | | | | | | | | | | Until now, most OSD objects created the associated ASS_Renderer instance as soon as possible, even if nothing was going to be rendered. Maybe this was even intentional. Change this for the sake of lowering resource usage, and strictly initialize ASS_Renderer only when it's really needed. For the OSC, initialization has to be forced, because of the insane mechanism for translating mouse coordinates to OSD coordinates.
* sub: always try to use libavcodec text subtitle converterwm42015-09-011-12/+4
| | | | | | | | | | | | Drop the whitelist. It's annoying to maintain. Instead, accept any subtitle decoder. Since this code path will now also be taken by bitmap subtitle decoders not whitelisted by sd_lavc.c, add a warning when bitmap subtitles are decoded. (To reduce or increase potential user confusion.) To some degree, a whitelist is needed to distinguish text and bitmap subtitles. FFmpeg has an API to distinguish them in a generic way to some degree, but Libav doesn't. So we just stick with this for now.
* sd_ass: assume negative durations are unknown durations, and handle themwm42015-08-271-5/+27