Note that hresult_to_str() (coming from wasapi_explain_err()) is mostly
wasapi-specific, but since HRESULT error codes are unique, it can be
extended for any other use.
This is another attempt at making files with sparse video frames work
better.
The problem is that you generally can't know whether a jump in video
timestamps is just a (very) long video frame, or a timestamp reset. Due
to the existence of files with sparse video frames (new frame only every
few seconds or longer), every heuristic will be arbitrary (in general,
at least).
But we can use the fact that if video is continuous, audio should also
be continuous. Audio discontinuities can be easily detected, and if that
happens, reset some of the playback state.
The way the playback state is reset is rather radical (resets decoders
as well), but it's just better not to cause too much obscure stuff to
happen here. If the A/V sync code were to be rewritten, it should
probably strictly use PTS values (not this strange time_frame/delay
stuff), which would make it much easier to detect such situations and
to react to them.
mp_parse_escape() is used by the JSON parser in json.c, and JSON allows
escaping "/" (solidus).
Although it makes no sense, apparently Javascript traditionally allowed
that as escape sequence for working around issues with embedding
Javascript in HTML. (Or something like this must have been the history
of this issue.) Since it's valid in Javascript, it had to be valid in
JSON as well, and JSON explicitly specifies it as valid escape.
Fixes#2694.
AVComponentDescriptor.offset was introduced relatively recently. On
older releases, you have to use AVComponentDescriptor.offset_plus1,
which is now deprecated.
Instead of adding ifdeffery, assume AV_PIX_FMT_NV21 is the only format
for which this applies (and will remain the only case), which is
probably true enough.
Should take care of the planned FFmpeg AV_PIX_FMT_P010 addition. (This
will eventually be needed when doing HEVC Main 10 decoding with DXVA2
copyback.)
A format could declare that some or all LSBs in a component are padding
bits by setting a non-0 AVComponentDescriptor.shift value. This means we
would interpret it incorrectly, because until now we always assumed all
regular formats have the padding in the MSBs.
Not a single format that does this actually exists, though. But a NV12
variant will be added later in FFmpeg.
Windows definitely supports Unix-style fd inheritance. This mostly
worked when launched from mpv.exe, though mpv should change the file
mode to O_BINARY. When launched from mpv.com, the wrapper must pass the
list of handles (stored in the undocumented lpReserved2 and cbReserved2
fields) to the mpv process.
Commit 3909e4cd ended up losing the ability to tune the gaussian window,
which this commit trivially reintroduces.
The constant scaling factor (present in the code copied from glumpy)
also goes against filter_kernels.c conventions, which is that f(0.0) = 1
(and the invoking code takes care of normalization), and has been
removed.
The values of this new gaussian function corresponds to different
functions when compared against the old version. To translate the old
values p1 to the new values p2 requires solving 2^(e/p1) = e^(2/p2) or
p2 = p1 * 2/(e * ln(2)) ≈ p1 * 1.0615
In other words, to get the old default in the new function requires
setting scale-param1 to 1.0615. (The new function is *slightly* sharper
by default)
(Though most users should probably not notice the change)
To get a uniform license for this file, relicense the mpv parts to BSD
as well.
But leave the door open for a later change to LGPL. (All non-Glumpy code
was written within mpv, and all mpv authors have agreed to LGPL
relicensing.)
Closes#2688.
This file claims to be based on the "MPlayer VA-API patch", but this is
untrue. Only some glue code was copied from hwdec_vaglx.c, and this glue
code was never in MPlayer or the MPlayer VA-API patch in any form, and
instead part of the mpv-original way we do hardware decoding OpenGL
interop. The EGL interop method didn't exist at the time the MPlayer
VA-API patch was created either.
PT_RELOAD_FILE is a somewhat obscure case when using DVB or when
switching Matroska editions. Both cases were broken, because the
asynchronous playback abort mechanism was still triggered. This
mechanism is used to force the demuxer and stream layers to exit
immediately (instead of blocking on I/O possibly forever), and
is normally disabled on playback start. The reopen path is a bit
strange, and needs to reset it manually.
Pointed out in #2568.
If you do "mpv /bla/", and then branch out into sub-directories using
playlist navigation, and then used quit and watch later, then playing
the same directory did not resume from the previous point. This was
because resuming is based on the path hash, so a path prefix can't be
detected when resuming the parent directory.
Solve this by writing each path prefix when playing directories is
involved. (This includes all parent paths, so interestingly, "mpv /"
would also resume in the above example.)
Something like this was requested multiple times, and I want it too.
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
It existed for XP-compatibility only. There was also a time where
ao_wasapi caused issues, but we're relatively confident that ao_wasapi
works better or at least as good as ao_dsound on Windows Vista and
later.
Normally, PulseAudio accepts any combination of sample format, sample
rate, channel count/map. Sometimes it does not. For example, the channel
rate or channel count have fixed maximum values. We should not fail
fatally in such cases, but attempt to fall back to a working format.
We could just send pass an "unset" format to Pulse, but this is not too
attractive. Pulse could use a format which we do not support, and also
doing so much for an obscure corner case is not reasonable. So just pick
a format that is very likely supported.
This still could fail at runtime (the stream could fail instead of going
to the ready state), but this sounds also too complicated. In
particular, it doesn't look like pulse will tell us the cause of the
stream failure. (Or maybe it does - but I didn't find anything.)
Last but not least, our fallback could be less dumb, and e.g. try to fix
only one of samplerate or channel count first to reduce the loss, but
this is also not particularly worthy the effort.
Fixes#2654.
Apparently, the firmware will ignore pixel_x/pixel_y if the numeric
value of them gets too high (even if they indicate square pixel aspect
ratio). Even worse, the destination rectangle is ignored completely,
and the video frame is simply stretched to the screen. I suspect this
is an overflow or weird sanity check within the firmware.
Work it around by limiting the fields to 16000, which is an arbitrary
but apparently working limit.
There are a lot of incorrectly encoded subtitles with .ass extension
and non-ass subtitles (srt, ssa) with such extension, so we need to
try codepage detection even for .ass.
Signed-off-by: wm4 <wm4@nowhere>
