WebVTT subtitles in WebM require special logic, and we signal that using
the "webvtt-webm" codec name, which is not part of FFmpeg. That worked
fine until commit 94859997b8 ("sub: update codec info") added a call
to mp_codec_info_from_av(), which overwrites our codec name with
FFmpeg's the first time the subtitle decoder is initialized. As a
result, WebM WebVTT subtitles are currently not rendered correctly after
switching subtitle tracks. Fix the issue by resetting the codec name
after calling mp_codec_info_from_av().
We originally took the codec name as a separate parameter, making this
talloc_strdup() good hygiene. But since commit 73779a8c70
("sub/lavc_conv: take sd context as a parameter for lavc_conv_create"),
we take the name from the sd context, whose other fields we already
reference. So it should be safe just to copy the pointer like we do in
sub/sd_lavc.c.
We want to add padding around the whole bitmap, not within it. Smaller
parts are rendered onto bigger bitmap. Remove leftover padding code.
Fixes: e2fc75434e
Rendering OSD on every frame draw is quite heavy, even if some of the
rendering parts are cached, it still takes significant amount of time,
depending of payload can take 8-10 ms just to do the text shaping.
Instead render only when we need it.
This is a change in default for libass with harfbuzz enabled, previously
it would choose the best available shaper.
Harfbuzz isn't really needed for mpv's OSD and it comes with a
significant performance penalty, so use simple instead
Some languages actually require strings to be valid UTF-8, unlike C
which couldn't care less as long as it is NULL terminated.
Change triggered by Python support, but is also useful for Rust and Java.
Unknown duration subtitle handling must be executed on every decode
call, because we are actually adjusting the duration value of subtitles
that are decoded in the past. It should not only execute when the
newest packet has an unknown duration.
Added in 56616b0b01. Note that it was
called osd_draw then and not osd_render. Anyways, this line doesn't make
any sense today because vo_gpu_next in fact does not call osd_draw (or
any similar API) after this. Resetting the bool here instead seems to
cause redraws to be missed. For the other handful of VOs that use this,
there is no difference. They all use the mp_draw_sub_overlay call and
the playloop appropriately takes care of the redraw notification value.
Fixes#15963.
Notably they are exchanged between demux and decode thread. It's fine
because we know those pointers will be alive as long as avctx is alive.
And only the value may change during decoding in rare situations. Make
those pointers atomic for the sake of it.
It shouldn't change anything, except some codegen.
From https://www.gnu.org/software/libc/manual/html_node/Atomic-Types.html#Atomic-Types:
In practice, you can assume that int is atomic. You can also assume that
pointer types are atomic; that is very convenient. Both of these
assumptions are true on all of the machines that the GNU C Library
supports and on all POSIX systems we know of.
This update introduces a demux_packet_pool, allowing for the reuse of
previously allocated packets when needed.
sizeof(AVPacket) is not a part of the lavc public ABI, which prevents us
to allocate memory in larger blocks. However, we can substantially
decrease the amount of alloc/free operations during playback by reusing
both mpv's demux_packet and AVPacket.
This adjustment addresses the root cause of issue #12076, which,
although resolved upstream, did not fully tackle the persistent problem
of allocating small blocks of aligned memory. This issue largely stems
from the FFmpeg design of the AVPacket API. After this change memory
will no longer be allocated once cache limits is reached.
The demux_packet_pool is shared as a global pool of packets for a given
MPContext.
This change significantly speeds up the demuxer deinitialization,
benefiting file switching scenarios, especially when a large demuxer
cache is used.
See: #12294
See: #12563
Signed-off-by: Kacper Michajłow <[email protected]>
There's several path-related options that do not handle common shortcuts
(like ~/). Fix this by using mp_get_user_path where appropriate which
expands the path so users get more intuitive behavior. Fixes#15598.
Taken from the last freely licensed version of Symbola and manually
adjusted the number in the glyph file to match the adjacent arrows.
Saving sfdir with fontforge also automatically removed the O flag from 2
existing glyphs. According to
https://fontforge.org/docs/techref/sfdformat.html "O" just meant "the
character was open when last saved", so it doesn't change anything
visible.
By default OSD and subs have no shadow, but if you do set a
--osd/sub-shadow-offset, the current default white shadow color looks
bad around white text with black border. Default to semitransparent
black instead. Use the same color box profiles were using to allow
removing it from there.
Previous fixes in bcc3d72 make subtitles on videos with non-square pixel
aspect ratios appear incorrect. This can happen on subtitles for SD
Blu-rays where the video resolution is 720x480 but the aspect ratio is
4:3. The scaling still applies when the video frame is cropped with
filters so the previous fix will still work.
Fixes#15415.
The current OSD font size is excessively large, causing most
messages—except for very short ones to overflow horizontally.
I conducted testing across multiple devices of varying screen sizes and
under different scenarios. The adjusted font size strikes a good balance
for readability on non-high-DPI displays, while high-DPI displays should
utilize DPI scaling as needed.
Additionally, I compared the font sizes of subtitles and UI elements
across various VOD platforms, which generally use smaller font in most
cases.
The current sub font size was significantly larger than even PGS
subtitles, which are quite large on their own. Now, they are comparable.
The subtitle font size was chosen based on recommendations from the BBC
Subtitle Guidelines. It is set to 8% of the video height with a
recommended scaling factor of 0.67. Therefore, at 720p (the reference
size for mpv font scaling), the calculation is 8% * 0.67 * 720 = 38.592,
rounded down to 38. This value falls within the recommended scaling
range of x0.5–x1 for desktop PCs/Laptops and TVs (32"–42"). For more
information, see
https://www.bbc.co.uk/accessibility/forproducts/guides/subtitles/#Presentation-font-size.
OSD font size is smaller than font as those elements shouldn't be
distractful and only noticable when the user wants to look at them.
Outline size is set to 5.5% of font size.
High --osd-blur values break the osd-bar by not drawing the filled
portion, and even low values just make it look worse, so don't apply
--osd-blur to the osd-bar.
This adds --osd-bar-marker-style option which can be used to
customize OSD bar marker style. In addition to the existing triangle
style, a new style option is added to draw markers as lines.
If show-text ${playlist} is used with --osd-scale-by-window=no while
printing to the terminal or while mpv is starting, the out_screen_h
assignment in osd_get_text_size() causes runtime error: signed integer
overflow: 288 - -2147483648 cannot be represented in type 'int'. Fix
this by not making prepare_osd_ass() use an infinite playresy.
This prevents printing show-text ${playlist} without a line limit to the
terminal with --osd-scale-by-window=no, which makes only the last
playlist entries be printed, and the selected one is not printed if it
isn't among them. A later commit will make the line calculation
accurate.
A packet with an unknown duration flagged the entire context and then
this was saved forever throughout the entire lifetime of the object.
This inherently doesn't work with the redecoding sub logic which will go
through all the packets again. So the second time around, packets with
known durations get treated as if they were unknown and things go awry.
Rework this so it is per packet like it should be and not a global
state. Note that f9cefbfec4 originally
added this for specifically eia-608 subtitles but their packets are all
detected as unknown anyway due to the durations so this is not needed
anymore and interferes with other things.
Thomas Hebb