| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
libavcodec's movtext-to-ass converter does the same and has more
features. On Libav, this commit disables mp4 subtitle display.
|
| |
|
|
|
|
| |
They're not necessarily restricted to YUV aka YCbCr.
vo_direct3d.c and demux_disc.c (DVD specific code) changes untested.
|
| |
|
|
|
|
|
| |
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).
|
| |
|
|
| |
Don't ask why.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.)
|
| |
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Just like with text subtitles. Move the magic constants to a common
place too.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Reduces memory usage and startup times. The implementation is a bit
weird, because both OSD parts have conflicting requirements on the used
ASS styles.
|
| |
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.)
|
| |
|
|
| |
This happens to be handled in a better way in another place now.
|
| |
|
|
|
| |
In newer libass version, this does nothing, and will be removed on the
next API/ABI bump.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
Fixes #2336.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The FFmpeg can officially not distinguish between unknown subtitle
durations, and subtitle durations being 0. (It documents the value 0
meaning unknown duration.)
In practice, at least the LRC demuxer signals unknown subtitle durations
with a negative value.
Assume negative durations mean unknown duration. Show subtitles with
unknown duration forever. Unless there's a subtitle event following it;
then reset the duration so that it ends on the new subtitle event.
Fixes #2244.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nobody wanted to restore this, so it gets the boot.
If anyone still wants to volunteer to restore menu support, this would
be welcome. (I might even try it myself if I feel masochistic and like
wasting a lot of time for nothing.) But if it does get restored, it
should be done differently. There were many stupid things about how it
was done. For example, it somehow tried to pull mp_nav_events through
all the layers (including needing to "buffer" them in the demuxer),
which was needlessly complicated. It could be done simpler.
This code was already inactive, so this commit actually changes nothing.
Also keep in mind that normal DVD/BD playback still works.
|
| |
|
|
|
|
|
|
|
| |
uchardet is written in C++, and thus doesn't appreciate the value of
using static strings, and internally stores the guessed charset as
allocated std::string. Add a minimal hack to deal with this. (I don't
appreciate that the code is potentially harder to understand by
returning either a static or allocated string, but I do appreciate for
not having to litter the existing code with strdups.)
|
| |
|
|
|
|
|
| |
Probably makes users happy who want bitmap subtitles to show up in the
screen margins, and stops them from doing idiotic crap with vf_expand.
Fixes #2098.
|
| |
|
|
| |
Oops.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
MPlayer traditionally had completely separate sh_ structs for
audio/video/subs, without a good way to share fields. This meant that
fields shared across all these headers had to be duplicated. This commit
deduplicates essentially the last remaining duplicated fields.
|
| |
|
|
| |
This makes the code slightly more generic.
|
| | |
|
| |
|
|
|
| |
Instead of bstr. Most callers of this function do not need bstr. The
bstr version of this function is now mp_path_join_bstr().
|
| |
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
|
|
| |
Because gcc (and clang) is a goddamn PITA and unnecessarily warns if
the universal initializer for structs is used (like mp_image x = {})
and the first member of the struct is also a struct, move the w/h
fields to the top.
|
| | |
|
| |
|
|
|
|
|
| |
They are redundant. They were used by draw_bmp.c only, and only in a
special code path that 1. used fixed image formats, and 2. had image
sized perfectly aligned to chroma boundaries (so computing the chroma
width/height is trivial).
|
| |
|
|
|
| |
Realistically probably no problem at all since they're in ms and usually
start from 0, but whatever.
|
wm4
Marcin Kurczewski