| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Since some users apparently can't figure this out.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
All authors have agreed, with the following exceptions:
e68d7f6858: wight wasn't asked (I think...), but even if he modified the
patch he applied, all code added by it was removed again later.
cb7768f9bb: nick could not be reached, but the declarations he added as
well as the full timer.c file were deleted again in cff81fe498 and
f800a42e45 (did it really take 6 years to remove unused declarations?).
ffaf4af230: it looks like this person wasn't contacted, but the code
added was removed again in f544bcf105.
|
| |
|
|
|
|
|
| |
This comes with estimated level of difficulty. Files which were already
LGPL are listed too, to avoid potential confusion.
Some entries use shell wildcards.
|
| |
|
|
|
|
|
|
| |
All authors have agreed.
Commit 94d3170bd05 is a bit murky: Nick could not be reached, and arpi's
changes were obviously inspired or copied from Nick's. However, the
changed symbols were removed and do not exist anymore.
|
| |
|
|
|
|
|
| |
Although pretty similar to the probably unrelicensable
video/fmt-conversion.c/h (basically using the same idea, but for audio),
it was written by someone else. The format mapping was first added in
commit ad95e046c2451.
|
| |
|
|
|
| |
All authors agreed. Some of the code originated from commit
3c49701490aecb by michael, thus the license change has to be delayed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
msg.c is "partial" due to "michael", whose work can be changed to LGPL
only once the core is LGPL. It's explained in the Copyright file. I
prefer to do the relicensing incrementally (due to the overwhelming
workload). Changing the license before that happens would be legally
questionable, but nothing can stop us from essentially marking it as
"will be LGPL".
All authors have agreed to LGPL, with the following exceptions:
9df11ee8bf: the author (probably) didn't agree, but the line that is
added is later fully removed.
35e90f1556: was not asked, but all iconv code was 100% removed from the
mp_msg mechanism (we alwas require UTF-8 now).
4e4f3f806e: the change by michael.
50a86fcc34: the identify variable was move, and completely removed the
latest in commit 48bd03dd91232.
1f6c494641: did not agree, but due to a major mp_msg change the added
line became unnecessary and was removed.
da63498bf9: was not reachable, but the MPlayer GUI is gone from mpv
anyway (also commit fc4d6e617d8d removed these specific additions a long
time ago).
|
| |
|
|
|
|
| |
I guess there is a hard to balance tradeoff between appearing rude or
dismissive, and making the user think it's ok to not provide essential
information.
|
| |
|
|
|
|
|
|
| |
The author of the old code disagreed with LGPL. The new code is a clean
room reimplementation by Niklas Haas. It lacks the clamping, but we
decided it doesn't matter.
Untested, bugs can be fixed later anyway.
|
| |
|
|
| |
See FFmpeg commit c0f17a905f3588bf61ba6d86a83c6835d431ed3d.
|
| |
|
|
|
| |
It doesn't even use OpenGL header anymore. What it needs are EGL and GLX
libs/header and similar.
|
| |
|
|
| |
Seems much more resource efficient than concatenating a string.
|
| | |
|
| |
|
|
|
| |
Regression since 8996f79edbf.
Closes #4398
|
| |
|
|
| |
Apparently it has been broken since forever?
|
| |
|
|
|
|
|
|
| |
Until now, the texture pointer was stored in plane 1, and the texture
array index was in plane 2. Move this down to plane 0 and plane 1. This
is to align it to the new WIP D3D11 decoding API in Libav, where we
decided that there is no reason to avoid setting plane 0, and that it
would be less weird to start at plane 0.
|
| |
|
|
|
|
|
|
| |
Sigh...
The functionality is not actually needed for vdpau, but if the vdpau
hwaccel is present, the FFmpeg version is new enough that it includes
the field.
|
| |
|
|
| |
Fixes the issue pointed out in #4394.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
These decoders can select the decoding device with hw_device_ctx, but
don't use hw_frames_ctx (at least not in a meaningful way).
Currently unused, but intended to be used for cuvid, as soon as it hits
ffmpeg git master.
Also make the vdpau and vaapi hwaccel definition structs static, as we
have removed the old code which would have had clashing external
declarations.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update man page for fonts.conf and subfont.ttf. These are two
undocumented features in mpv. They were only hardcoded into sub/ass_mp.c
and could not be found anywhere else in the entire codebase. Git log
reveals that fonts.conf was added in 2013 while subfont.ttf was brought
in by a ancient patch of mplayer in 2002...
These are two quite useful undocumented features when you do not want to
mess up with global fonts.conf to include more fonts.
Also document ~/.config/mpv/fonts/ directory and suggest using fonts.conf
to include additional fonts.
mpv reads all files in ~/.config/mpv/fonts/ directory into memory. If
there are a lot of fonts in that directory, mpv would use a lot of
memory. Using ~/.config/mpv/fonts.conf to include additional fonts is
more memory-efficent.
|
| |
|
|
|
|
|
|
| |
This reverts commit 142b2f23d4293, and replaces it with another try. The
previous attempt removed the overlay on every rendering, because the
normal rendering path actually unrefs the mp_image. Consequently,
unmap_current_image() was completely inappropriate for removing the
overlay.
|
| |
|
|
|
|
|
|
| |
If the default shell of the user is set to csh or tcsh, the use of
"$SHELL -l -c" will fail to launch mpv because -l and -c cannot be used
together with csh or tcsh.
Signed-off-by: Akemi <der.richter@gmx.de>
|
| |
|
|
|
|
|
| |
Tries to access the options, which are obviously not allocated if there
is no DVD support compiled.
Fixes #4393.
|
| |
|
|
| |
It's a simple memory leak. (The API objects were destroyed anyway.)
|
| |
|
|
|
| |
This should make vo_opengl_cb uninit remove the frame, even if the
renderer and OpenGL state remains active.
|
| |
|
|
| |
sdh filter returns NULL when subtitle line should be skipped
|
| |
|
|
| |
The entire af code is going to be removed, but Ordnung muss sein.
|
| |
|
|
|
| |
This is probably better than separate options. For example, the user
does not have to guess which one is applied if both options are enabled.
|
| |
|
|
|
|
|
|
| |
The new replaygain code accidentally applied the linear gain as cubic
volume level. Fix this by moving the computation of the volume scale out
of the af_volume filter.
(Still haven't verified whether the replaygain code works correctly.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
af_volume is deprecated, and so are its replaygain sub-options. To make
it possible to use replaygain without deprecated options (and of course
to make it available at all after af_volume is dropped), reintroduce
them as top-level options.
This also means that they are easily changeable at runtime by using them
as properties. Change the "volume" property to use the new update
mechanism as well.
We don't actually bother sharing the implementation between new and
deprecated mechanisms, as the deprecated one will simply be deleted.
For the from_dB() functions, we mention anders' copyright, although I'm
not sure if a mere formula is copyrightable. This will have to be
determined later.
This whole change is mostly untested. Our distributed human CI will take
care of it.
|
| |
|
|
|
| |
Could be broken after the previous commit removed finding the GL include
dir.
|
| |
|
|
|
|
| |
We don't need to link against libGL directly, nor do we need OpenGL
headers. The only thing we need is the windowing interop stuff, such as
libEGL.
|
| |
|
|
| |
Pointed out by someone.
|
| |
|
|
|
| |
Since mpv ships all the required OpenGL defines now,
rpi check doesn't need to check system GL headers.
|
| |
|
|
|
|
|
|
|
| |
Close the audio device if there is no audio track (or stream) in the
current file. It will be opened again if the next file should contain
audio.
Signed-off-by: Marko Hauptvogel <marko.hauptvogel@googlemail.com>
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
|
| |
Considered semantically equivalent with mouse_btn3/4.
This is a preemptive fix for upcoming changes to AXIS_* events.
|
| | |
|
| | |
|
| |
|
|
|
| |
Probably helps with #4311. It surely is not the correct fix, of course.
But ao_openal has no business of causing trouble anyway.
|
| |
|
|
|
|
|
|
|
|
| |
This drops support for the old libavcodec APIs. Now FFmpeg 3.3 or FFmpeg
git is required. Libav has no release with the new APIs yet, so for
Libav git as of a few weeks or months ago or so is required if you want
to use Libav.
Not much actually changes in hwdec_vaegl.c - some code is removed, but
the reindentation inflates the diff.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Also update release policy documentation and version extraction.
|
| | |
|
| |
|
|
|
|
|
| |
All controbutors have agreed. In one case, someone who is unaccounted
for changed a glyph in some trivial way; we simply replaced the glyph
with another one in 1e4d3a2440e94 to avoid any potential problems
(although that change was probably not copyrightable anyway).
|
| |
|
|
|
|
|
| |
All contributors have agreed. In 3a43f13fcec1, someone who potentially
disagreed reverted a commit by someone else (restoring the original
state). This shouldn't matter for Copyright, and all of the affected
code was rewritten/removed anyway.
|
| |
|
|
|
| |
These are covered by the analysis in commit e7e6aa3d64d8773 too
(although there are no potential problems).
|
| | |
|
| |
|
|
|
|
| |
It's been missing since mplayer2 times, not sure why. It originates from
subreader.c. No analysis on whether it can be relicensed to LGPL was
done yet.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most contributors have agreed. This claims it's based on gstreamer code,
but this was LGPL at the time (and still is). Contributors whose code
was removed were not accounted for. There are still some potentially
problematic cases:
06eee1b67 is potentially the most problematic case. Most of these
changes are gone due to mpv not using BITMAPINFOHEADER anymore. Some
of the other changes are rather trivial. If someone contests this and
claims that copyrightable changes are left, the original change can
simply be reverted.
62bfae140 has only 2 lines left: a "char *name;" struct field, and a
line that prints a message. All other code was removed. The parsing code
in particular was made declarative, which replaced reading this element
explicitly (and other elements, see 1b22101c77e). I'm putting the log
message under HAVE_GPL, but I don't think the declaration is
copyrightable, or the mere concept of reading this element. Redoing the
other 2 lines of code would result in the same program text.
d41e860ba was applied by someone who (potentially) disagreed. The patch
itself is from someone who did agree, though. It's unknown whether the
applier changed the patch. But it seems unlikely, and the change was
mostly rewritten.
50a86fcc3 all demux_mkv changes were reverted (old stdout slave mode)
3a406e94d same
2e40bfa13 the old MPlayer subtitle code was completely removed
316bb1d44 completely removed in 1cf4802c1d
87f93d9d7 same
11bfc6780 relative seeks were removed in 92ba630796
be54f4813 the corresponding demux_mkv code was removed in 5dabaaf093
efd53eed6 all internal vobsub handling is now in FFmpeg
d7f693a20 removed in f3db4b0b937
e8a1b3713 removed in 522ee6b7831
cfb890259 removed, see 6b1374b203 for analysis
c80808b5a same
|
| |
|
|
|
|
|
|
|
|
|
| |
The only definitions from MPlayer code are the CONTROL_* defines (added
in 7a2eec4b as part of libao2 - not part of libao), and MP_NOPTS_VALUE,
which was added in e6338c58. The latter is by "michael", who has agreed
under the condition that the core is LGPL, which has not happened yet,
but considering the macro definition used to be different, has the same
value and similar name to libavformat's AV_NOPTS_VALUE (which existed
first, and as LGPL), and that this almost certainly not copyrightable,
I'm assuming that this is fine.
|
| |
|
|
|
|
|
| |
Reduces the ifdeffery, which is good and will avoid silent breakages, or
weird behavior if a lib is omitted.
Also reorder the x11_common.c include statements.
|
| |
|
|
|
| |
Specifically, this field must never be 0 (and the option can naturally
not be 0 in any way, unless it wasn't initialized correctly).
|
| |
|
|
|
| |
Uses python scripting on fontforge since native scripting is considered
legacy and even Ubuntu Trusty seems to have python scripting.
|
| |
|
|
|
| |
The triangle icon has potentially questionable copyright issues, see
https://github.com/mpv-player/mpv/commit/a7e9bac13210834abd95380e89b5c3dae2336c52
|
| |
|
|
|
|
|
| |
Should make changes easier to inspect.
This was created by opening the current osd_font.otf in Fontforge and
saving as .sfdir.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All contributors of the code used for these files agreed to the LGPL
relicensing.
There are some unaccounted contributors, but all of their code was
completely removed before. (The only exception is one contributor whose
only line left was "#include <string.h>". I don't know if that's
copyrightable, but it wasn't needed anyway, so just remove it.)
These files started out as libvo/sub.* (renamed to sub/sub.*, then
renamed again to sub/osd.*). They used to contain code for rendering
the OSD (as in, actual pixel manipulation and text layouting). But
later all this code was dropped, and libass was used to render the OSD
instead. Actual subtitle rendering was reimplemented in other files
(the old subtitle rendering path is completely gone).
One potential problem are the option declarations, which makes this
harder, as these options involve more history. But it turns out most of
them were reimplemented since 80270218cb9, rather than taken from old
code. (Although not all - but the rest covered by relicensing
agreements.)
This also affects osd_state.h, which was apparently incorrectly implied
to be LGPL.
|
| |
|
|
|
|
|
|
|
|
| |
All contributors have agreed.
Compared to sd_ass.c, this has a pretty simple history:
av_sub.c -> sub/av_sub.c -> sub/sd_lavc.c
At one point, some code from spudec.c was added to it, but it was
removed again later.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All contributors of the code used for sd_ass.c agreed to the LGPL
relicensing. Some code has a very chaotic history, due to MPlayer
subtitle handling being awful, chaotic, and having been refactored a
dozen of times. Most of the subtitle code was actually rewritten from
scratch (a few times), and the initial sd_ass.c was pretty tiny. So we
should be fine, but it's still a good idea to look at this closely.
Potentially problematic cases of old code leaking into sd_ass.c are
mentioned below.
Some code originates from demux_mkv. Most of this was added by eugeni,
and later moved into mplayer.c or mpcommon.c. The old demux_mkv ASS/SSA
subtitle code is somewhat dangerous from a legal perspective, because it
involves 2 patches by a certain Tristan/z80, who disagreed with LGPL,
and who told us to "rewrite" parts we need. These patches were for
converting the ASS packet data to the old MPlayer text subtitle data
structures. None of that survived in the current code base.
Moving the subtitle handling out of demux_mkv happened in the following
commits: bdb6a07d2a712c, de73d4dd978cb2, 61e4a801913f76. The code by
z80 was removed in b44202b69fc4a1.
At this time, the z80 code was located in mplayer.c and subreader.c.
The code was fully removed, being unnecessary due to the entire old
subtitle rendering code being removed. This adds a ass_to_plaintext(),
function, which replaces the old ASS tag stripping code in
sub_add_text(), which was based on the z80 code. The new function was
intended to strip ASS tags in a correct way, instead of somehow
dealing with other subtitle types (like HTML-style SRT tags), so it
was written from scratch.
Another potential issue is the --sub-fix-timing option is based on
-overlapsub added in d459e644632cb9b. But the implementation is new, and
no code from that commit is used in sd_ass.c. The new implementation
started out in 64b1374a4456435. (The following commit, bd45eb468ced22
removes the original code that was replaced.) The code was later
moved into sd_ass.c.
The --sub-fps option has a similar history.
|
| |
|
|
|
|
|
| |
Somewhat chaostic history: libass/ass_mp.* -> ass_mp.* -> sub/ass_mp.*
As far as I can tell, everyone who ever touched these files has agreed
to the relicensing.
|
| |
|
|
|
| |
This change was requested during patch review, but apparently it was
overlooked on merge.
|
| | |
|
| |
|
|
|
| |
%ls is C99. %S is supported by some systems, including MinGW/MSVC, but
no reason to use it.
|
| |
|
|
|
|
|
| |
IMMDeviceEnumerator_RegisterEndpointNotificationCallback() will start
listening for notifications, and is the point at which callbacks can
start firing. These callbacks will read the fields we set after the
register calls, which is a potential race condition. Move it upwards.
|
| |
|
|
|
| |
(Of course this is on by default, because otherwise we'd randomly break
downstream applications.)
|
| |
|
|
|
| |
There have been user complaints, and I'm annoyed by this behavior
myself.
|
| |
|
|
|
| |
The default of 80 is conservative to allow relatively wide fonts, but
with many common fonts a bigger number can be used without overflow.
|
| | |
|
| |
|
|
|
| |
Glyphs taken and based on U+1F507 to U+1F50A from Symbola, which
is available under public domain: http://users.teilar.gr/~g1951d/
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Click to toggle mute, mouse wheel to change volume.
OSD is shown on volume change.
|
| | |
|
| |
|
|
| |
Use a helper function for these safety checks.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
There is explicit code to handle the libmpv case, but it expects that
a dispatch queue is running. This is not necessarily the case. E.g.
edit the simple.c mpv example not to do any playback and to destroy
the mpv handle immediately. It will freeze on exit, because nothing
will release the mpv_handle.
I'm not sure how this should be fixed, so disable it for now in
library mode.
|
| |
|
|
| |
At least this doesn't duplicate the libavcodec PCM codec names.
|
| |
|
|
|
| |
I think these became redundant some time ago, and would only matter if
someone put QT tags into WAVEFORMATEX headers using mkv avi muxing.
|
| |
|
|
|
|
|
|
| |
When the format of the subtitle bitmaps changes, such as with taking
screenshots with vo_vaapi (RGBA for the VO vs. Y8 for screenshots), the
cache image obviously needs to be recreated.
Fixes #4325.
|
| |
|
|
|
|
|
|
|
|
|
| |
due to the System inherent fullscreen animation the option and the
actual fullscreen state can be out of sync, leading to a wrongly
reported unfs window size in the time of the animation.
just always fall back to the window size, we keep track of, when we
either are in fullscreen or are currently switching to it.
Fixes #4323
|
| |
|
|
|
|
|
|
| |
Wayland is still too amateurish, and multiple features don't work,
including critical ones. There is no solution in sight, so prefer X11.
(Which seems to mostly work ok via xwayland.)
Once all problems are solved, the defaults can be switched back.
|
| |
|
|
|
|
|
|
|
|
| |
When doing harder filtering not require a space after : results
in lines with a clock (like 10:05) to be taken as a speaker label.
So require a space after : even when doing harder filtering as
missing space is very uncommon.
Some like to add text in parentheses in the speaker label,
like XXX (loud): or just (loud):
allow parentheses when doing harder filtering
|
| |
|
|
|
|
|
|
|
|
| |
The license text refers a "above copyright notice", so I guess it'd be
good to actually provide such a notice.
Add the license to some files that were missing it (since in theory, our
Copyright file says that such files are LGPL by default).
Remove the questionable remarks about the license in the client API.
|
| |
|
|
|
|
|
| |
It's all explained in the DOCS changes. Although this option was always
kind of obscure and pointless. Until it is removed, the only reason for
setting it would be to raise the static default limit, so change its
default to INT_MAX so that it does nothing by default.
|
| |
|
|
|
|
|
|
|
| |
The previous commit set "mpctx->playback_active = false;" before unload
hooks were processed. This was intentional, but could in theory cause
playback_active to be set to true again, and actually it's plain wrong
if playback was exited in the middle it. There needs to be something
else that forces playback_active to be set to false while in this
unloading state.
|
| |
|
|
|
|
|
|
| |
Make mpv_observe_property() work correctly on them even with
--keep-open-pause=no.
This also changes the situations in which the screensaver is
enabled/disabled subtly.
|
| |
|
|
|
|
|
|
|
| |
Merge the pause_player() and unpause_player() functions. Make sure the
pause events are emitted properly. We can now set the internal pause
state based on a predicate, instead of e.g. handle_pause_on_low_cache()
making a mess to trigger the internal pause state as wanted.
Preparation for some more changes.
|
| |
|
|
|
|
|
|
|
|
|
| |
Instead of pausing if --keep-open is active, stop
at end but continue playing if seeking backwards.
And then stop again when end is reached.
Signed-off-by: wm4 <wm4@nowhere>
Over the PR, the option was renamed, and the manpage additions were
slightly changed/enhanced.
|
| | |
|
| |
|
|
| |
Might fix #4315.
|
| |
|
|
| |
_wgetcwd is apparently not available in all runtimes. Well, whatever.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Un-special-case the sub-speed property, and apply subtitle speed updates
in more cases. In particular, this respects runtime changes of the
sub-fps option.
(A minor consequence of this is that the subtitle speed is recomputed
more often even in cases when it's not necessary. Also, the subtitle
update is slightly "delayed" rather than strictly instant. Both of
these likely are absolutely not observable by the user, although the
subtitle speed verbose log message will be printed more often if the
subtitle format is MicroDVD.)
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Also "announce" the plans to undeprecate it with changed semantics
later. The deprecation period is needed to warn script authors and
client API users (etc.) of the change.
This is done because everyone seems to expect --loop to loop the current
file, not the playlist. Even in cases when only 1 file is on the
playlist, the --loop-file semantics seem to be preferred.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Mostly because of ANGLE (sadly).
The implementation became unpleasantly big, but at least it's relatively
self-contained.
I'm not sure to what degree shaders from different drivers are
compatible as in whether a driver would randomly misbehave if it's fed
a binary created by another driver. The useless binayFormat parameter
won't help it, as they can probably easily clash. As usual, OpenGL is
pretty shit here.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
- libfaac and libvo_aacenc were removed from FFmpeg
- add libopus profile
- modify vp8's ovcopts and add vp9
- switch enc-f-webm to vp9 + opus
- remove obsolete devices profiles using deprecated filters
|
| |
|
|
|
|
|
|
| |
This just checks if dvdread or dvdnav are enabled so it can
compile dvdread code.
Change description to be clearer on what this does differently from
--enable-dvdread.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gl_headers.h is basically header_fixes.h done consequently. It contains
all OpenGL defines (and some typedefs) we need. We don't include GL
headers provided by the system anymore.
Some care has to be taken by certain windowing APIs including all of
gl.h anyway. Then the definitions could clash. Fortunately, redefining
preprocessor symbols to the same content is allowed and ignored. Also,
redefining typedefs to the same thing is allowed in C11. Apparently the
latter is not allowed in C99, so there is an imperfect attempt to avoid
the typedefs if required API symbols are apparently present already.
The nost risky part about this are the standard typedefs and GLAPIENTRY.
The latter is different only on win32 (and at least consistently so).
The typedefs are mostly based on stdint.h typedefs, which khrplatform.h
clumsily emulates on platforms which don't have it. The biggest
difference is that we define GLsizeiptr directly to ptrdiff_t, instead
of checking for the _WIN64 symbol and defining it to long or long long.
This also typedefs GLsync to __GLsync, just like the khronos headers.
Although symbols prefixed with __ are implementation reserved, khronos
also violates this rule, and having the same definition as khronos will
avoid problems on duplicate definitions.
We can simplify the build scripts too. The ios-gl check seems a bit
wrong now (what we really want to test for is EAGLContext), but I can't
test and thus can't improve it.
cuda_dynamic.h redefined two GL symbols; just include the new headers
directly instead.
|
| |
|
|
|
| |
Instead, enable the "old" code, which uses this for gapless info (audio
padding/trailing) only.
|
| |
|
|
|
| |
Pointed out by uau. Not sure why gcc doesn't warn (it uses ((void*)0)
for NULL).
|
| |
|
|
|
|
|
| |
This is pretty trivial, but also quite annoying due to details like
mismatching eglGetProcAddress() function signature (most callers just
cast the function pointer), and ARM/Linux hacks. So move them all to one
place.
|
| |
|
|
|
|
|
|
|
| |
With the recent GLES3 header detection, and if ANGLE is in the search
path, the ANGLE headers will be used over the desktop GL ones. It
appears the ANGLE headers do not include <windows.h>, which leads to the
dxinterop code to fail building. Oops.
Fix this by including <windows.h> is dxinterop is compiled in.
|
| |
|
|
|
| |
Avoid it where we can, because it tends to have unexpected side-effects.
(Probably not in this case, but still a reason to avoid it.)
|
| |
|
|
|
|
|
|
| |
It appears we expect IOS to provide GLES 3. The IOS block contains all
symbols from the GLES block. Weirdly not all, so it's possible that some
symbols will be redefined, which is annoying, but harmless. I don't have
an iOS setup to test, otherwise it's likely that a modification of the
IOS include statements would take care of this.
|
| |
|
|
|
| |
There's no reason to make it Android specific, as it uses standard
include paths.
|
| |
|
|
|
| |
Looks like Libav is going to drop it, unnecessarily making compilation
fail.
|
| |
|
|
|
|
| |
This hasn't been updated for a while. Some options are deprecated
(--softvol), semi-deprecated or virtually useless (e.g. --vo and --ao),
or use old-syntax (--sub-codepage).
|
| |
|
|
|
| |
This will make --list-options (and some other code paths) actually
return the proper default. Shouldn't change behavior.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the VO doesn't support a format output by vf_lavfi, no conversion
filter was inserted, and filter chain creation failed.
This is because vf_lavfi doesn't properly follow the format negotiation
model, which means the format negotiation pass does not catch all cases
where conversion is needed. Specifically, vf_lavfi supports that all
output formats are supported for any given input format, but then does
not actually call vf_next_query_format() in reconfig() to check which
format it uses, but outputs whatever it gets from libavfilter.
I think this is ok to avoid excessive complexity in vf_lavfi.c, but it
also means adding more kludges to vf.c. I justify this (and the code
duplication) with the idea that the current filter chain code will die
anyway at some point.
The .log field additions for c->first/c->last are strictly speaking not
needed, but useful for debugging.
|
| | |
|
| |
|
|
|
| |
And also future directions. Basically, it tells the user that he
can't hope for perfect forward-compatibility.
|
| |
|
|
|
| |
Well, ok, only 4 filters. The rest will survive in one or the other
form.
|
| |
|
|
|
|
| |
Literally copy-pasted from the same commit for video filters. (Once new
code for filters is implemented, this will all go away or at least get
unified anyway.)
|
| |
|
|
|
|
|
| |
This was supposed to restrict output to formats supported by us. But we
usually support all FFmpeg sample formats anyway (if not, it will error
out gracefully, and we would add the missing format). Basically, it's
just useless bloat.
|
| |
|
|
| |
Might make porting to batshit environments simpler.
|
| |
|
|
|
|
|
| |
Previously, the shared behaviour for each mouse-button message lived at
the bottom of the WndProc. Move it into handle_mouse_down/up functions
(similar to the handle_key_down/up functions.) This makes the WndProc
slightly less complicated. There should be no change in behaviour.
|
| |
|
|
|
|
| |
Regression due to 03fe506. It accidentally changed the default value if
glGetTexLevelParameteriv() is not available, which is the case with
ANGLE.
|
| |
|
|
|
|
| |
Now e.g. --vf=pad=1000:1000 works.
All in all pretty ugly and hacky. Just look away.
|
| |
|
|
|
|
| |
when building with a deployment target older than an SDK with Touch Bar
support we still tried to access the TouchBar, since the compile time
checks are positive. to prevent this we add two runtime checks.
|
| |
|
|
|
|
|
|
|
|
| |
Now you can for example do "--vf=hue=h=60" - there is no "hue" filter in
mpv, so libavfilter's will be used.
This has certain caveats (see manpage).
The point of this is providing a relatively smooth transition path to
removing our own filter stuff.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The plan is to nuke the custom filter chain completely. It's not clear
what will happen to the still needed builtin filters (mostly hardware
deinterlacing and vf_vapoursynth). Most likely we'll replace them with
different filter chain concept (whose main purpose will be providing
builtin things and bridging to libavfilter).
The undocumented "warn" options are there to disable deprecation
warnings when the player inserts filter automatically.
The same will be done to audio filters, at a later point.
|
| |
|
|
| |
Not sure why it was a warning in the first place.
|
| |
|
|
|
|
|
|
|
|
|
| |
Now taking a screenshot actually works, if libjpeg is disabled at
compile time.
In particular, the AV_PIX_FMT_YUVJ formats (with the "J") cause us
problems. They have been deprecated years ago, but the libavcodec jpg
encoder won't accept anything else. This is made worse by the fact that
mpv doesn't have J formats internally - it always uses the color levels
metadata to decide the range instead.
|
| |
|
|
|
| |
The APIs that run commands in a more API-like manner disable OSD and
string expansion by default.
|
| | |
|
| |
|
|
| |
Remove the weird custom thing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
And also change input.conf to make all screenshots async. (Except the
every-frame mode, which always uses synchronous mode and ignores the
flag.) By default, the "screenshot" command is still asynchronous,
because scripts etc. might depend on this behavior.
This is only partially async. The code for determining the filename is
still always run synchronously. Only encoding the screenshot and writing
it to disk is asynchronous. We explicitly document the exact behavior as
undefined, so it can be changed any time.
Some of this is a bit messy, because I wanted to avoid duplicating the
message display code between sync and async mode. In async mode, this is
called from a worker thread, which is not safe because showing a message
accesses the thread-unsafe OSD code. So the core has to be locked during
this, which implies accessing the core and all that. So the code has
weird locking calls, and we need to do core destruction in a more
"controlled" manner (thus the outstanding_async field).
(What I'd really want would be the OSD simply showing log messages
instead.)
This is pretty untested, so expect bugs.
Fixes #4250.
|
| |
|
|
| |
Some array functions call memmove().
|
| |
|
|
|
|
|
|
|
|
|
| |
Obviously, this has no effect on commands which do not support this
explicitly. A later commit will enable this for screenshots.
Also add some wording on mpv_command_async(), which has nothing to do
with this. Having a more elegant, unified behavior would be nice. But
the API function was not created for this - it's merely for running
commands _synchronously_ on the core, but without blocking the client
API caller (if the API user consistently uses only async functions).
|
| |
|
|
| |
To be used by the following commits.
|
| |
|
|
|
|
|
|
|
|
| |
This wasn't enabled if no stream cache was used. It can work with only
the demuxer cache.
In theory this could be always enabled (even for local files), but still
try to avoid this, and enable it only if the source is marked as
potentially being a "network" stream. The intention is mostly to enable
it for the youtube-dl pseudo-DASH support.
|
| |
|
|
| |
Closes #3264
|
| |
|
|
|
|
| |
The 'sub' and 'audio' configuration subdirectories are supposed to
be fallbacks for sub-paths and audio-file-paths respectively, but
they weren't being scanned even if they existed.
|
| |
|
|
|
|
|
| |
The old code called reinit_window_state() from the VO thread, which is
not safe. Instead of calling reinit_window_state() when
VO_EVENT_FULLSCREEN_STATE is captured, it should be called when sending
the event from the Win32 thread instead.
|
| |
|
|
|
|
| |
README.md: fix linebreaks
It's only a README, but the 80 columns limit should be followed.
|
| |
|
|
| |
Didn't know waf actually tried to compile the same files twice.
|
| |
|
|
|
|
|
|
|
| |
Reallows enabling dvdnav without enabling dvdread which was broken
in 77cbb3543 when they were both disabled by default.
Since dvdnav requires dvdread, we can enable dvdread:// even if
--enable-dvdread isn't passed.
Fixes #4290
|
| |
|
|
|
|
|
|
|
|
| |
This is a bit approximate, because we rely on the pixel format changing
if the hardware decoding changes. This is not always true, as the pixel
format for software decoded video and hardware decoded video copied back
to CPU RAM could be the same. (Not sure if that is actually the case for
any supported cases.)
But for now this should fix most of #4289.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This tried to use AF_FORMAT_DOUBLE as KSDATAFORMAT_SUBTYPE_IEEE_FLOAT,
with wBitsPerSample==64. This is probably not allowed, and drivers
appear to react inconsistently to it. (With one user, the format was
accepted during format negotiation, but then rejected on actual init.)
Remove it, which essentially forces it to fall back to some other
format. (Looks like it'll use af_select_best_samplerate(), which would
probably make it try S32 next.)
The af_fmt_from_planar() is so that we don't have to care about
AF_FORMAT_FLOATP. Wasapi always requires packed data anyway.
This should actually handle other potentially unknown sample formats
better.
This changes that set_waveformat() always set the exact format. Now it
might set a "close" format instead. But all callers seem to deal with
this well. Although in theory, callers should probably handle the
fallback. The next cleanup (if ever) can take care of this.
|
| |
|
|
| |
Same as stream_bluray, but only if no title is selected already.
|
| |
|
|
|
| |
Probably a typo in 5e30e7a04.
Fixes #4283
|
| | |
|
| | |
|
| |
|
|
| |
This reverts commit 6573b73462e336da0daca845ba4df02782afc2b6.
|
| |
|
|
|
|
| |
a small logic error in 063ca8f broke the filtering of the menu bar item
key shortcuts. they where called several times per event because the
propagation wasn't stopped properly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
there are two minor bugs. mpv could try to retrieve the size when in
fullscreen and would get the fullscreen size. to fix that we keep track
of the window size before going into fullscreen.
the second small bug is when using HiDPI resolution and the
--hidpi-window-scale option. we actually want the OSD to show the proper
window scale depending on the hidpi settings. before when resizing the
window to double the size it could show "window-scale: 1.0" or
"window-scale: 0.5" when resizing to normal size. now it considers the
backing scale factor and the hidpi option to return a logical correct
window size.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
this fixes a weird behaviour when a borderless window's style mask is
set to a none-borderless style mask. this can happen when cycling the
border or just toggling fullscreen. what happens is that the first
responder is reset to the NSWindow instead of being kept, the events
view in our case. this happens without the usual resignFirstResponder,
becomeFirstResponder routine.
this is a small workaround that overrides the setStyleMask method. it
keeps the first responder from before the style mask change and resets
this first responder after the new style mask was applied.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
for a reason i can just assume some key events can vanish from the
event chain and mpv seems unresponsive.
after quite some testing i could confirm that the events are present at
the first entry point of the event chain, the sendEvent method of the
Application, and that they vanish at a point afterwards. now we use
that entry point to grab keyDown and keyUp events. we also stop
propagating those key events to prevent the no key input' error sound.
if we ever need the key events somewhere down the event chain we need
to start propagating them again. though this is not necessary currently.
|
| | |
|
| | |
|
| |
|
|
| |
Close #4221
|
| |
|
|
| |
It seems we generally skip the space, such as seen on the AO init line.
|
| |
|
|
|
|
| |
In print_stream print additional stream info for audio
and video track. While it may be incorrect it is mostly
correct and good info to have.
|
| |
|
|
|
|
|
|
|
|
|
| |
"@name:!" becomes simply "@name". This is actually slightly more complex
to parse, but makes for a much simpler syntax and will be less weird to
the user. Suggested by haasn.
The old syntax is now rejected with an error.
Also add some more explicit error checks, instead of e.g. allowing empty
filter names and erroring only when it's not found.
|
| |
|
|
|
|
|
|
| |
DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL might be buggy on some hardware.
Additionaly DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL might be supported on some
Windows 7 systems with the platform update, but it might have poor
performance. In these cases, the user might want to disable the use of
DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL swap chains with --angle-flip=no.
|
| |
|
|
|
|
|
| |
It should default to true, but setting the filter list via mpv_node
(relevant for client API and Lua scripting) left it to false.
Also "document" the flag.
|
| |
|
|
|
|
|
|
|
|
| |
Basically, see the example in input.rst.
This is better than the "old" vf-toggle method, because it doesn't
require the user to duplicate the filter string in mpv.conf and
input.conf.
Some aspects of this changes are untested, so enjoy your alpha testing.
|
| |
|
|
| |
Nobody needs to read all the text below it, really.
|
| |
|
|
|
|
|
|
|
|
| |
Add subtitle filter to remove additions for deaf or hard-of-hearing
(SDH). This is for English, but may in part work for others too.
This is an ASS filter and the intention is that it can always be
enabled as it by default do not remove parts that may be normal text.
Harder filtering can be enabled with an additional option.
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
| |
Add a demux_start_time property, update docs.
|
| |
|
|
|
|
|
|
|
|
|
| |
This makes the code more closely match mpv's style. Specifically, it
changes some names from camelCase to snake_case, removes some Hungarian
notation, replaces direct vtbl access with COM macros, makes use of the
SAFE_RELEASE macro, moves some declarations closer to their first use,
and fixes the brace style, as well as a few other things.
This also makes the IDropTargetVtbl static and it fixes the buggy
QueryInterface implementation.
|
| |
|
|
|
|
| |
This was mostly self-contained, so its removal makes w32_common.c a bit
easier to read. Also, because it was self contained and its author has
agreed to LGPL relicencing, the new file has the LGPL licence header.
|
| |
|
|
|
|
| |
input_size can be the size of a cropped image
Signed-off-by: wm4 <wm4@nowhere>
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove low quality drc filter. Anyone whishing to have dynamic range
compression should use the much more powerful acompressor ffmpeg filter:
mpv --af=lavfi=[acompressor] INPUT
Or with parameters:
mpv --af=lavfi=[acompressor=threshold=-25dB:ratio=3:makeup=8dB] INPUT
Refer to https://ffmpeg.org/ffmpeg-filters.html#acompressor for a full
list of supported parameters.
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
| |
Appears to give better formatting. (I'll never understand rst...)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Compensates for wider fonts like DejaVu Sans Mono.
Further compensate for the minus sign in the right timecode by 10px.
Closes #3952
|
| |
|
|
| |
This removes the twitch of the right-aligned cache status.
|
| |
|
|
|
|
|
|
|
|
| |
Will still hide playlist items with long enough filenames and osd-font-size
but not as soon.
osc messages should now preserve their scaling with fullscreen toggling and
cycling through audio-only files and files with video.
Closes #4081, #4083, #4102
|
| | |
|
| |
|
|
|
|
| |
Requested. The property semantics are a bit muddy due to lack of effort.
Anticipated use is different display of cache status, so it should not
matter anyway.
|
| |
|
|
|
|
|
|
|
|
| |
The delay between call to .resize, which cleared the buffer, and
actually rendering the first video frame, was significant, resulting in
short flicker on navigation and resizing. This was especially visible
when zooming and navigating between images.
Now the clearing is scheduled to happen just before the rendering, which
looks to be good enough even without double buffering.
|
| |
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
If vaapi was found, but neither the old or new libavcodec vaapi hwaccel
API, then HAVE_VAAPI_HWACCEL will be defined, but not _OLD or _NEW. The
HAVE_VAAPI_HWACCEL define pretty much exists only for acrobatics with
our own waf dependency checker helper code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new API works like the new vaapi API, using generic hwaccel support.
One minor detail is the error message that will be printed if using
non-4:2:0 surfaces (which as far as I can tell is completely broken in
the nVidia drivers and thus not supported by mpv). The HEVC warning
(which is completely broken in the nVidia drivers but should work with
Mesa) had to be added to the generic hwaccel code.
This also trashes display preemption recovery. Fuck that. It never
really worked. If someone complains, I might attempt to add it back
somehow.
This is the 4th iteration of the libavcodec vdpau API (after the
separate decoder API, the manual hwaccel API, and the automatic vdpau
hwaccel API). Fortunately, further iterations will be generic, and not
require much vdpau-specific changes (if any at all).
|
| |
|
|
|
|
| |
Might be useful for other backends too. For context_vdpau, resize
handling, presentation, and handling the mapping state becomes somewhat
less awkward.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In some cases, such as when using the libmpv opengl-cb API, or with
certain vo_opengl backends, the main framebuffer is never accessed.
Instead, rendering is done to a FBO that acts as back buffer. This meant
an incorrect/broken bit depth could be used for dithering.
Change it to read the framebuffer depth lazily on the first render call.
Also move the main FBO field out of the GL struct to MPGLContext,
because the renderer's init function does not need to access it anymore.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Useful for testing. Unfortunately, the nVidia EGL driver ignores this,
and returns a GLES 3.2 context anyway (which it is allowed to do). Might
still be useable with ANGLE, which will really give you a GLES 2 context
if you ask for it.
|
| |
|
|
|
|
|
| |
When dumb mode is used (the "simple" rendering path), respect the dither
options. Options should never be ignored (except in GLESv2 mode); either
they should be respected in dumb mode, or they should disable dumb mode.
In this case, the former applies.
|
| |
|
|
|
|
|
| |
This actually fixes the dreaded errors during resizing. It works pretty
much like before, except each surface is reallocated before it's used.
It implies surfaces with the old size remain in the presentation queue
and will be displayed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't assume 0 is an invalid object handle. vdpau with its weird API
design makes all objects indexes, with 0 being a perfectly valid and
common value. You need to use VDP_INVALID_HANDLE, which is not 0.
Don't crash if init fails at vdpau initialization. It's because
mp_vdpau_destroy(NULL) crashes. Simplify it.
Destroy output surface backed FBO before output surface. Also, strictly
bookkeep the map/unmap calls (and unmap surfaces before destroying the
FBO/texture). I can't see a change in the weird errors when resizing the
window, but I guess it's slightly more correct.
Add the GL_WRITE_DISCARD_NV symbol to header_fixes.h, because we might
fail compilation with headers that do not contain the vdpau extension
(well, probably doesn't matter).
|
| |
|
|
|
|
|
| |
The gl_timer_last_us() function could access samples[-1]. Fix by
coercing to unsigned, so the % will put it into index [0,max). The
real value returned in this corner case doesn't mean too much, I
guess.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As the manpage says, this has no value other than adding bugs.
It uses code based on context_x11.c, and basically does very stripped
down context creation (no alpha support etc.). It uses vdpau for
display, and maps vdpau output surfaces as FBOs to render into them.
This might be good to experiment with asynchronous presentation. For
now, it presents synchronously, with a 4 frame delay (which should whack
off A/V sync). The forced 4 frame delay is probably also why interaction
feels slower.
There are some weird vdpau errors on resizing and uninit. No idea what
causes them.
|
| |
|
|
|
|
| |
Should have done this 1000 years ago. Now GL backends can use mp_log
macros directly on the MPGLContext, instead of doing stupid things like
for example MP_WARN(ctx->vo, ...).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is just a pointless refactor with the only goal of making
image_writer_opts.format a number.
The pointless part of it is that instead of using some sort of arbitrary
ID (in place of a file extension string), we use a AV_CODEC_ID_. There
was also some idea of falling back to the libavcodec MJPEG encoder if
mpv was not linked against libjpeg, but this fails. libavcodec insist on
having AV_PIX_FMT_YUVJ420P, which we pretend does not exist, and which
we always map to AV_PIX_FMT_YUV420P (without the J indicating full
range), so encoder init fails. This is pretty dumb, but whatever. The
not-caring factor is raised by the fact that we don't know that we
should convert to full range, because encoders have no proper way to
signal this. (Be reminded that AV_PIX_FMT_YUVJ420P is deprecated.)
|
| |
|
|
| |
Nobody cares about those.
|
| |
|
|
|
|
|
| |
The buffer_size may be updated before the process callback is called for
the first time. Or, the connection graph could change, which changes the
latency of the pipeline after mpv's output. Ensure we keep on top of
these changes by registering callbacks to update our latency estimation.
|
| |
|
|
|
|
|
|
| |
This also will set image=NULL, if the video frame is marked as hwaccel,
and could not be copied to normal RAM. This will probably change the
error message (due to screenshot_get() returning NULL, instead of making
image conversion fail at a later point), but the behavior is the same
anyway.
|
| | |
|
| |
|
|
|
|
|
| |
The function tried to do something clever but ignored the fact that
the middle button followed the left button rather than the right.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
|
| |
|
|
| |
See #4227.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
On some DVDs, title number is not necessarily the same as the (first)
PGC number. (Most often they are equal, since there's usually exactly
one PGC per title, which is likely why this issue wasn't noticed
before.) When searching for audio/subtitle metadata, we want to look
at the actual PGC we're about to play. See discussion in issue #4235.
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
|
|
|
|
| |
This means the subtitles will show as "intended".
For some weird reason, --sub-ass-style-override is the option that
controls style override, which implies it's specific to ASS. While that
seems weird and doesn't always reflect reality, I don't care about that
now.
|
| |
|
|
| |
Pure garbage.
|
| |
|
|
|
|
| |
I guess that's the full extent I still care about nVidia's broken
garbage. In theory, we could always force the video mixer (which is the
only method getting the video data that works), but why bother.
|
| |
|
|
|
|
|
| |
The "return false;" was debugging code.
In addition, filter a plain "default", because it's not going to do
anything interesting and just looks ugly.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It appears some device can be missing if we filter too many. In
particular, I've seen devices starting with "front" and "sysdefault"
being mapped to different hardware. I conclude that it's not sane trying
to present a nice device list to users in ALSA. It's fucked. (Although
kodi appears to attempt some intense "beautification" of the device
list, which includes parsing parameters from the device name and such.
Well, let's not.)
No other audio API requires such ridiculous acrobatics.
|
| |
|
|
|
|
|
|
|
|
| |
Apparently POLLERR can be set if poll is called while the device is in
the SND_PCM_STATE_PREPARED state. So assume that we can simply call
snd_pcm_status() to check whether the error is because the device went
away (i.e. we expect it to return ENODEV if this happened).
This avoids sporadic device lost warnings and AO reloads. The actual
device lost case is untested.
|
| | |
|
| |
|
|
|
|
| |
We have direct rendering with hardware decoding now (so no SSE4 for
memcpy from GPU memory required), and also OpenGL drivers are not so
much of a problem anymore with ANGLE being default.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
due to the see-through nature of the title bar and our standard black
window background, the title bar appears dark grey opposed to the
expected light grey.
we change the window background to white but at the same time set the
background of the enclosed view to black. that way the title bar has a
white background and the background of our video stays black in all
cases. this prevents white flashing in some cases when the video is
resized with too heavy render settings.
|
| |
|
|
| |
Fixes #4204
|
| |
|
|
| |
Fixes #4194
|
| |
|
|
|
| |
The hack becomes unnecessary with newer versions, but it's still needed
for older ones.
|
| |
|
|
|
|
|
|
|
|
| |
Relevant:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=0798fddb5000f2b1edffc693ec65236a680ce61f
Eventually I'll just remove this option. But it's probably good to leave
it for while, possibly for letting Mesa VA driver users test and confirm
this.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Probably does much more:
+ add support DVB-T2
* DVB params set to AUTO by default
* MAX_CARDS: 4 -> 16
* DMX_SET_BUFFER_SIZE: 64kb -> 256kb
+ add DTV_CLEAR call before tune
+ add logic from https://github.com/olifre/mpv/commits/dvb-mixed-api-scan
* rename type to delsys
* single playlist per adapter
* card -> adapter
* fix channels order in playlist
* update internal api
* auto fallback to old DVB API on tune
* fix DELSYS_SUPP_MASK value
* remove tone - unused
* add channel mem zeroize in config parser
+ add code from libdvbv5 for detect delivery systems
* SYS_DVBC_ANNEX_AC replaced to SYS_DVBC_ANNEX_A + SYS_DVBC_ANNEX_C
Signed-off-by: wm4 <wm4@nowhere>
|
| | |
|
| |
|
|
| |
(Helps shell completion.)
|
| |
|
|
|
|
|
|
|
|
| |
For an unknown reason, '-Wl -export-dynamic' doesn't work anymore
on the last macOS build (10.12.3 with Apple LLVM 8.0.0) so forcing
cplugins is useless because the check fails. Replacing the linker
option with its substitute '-rdynamic' do the trick.
The syms module from waf still works as expected and only the
symbols specified in mpv.def are exported.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The existing code modifies f.radius so that it is in terms of the
filter sample radius (in the source coordinate space) and has
some small errors because of this behavior.
This commit changes f.radius so that it is always in terms of
the filter function radius (in the destination coordinate space).
The sample radius can always be derived by multiplying f.radius
by filter_scale, which is the new, more descriptive name for the
previous inv_scale.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Modifications to the input coordinates should all be performed
before the final range check against the filter boundaries.
However, in the existing code, the blur/taper is applied after the
filter radius check is performed. Thus, effectively the filter radius
cutoff is applied to only-downscaling-metric-modified coordinates, not
the final coordinates.
Correct this issue and restructure the returns a bit to make it
more obvious what is being done.
|
| |
|
|
|
|
|
| |
Depends on FFmpeg commit ade7c1a2326e2bb9b.
It has yet to show whether it actually does what it should. Probably
doesn't.
|
| |
|
|
|
|
| |
Needed for the following commit.
Also, fix that uint32_t type - we always assumed int.
|
| |
|
|
|
|
|
| |
Basically, the opengl-cb API causes fewer issues, even if it's a bit
harder on the API user.
See #4197.
|
| |
|
|
|
|
|
|
|
| |
Apparently fixes youtube mp4 streams if avformat_find_stream_info() is
not called.
Keeping audio/video track and other track durations separate is for
the sake of embedded subtitle streams, where we want to include the
duration of overlong subtitle streams (I think).
|
| |
|
|
|
|
| |
I find it slightly helpful in some situations.
Also change the code to have a single exit path to make this easier.
|
| |
|
|
| |
It didn't deinterlace at all. Oops.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm not sure what's going on here, but it appears kodi switches forward
and backwards references for advanced VPP deinterlacing modes. This in
turn makes deinterlacing with these modes apparently work. If you don't
switch the directions, you get a stuttering mess.
As far as the libva trace dump is concerned, this makes mpv's libva
deinterlacing API use behave like kodi's, and appears to reproduce
smooth video with advanced libva deinterlacing enabled.
I'm hearing that Mesa actually does it correctly, and I'm not sure what
will happen there. For now, passing "reversal-bug=no" as sub-option to
the vavpp filter will undo this behavior.
|
| |
|
|
|
|
|
| |
Fully initialize two structs (not doing so may or may not have been a
bug).
Actually destroy the VABufferID we create (moderate memory leak).
|
| |
|
|
|
|
|
|
|
|
|
| |
forcibly moving a window from one screen to another is supposed to put
it in a position that looks relative the same as on the old screen, as
in bottom, top, left and right margin look the same, without changing
the window size. in some situations the old code moved the window off
screen or on top of the menu bar so it ended up at a somewhat random
position. the new code fixes some edge cases but is probably not
completely correct since the priority is to make sure that the window
ends up on the right screen.
|
| |
|
|
|
|
|
|
|
|
|
| |
when forcibly moving windows to a different screen with --screen or
--fs-screen we need to move the window into the screen bounds if the
window is out of bounds, otherwise it can end up on the wrong screen.
previously it always recalculated the bounds and moved the window when
toggling fullscreen, now it only does the bound calculation when
changing screens.
Fixes #4178
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
i falsely assumed that the windowDidChangeScreen was meant to report
‘physical’ screen changes but was wondering why it triggers on other
events too. it actually is a event that informs us when anything
referenced by our current NSScreen is changed. even when something
referenced in the NSScreen changed the old and new NSScreen are still
equal if the physical screen didn’t change. with that my previous
optimisation broke some cases where the physical screen didn’t change
but things it referenced did, leading to a segfault when theses were
accessed. to keep the optimisation we will always update our internal
NSScreen reference but the rest only when the physical screen was
changed.
|
| |
|
|
|
|
|
| |
initialise OSC with a zero mouse area so mp_input_test_dragging returns
a proper value.
Fixes #1819
|
| |
|
|
| |
Fixes #3242
|
| | |
|
| |
|
|
|
|
|
|
| |
This is apparently what happens in this situation:
Turn off display with DPMS, turn back on with DPMS. MPV is hung.
See #4189.
|
| |
|
|
| |
Fixes #4188 as pointed out in the issue.
|
| |
|
|
|
|
|
|
| |
What a fucking waste of time. It depends on with which headers you
compile as well, so the situation is worse and more confusing than
you'd think. God knows what brain fart made them change the numeric
ID without changing the extension name or any other ways to keep
ABI-compatibility and without any warning.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
FFmpeg could crash with vaapi (new) and --vo=opengl + interpolation.
It seems the actual surface count the old vaapi code uses (and which
usually never exceeded the preallocated amount) was higher than what
was used for the new vaapi code, so just correct that. The d3d helpers
also had weird code that bumped the real pool size, fix them as well.
Why this would result in an assertion failure instead of a proper error,
who knows.
|
| |
|
|
|
|
| |
Don't give the driver more forward/backward refernces than it requested
in num_forward_references/num_backward_references. This shouldn't
matter, I'm just trying to play it safe.
|
| |
|
|
|
|
| |
This is probably wrong. Just don't bother with it. The only potentially
negative effect is from calling vaQueryVideoProcPipelineCaps() every
frame.
|
| |
|
|
|
|
| |
Locale-independent, and doesn't have the char vs. unsigned char problem.
(Although in this case, the code was fine, because bstr.start is
unsigned char.)
|
| |
|
|
|
|
|
|
|
| |
Fixes theoretical lock-order issues found by Coverity. Calling these
inside the log is unnecessary anyway, because they have their own
locking, and because mpv_detach_destroy() needs to be called by someone
who has exclusive access to the mpv_handle (it's basically a destructor
function). The lock order issues comes from the fact that they call back
into the client API implementation to broadcast events and such.
|
| |
|
|
|
|
|
|
| |
Includes hls, mp4, mkv by default. This also avoids stupid things like
decoding at least 1 video frame per stream in the demuxer.
This also add --demuxer-lavf-probe-info to give finer control over what
happens.
|
| |
|
|
|
| |
The function ignores AVBufferSrcParameters.channel_layout. Set it
manually using the API.
|
| |
|
|
|
|
|
|
|
|
| |
fffab30 introduced a small regression where the cursor couldn't be
unhidden after refocusing. the problem is that no mouseUp event was
reported in our events_view. work around this with a separate event
monitor. this also fixes another regression when the window is being
dragged from the title bar.
#4174
|
| |
|
|
|
|
| |
This was added for A-B loops, but it looks like commit a1dec6f5 made
this code unnecessary. Remove it, because it has the annoying
side-effect of blocking playback stop when seeking past the end.
|
| | |
|
| |
|
|
| |
I can't find any actual need for it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a race condition created by the previous commit, and possibly
others. Sometimes interpolated frames weren't redrawn as uninterpolated
ones.
The problem is that redrawing/drawing a frame can't reset the VO
want_redraw flags, because logically these have to happen after the core
acknowledged and explicitly reissued a redraw. The core needs to be
involved because the OSD text and drawings could depend on the playback
or window state.
Change it such that it always goes through the core.
Also, VOs inconsistently called vo_wakeup() when setting want_redraw,
which is also taken care of by this commit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When pausing, we sent BOCTRL_PAUSE and VOCTRL_RESTORE_SCREENSAVER. These
essentially wait until the video frame has been rendered. This is a
problem with the opengl-cb, if GL rendering is done in the same thread
as libmpv uses. Unfortunately, it's allowed to use opengl-cb this way.
Logically speaking, it's a deadlock situation, which is resolved with a
timeout. This can lead to quite ugly effects, like the on-pause frame
not being rendered until the timeout has passed. It has been interpreted
as video continuing to play.
Resolve this by simply not blocking on pause. Make the screensaver
controls async, and handle sending VOCTRL_PAUSE in the VO thread.
(All this could be avoided by redoing the internal VO API.)
Also see #4152.
|
| |
|
|
|
| |
Flags like MP_IMGFLAG_YUV were meaningless for hwaccel formats, and
setting fields like component_bits made even less sense.
|
| |
|
|
|
|
|
|
| |
If imgfmt is a hwaccel format, hw_subfmt will contain the CPU equivalent
of the data stored in the hw frames.
Strictly speaking, not doing this was a bug, but since hwaccel formats
were tagged with MP_IMGFLAG_YUV, it didn't have much of an impact.
|
| |
|
|
|
|
|
| |
For example, previously, --audio-device='alsa/' would provide ao->device="" to
the alsa driver in spite of the fact that this is an already parsed option. To
avoid requiring a check of ao->device[0] in every driver, make sure this never
happens.
|
| |
|
|
|
|
| |
even though the mouse doesn’t move relative to the window itself, when
the window is being dragged, some outliers are still reported and
trigger the OSC.
|
| |
|
|
|
|
| |
fixes the case when mpv is opened and the cursor is within the window
bounds without moving the mouse. previously the window could only be
dragged around after the first mouse movement.
|
| | |
|
| | |
|
| |
|
|
|
| |
Doesn't matter, since it's the flush call, but be nice. In particular,
don't upset coverity.
|
| |
|
|
|
|
|
|
|
| |
Currently, tracks have always associated streams, so there can't be a
NULL dereference on the next line. But all the code is written with the
possibility in mind that we might want tracks without streams, so make
it consistent.
Found by coverity.
|
| |
|
|
| |
OK, they're redundant. Now stop wasting my time, coverity.
|
| |
|
|
|
|
| |
Probably didn't happen in practice, but anyway.
Found by coverity.
|
| |
|
|
|
|
|
| |
Found by coverity.
All of these cases happened to work, probably even in 32 bit (when the
name pointer allowed it to use only 4 bytes of space).
|
| |
|
|
|
|
| |
Not so important by itself, but important for when we replace the vf
libavfilter wrapper with the common implementation. (Which will
hopefully happen, but not too soon.)
|
| |
|
|
|
| |
It's nice that you don't have to create a parameter string anymore, but
the rest sure is complicated as hell.
|
| |
|
|
|
|
|
|
|
|
| |
Preparation for enabling hw filters. mp_image_params can't have an
AVHWFramesContext reference (because it can't hold any allocations, and
isn't meant to hold "active" data in the first place.
So just use a mp_image. It has all real data removed, because that would
essentially leak 1 frame once the decoder or renderer don't need it
anymore.
|
| |
|
|
| |
They're unrelated. Sue me.
|
| |
|
|
|
|
| |
Not needed under any circumstances. While the Windows ones export
functions to which we must link, these functions are always available,
even if libavcodec was compiled with D3D disabled.
|
| |
|
|
|
| |
Well, not like we can detect whether it's missing from libavcodec, but
it's still slightly better.
|
| |
|
|
|
|
|
|
| |
hw_vaapi.c didn't do much interesting anymore. Other than the function
to create a device for decoding with vaapi-copy, everything can be done
by generic code. Other libavcodec hwaccels are planned to provide the
same API as vaapi. It will be possible to drop the other hw_ files in
the future. They will use this generic code instead.
|
| |
|
|
|
|
|
|
|
| |
This was a hack to let libmpv API users pass a d3d device to mpv. It's
not needed anymore for 2 reasons:
1. ANGLE does not have this problem
2. Even native GL via nVidia (where this failed) seems to not require
this anymore
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
even before the recent refactor the cursor was hidden when moving it to
the top of the screen in fullscreen and placing it on top of the now
visible menu bar.
we need to know when the menu bar is hidden so we don’t create a
‘dead zone’ at the top of the screen where the cursor can’t be hidden.
to determine when the menu bar is visible, and with that the title bar,
we get the height of the menu bar. the height is always 0 when hidden.
furthermore there is no way to get the title bar directly and with that
its height. so we calculate the frame rect of a NSWindowStyleMaskTitled
window from a CGRectZero content frame. the resulting height is the
height of a title bar.
with that we can exclude the top area for the cursor hiding and can be
certain when the menu bar is not hidden.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the cursor couldn’t be hidden when the cursor was at the same position
as the Dock, even if the cursor was next to it. this is especially
annoying in fullscreen since the Dock isn’t actually hidden but is still
reported as being visible. this basically made the part of the screen,
where the Dock resides, a ‘dead zone’. so instead of using the
visibleFrame we will just use the normal frame. there is no problem at
the top area of the screen, since a window can’t be placed above the
menu bar and in fullscreen the menu bar is always reported as not being
on screen.
i suspect this was done so the cursor wasn’t hidden when the it was
placed above the Dock when windowed. with the recent refactor this is
not needed any more.
|
| |
|
|
|
|
|
|
|
|
| |
we can simplify the code because we don't need to change the bool
pointer we were given by the VOCTRL_SET_CURSOR_VISIBILITY event. i
assume this was done to work around some bugs previously to the recent
cursor refactor. i kept that because i thought it was necessary, which
wasn't in the end. after the refactor it only caused some weirdnesses i
tried to work around. without it we can get rid of some special cases
and simplify the code quite a bit.
|
| |
|
|
|
|
|
| |
holding shift swaps the scroll wheel axes and deltaY returned zero.
summing up deltaX and deltaY will always give us the right button.
Fixes #3506
|
| | |
|
| |
|
|
|
| |
Broken with waf 1.9.8 update.
Not noticed right away if previous waf version was present.
|
| |
|
|
|
|
|
| |
Travis being a POS again.
Why does the travis config even have tol be part of the source code
repo? This makes no sense.
|
| |
|
|
| |
Similar to code used everywhere else we create a lavc context.
|
| |
|
|
|
| |
I don't know what's this comment about hardware decoding. Possibly it
was written before vo_opengl had vaapi decoding support.
|
| |
|
|
|
|
| |
Implements --hwdec=videotoolbox on iOS. Similar to hwdec_osx.c, but
using CVPixelBuffer APIs available on iOS instead of the equivalent
IOSurface APIs in macOS.
|
| |
|
|
| |
Regression from recent refactor.
|
| |
|
|
| |
Seems like it has been long enough since we last updated.
|
| |
|
|
| |
Plus add a helper.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can drop the custom table.
For some reason, the interop does not accept GL_RGB_RAW_422_APPLE as
internal format for GL_RGB_422_APPLE, so switch the format table to use
GL_RGB (this way both interop and real textures work the same).
Another victim of the apparent requirement of exactly matching texture
formats is kCVPixelFormatType_32BGRA. vo_opengl wants to handle this as
normal RGBA texture, with a swizzle applied in the shader.
CGLTexImageIOSurface2D() rejects this, because it wants the exact
internal format. Just drop the format, because it's useless anyway.
(Maybe this is a bit too fragile...)
|
| |
|
|
| |
Gives us automatically support for all formats vo_opengl supports.
|
| |
|
|
|
|
|
| |
All supported pixel formats have a specific "mapping" of CPU data to
textures. This function determines the number and the formats of these
textures. Moving it to a helper will be useful for some hardware decode
interop backends, since they all need similar things.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GL_LUMINANCE_ALPHA is the only reason why per-plane swizzles exist.
Remove per-plane swizzles (again), and regrettably handle them as
special cases (again). Carry along the logical texture format (called
gl_format in some parts of the code, including the new one).
We also don't need a use_integer flag, since the new gl_format member
implies whether it's an integer texture. (Yes, the there are separate
logical GL formats for integer textures. This aspect of the OpenGL API
is hysteric at best.)
This should change nothing about actual rendering logic and GL API
usage.
|
| |
|
|
|
| |
Wrong colors. This didn't matter for the OpenGL interop code, because
the CV format was mapped to the correct texture format.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Originally, there was probably some sort of intention to restrict it to
formats supported by the interop, or something. But in the end it was
overcomplicated nonsense.
In the future, we could use mp_hwdec_ctx.supported_formats or other
mechanisms to handle this in a better way.
mp_hwdec_ctx.ctx is not set to a dummy pointer - hwdec_devices_load() is
only used to detect whether to vo_opengl interop is present, and the
common hwdec code expects that the .ctx field is not NULL.
This also changes videotoolbox-copy to use --videotoolbox-format,
instead of the FFmpeg-set default.
|
| |
|
|
|
| |
Introduce mp_imgfmt_to_cvpixelformat(), and change the existing
mp_imgfmt_from_cvpixelformat() to a table to avoid duplication.
|
| |
|
|
|
|
|
|
| |
The code for copying a videotoolbox surface to mp_image was duplicated
(with some minor differences - I picked the hw_videotoolbox.c version,
because it was "better"). mp_imgfmt_from_cvpixelformat() is somewhat
duplicated with the vt_formats[] table, but this will be fixed in a
later commit, and moving the function to shared code is preparation.
|
| |
|
|
| |
The option was removed a while ago.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
we reported some unnecessary mouse movements and not all mouse enter
and leave events. that lead to wrongly reported activity on hover areas
like on the OSC or comparable lua scripts. sometimes menu items were
shown that shouldn't be shown or they didn't vanish because of the
missing mouse leave event.
this incorporates @torque's fix for mouse leave events that weren't
triggered during a transition, like going to fullscreen. the
tracking area was updated but the mouse never left that area because
it was never over it.
besides some known cursor visibility bugs the aforementioned changes
also revealed some other bugs that weren't reproducible before because
of the missbehavior.
known issues, in some cases the cursor doesn't show or hide properly.
for example when switching spaces, switching Apps via CMD+Tab or a
system notification. former two could be fixed while keeping our current
blank cursor approach. though the notification case couldn't. there is
no event or similar to detect a notification and the cursor visibility
couldn't be recovered in any way.
new issues, i noticed that our event view isn't initialised yet when the
first VOCTRL_SET_CURSOR_VISIBILITY event gets dispatched, which depends
on the event view to be initialised. so the mouse cursor couldn't be
hidden when mpv was opened and the cursor was within the window bounds.
this wasn't noticeable before because of various bugs and unwanted
behavior that have been fixed with this. now, in case the event view
isn't ready yet, we set the visibility at a later point when the event
view is ready and a helper flag is set.
Fixes #1817 #3856 #4147
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
we have two problems here. first when mpv is started from the bundle it
uses its own environment variables and possibly can't find for example
the youtube-dl binary for our youtube-dl hook. second we couldn't
reliable determine when mpv was started from the bundle, which led to
the pseudo-gui usage even when the binary was invoked from a shell.
to prevent this we will wrap the bundle binary with a shell script,
which will only be called when we start mpv from the bundle. this way
we can get the same environment variables, like $PATH, for our bundle
and additional we can set the pseudo-gui only when started through this
script. it is also possible to detect the bundle usage properly and
accurately through the usage of another environment var.
Fixes #2061
|
| |
|
|
| |
Dumb.
|
| |
|
|
|
| |
Now hw_vaapi.c contains only the device setup, which could probably also
be abstracted.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
quitting mpv from the Dock's context menu leaves the shell in a bad
state where you can't see your input any more and other weirdnesses.
in a big refactor (afdc9c4) the method to handle this case was actually
copied over but the the code to register the event itself was removed or
forgotten by accident, leaving some lines of dead code. i re-added the
event and slightly adjusted the function. the function was slightly
changed so the head of it is consistent with our other events and it is
associated with this commit and functionality in the future.
|
| |
|
|
|
|
|
|
|
|
| |
The "Files without Copyright notice are licensed as LGPLv2.1+."
statement makes it sound like the manpage and some other stuff are LGPL.
But the rule actually affects only some source files that were added in
mpv.
Change the wording, and also explicitly list the licenses for some non
source files. There might be more such cases.
|
| |
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
|
|
|
| |
This reverts commit df91e492fd3365cf7db9c6ba4a721f8fcce0521c.
Multiple issues such as weird code with undefined behavior (like
(like conf_file*). The PR wasn't properly reviewed anyway (my error),
so this commit should be reviewed and then merged again.
|
| | |
|
| |
|
|
|
|
|
|
| |
this fixes a small bug with black edges on live resize, due to the
synchronisation with the DisplayLink. we just pause the DisplayLink for
the duration of the live resize. i also added some convenience functions
for reoccurring calls and simplified some DisplayLink related screen
info.
|
| |
|
|
|
|
|
|
|
|
| |
since there are different views on what ontop is, we make the ontop
window level modifiable. at the moment only support for macOS was added.
the default for macOS was changed from 'system' to 'window' since this
fixes an unwanted behaviour in fullscreen and in general causes less
issues with expected behaviour.
Fixes #2376 #3974
|
| |
|
|
|
|
|
|
|
|
|
| |
The AVFrame in the tmp_frame field was never actually deallocated.
Since this AVFrame holds data temporarily only, and is unreferenced
immediately after use, there is actually no need to make it per-pad, so
simplify it a bit.
(There's also no real value in caching this tmp_frame at all, but I
guess it makes the control flow slightly simpler.)
|
| |
|
|
|
|
| |
We can do this now, which means we can pass a mp_image through
libavfilter without loss. Currently, this affects relatively obscure
fields only.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Probably does much more:
+ add support DVB-T2
* DVB params set to AUTO by default
* MAX_CARDS: 4 -> 16
* DMX_SET_BUFFER_SIZE: 64kb -> 256kb
+ add DTV_CLEAR call before tune
+ add logic from https://github.com/olifre/mpv/commits/dvb-mixed-api-scan
* rename type to delsys
* single playlist per adapter
* card -> adapter
* fix channels order in playlist
* update internal api
* auto fallback to old DVB API on tune
* fix DELSYS_SUPP_MASK value
* remove tone - unused
* add channel mem zeroize in config parser
+ add code from libdvbv5 for detect delivery systems
* SYS_DVBC_ANNEX_AC replaced to SYS_DVBC_ANNEX_A + SYS_DVBC_ANNEX_C
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
| |
video/out/opengl/hwdec.h includes video/out/opengl/common.h, which tries
to include opengl headers.
|
| |
|
|
|
|
|
|
| |
Using these was a temporary solution while some compilers implemented
the underlying atomic mechanisms, but not the C11 language parts (or
that's what I guess). Not really useful for us anymore. Also, there is
the slight risk of having subtly incorrect semantics by using
potentially changing compiler internals and such.
|
| |
|
|
|
| |
If a maximized window restored from fullscreen,
the fullscreen state needs to be updated manually.
|
| | |
|
| |
|
|
|
| |
This should be useful for debugging, since otherwise it's hard to tell
which implementation has been auto-detected or if any failed to init.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Seen with a VOD of a recently ended livestream on Youtube.
They seem to use segmented DASH but unlike normal Youtube
segmented DASH, the segments don't seem to need the initialization
segment.
The video actually fails to start to play if the init segment is
prepended with a lot of 'Found duplicated MOOV Atom. Skipped it' errors
popping up.
|
| |
|
|
|
|
|
| |
The missing newline made the github rst renderer (which is a POS) hide
the entire section.
Also, add some more warning text.
|
| |
|
|
|
|
|
| |
This fixes a crash when changing channels; previously stream->priv would not
be initialized when dvb_get_state reused the existing state.
Signed-off-by: Thomas VanSelus <tvanselus@diospyros.us>
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fall back on PATH_DEV_DSP if nothing is set.
This mirrors the behaviour of --audio-device / --alsa-device.
There doesn't appear to be a general way to list devices with oss, so
--audio-device=help doesn't list oss devices except for the default one if the
file exists.
Previously --audio-device was ignored entirely by ao_oss.
fixes #4122
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we have a disconnected output, read data only passively (and don't
cause input to be written). Otherwise, we're in danger of making
libavfilter queue too many frames on other outputs which are connected
to the same input, but don't read as quickly.
Also don't set pad->output_needed in this specific case, because it
would nonsensically make lavfi_process() return true, even if nothing is
going on.
This commit breaks if there is a simple filter chain with a connected
input, but a disconnected output, like
--lavfi-complex='[aid1] copy [ao]'
and the audio output didn't initialize correctly. This will eventually
starve video as the audio packet queue get full (it will print a
warning, and then assume video EOF and exit).
But whatever.
Probably fixes #4118.
|
| |
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
|
| |
Also the one in interface-changes.rst.
Fixes #4121.
|
| |
|
|
| |
Small oversight, matters for OOM errors.
|
| |
|
|
|
| |
This is basically a WIP, but it can't remain in a branch forever. A
warning is print when using it as it's still a bit "shaky".
|
| |
|
|
| |
Whoops. Fixes #4119
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This replaces the old backend that exclusively used EGL windowing with
one that can also use ANGLE's ability to render to directly to a
texture. The advantage of this is that it allows mpv to create the swap
chain itself and this allows mpv to use a flip-mode swap chain on a HWND
(which avoids problems with DirectComposition) and to use a longer swap
chain that has six backbuffers by default (which reportedly fixes
problems with rendering 24fps video on 24Hz monitors.)
Also, "screenshot window" should now work on DXGI 1.2 and up (Windows 8
and up.)
|
| |
|
|
| |
They're unsupported only in MP4 DASH mode.
|
| |
|
|
|
| |
The existing discussion has managed to convince people they should
use cuda-copy instead of cuda, which just isn't right.
|
| | |
|
| |
|
|
|
| |
All entries must be separated by ";" or "\n". The parser just doesn't
enforce it if an entry uses quoting.
|
| |
|
|
| |
Not that we use it...
|
| |
|
|
|
|
|
| |
Some fields (notably tv_channel_list) were left uninitialized,
potentially causing problems later on.
Fixes #4096
|
| | |
|
| |
|
|
|
|
| |
Essentially, this will make it abort sooner. Especially with DASH it
might avoid confusing error messages, although exact behavior depends
on timing.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
We use the metadata provided by youtube-dl to sort-of implement
fragmented DASH streaming.
This is all a bit hacky, but hopefully a makeshift solution until
libavformat has proper mechanisms. (Although in danger of being one
of those temporary hacks that become permanent.)
|
| |
|
|
| |
Cosmetic preparation for later changes.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If used with fuzzy matching, the player tends to pick up random text
files, sometimes with interesting results.
The most interesting interaction is when the user uses
--log-file=something.txt, and mpv tries to open its own log file. It
essentially "freezes" during probing, because every time it reads from
it, it will write some more data, which in turn will cause more data to
be read - until the 2MB max. probing size is slowly reached. This is not
even an obscure corner case, but happened to multiple users.
The .txt extension has been considered a subtitle extension ever since
the code was added to MPlayer's subreader.c, but I'm not seeing many
actual subtitle files with this extension, so just get rid of it.
|
| |
|
| |
As the manual entry for --hwdec states that d3d11va and d3d11va-copy require Windows, it can be assumed that it also works for Windows 7. Since it doesn't, according to https://github.com/mpv-player/mpv/issues/3285#issuecomment-228593539, and personal testing, updating the manual accordingly and making the hwdec OS requirements for ANGLE in line with videotoolbox, where OS version is stated.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of enabling it only when a stream-cache is enabled, also try to
enable it independently from that if the demuxer is marked as
is_network.
Also add some code to the EDL code, so EDLs containing network streams
are automatically cached this way.
Extend the OSD info line so that it shows the demuxer cache in this case
(more or less).
I didn't find where or whether options.rst describes how the demuxer
cache is enabled, so no changes there.
|
| |
|
|
|
|
|
|
|
| |
Because it's kind of dumb. (But not sure if it was worth the trouble.)
For stream_file.c, we add new explicit fields. The rest are rather
special uses and can be killed by comparing the stream impl. name.
The changes to DVD/BD/CD/TV are entirely untested.
|
| |
|
|
|
|
|
|
| |
"uncached_stream" is a pretty bad name. It could be mistaken for a
boolean, and then its meaning would be inverted. Rename it.
Also add a "caching" field, which signals that the stream is a cache or
reads from a cache. This is easier to understand and more flexible.
|
| |
|
|
|
|
|
|
| |
when the color profile was changed it used the right NSScreen but with
the old colorSpace. this was optimised out by a previous commit because
of a wrong assumption. we need to update the screen so we can get the
new colorSpace. this adds a bit of redundancy since on screen change it
will update screen pointer twice.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the problem here is that dropped files can also be treated as
NSURLPboardType instead of just NSFilenamesPboardType. the 'else if'
could never be reached and was dead code.
this basically reverts ed695ce which tried to fix multiple dropped
URLs, or rather files, and moves the filename check infront of the URL
check. the filename path can handle multiple dropped files, whereas the
URL path can only handle one dropped URL. this assumes that only one URL
can be dropped at a time. it also reverts a603543 because it's not
needed any more.
this also fixes a problem where dropped URLs from Chrome don't conform
to the NSURL class and the readObjectsForClasses method always returned
an empty URL.
Fixes #4036
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
this optimises two things and fix a minor bug.
1. we always updated the display refresh rate on any mode change whether
it was the current screen or not. now we only update the refresh rate
when the mode changed happened on the current screen.
2. the windowDidChangeScreen event doesn't exclusively trigger on screen
changes so we updated the display refresh rate in cases where it wasn't
needed at all. since we manually keep track of the current screen, we
can easily test if the screen really changed.
3. weirdly on initWithContentRect accessing the screen of the window
always returned the main screen instead of the screen the window is
created on. since we already use the window init method with the screen
as argument, overwrite that method instead and use the screen argument.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
we are dealing with several problems here, which weren't apparent
because we always initialised a new displaylink for the display refresh
rate retrieval, previously to commit 449eb20 and bug 9490b62.
just changing the display with CVDisplayLinkSetCurrentCGDisplay
can cause inconsistent refresh rates and discontinuity in timestamps.
this can either lead to bogus values for the Actual display refresh rate
or retrieving the refresh rate of the previous display if we immediately
try to get a new value. since the Actual refresh rate is computed i
assume that it at least needs one refresh period to actual return
something useful.
furthermore when changing the screen and updating the displaylink, it
seems that the retrieved refresh rates for the screen mpv wasn't opened
on are being estimated in a sub-optimal way. as an example, when moving
my window to my second screen the Actual refresh rate was always a
constant 60Hz, even though it is supposed to fluctuate a little bit.
though if mpv was started on the secondary screen the Actual refresh
rate fluctuated around 59.94Hz like expected. in that case my primary
screen always reported a constant 60Hz instead.
for the first problem we moved the actual retrieval of the refresh rate
to the very last moment when mpv actual requests a new value and not
when the refresh rate changed. we only update the displaylink itself
when a possible refresh rate change is detected. this gives the
displaylink some time to calculate the new refresh rate. for the second
problem, instead of setting the new display we completely uninitialise
the old dislaylink and create a new one for the new screen. this gives
us properly estimated refresh rates.
additionally we also optimised the display refresh rate fallback
heuristic. it will never be 0 anymore and we prevent it from returning
bogus values with a simple threshold for the difference of the Actual
and Nominal refresh rate.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
several unicode characters can be encoded in two different ways, either
in a precomposed (NFC) or decomposed (NFD) representation. everywhere
besides on macOS, specifically HFS+, precomposed strings are being used.
furthermore on macOS we can get either precomposed or decomposed
strings, for example when not HFS+ formatted volumes are used. that can
be the case for network mounted devices (SMB, NFS) or optical/removable
devices (UDF). this can lead to an inequality of actual equal strings,
which can happen when comparing strings from different sources, like the
command line or filesystem. this makes it mainly a problem on macOS
systems.
one case that can potential break is the sub-auto option. to prevent
that we convert the search string as well as the string we search in to
the same normalised representation, specifically we use the decomposed
form which is used anywhere else.
this could potentially be a problem on other platforms too, though the
potential of occurring is very minor. for those platforms we don't
convert anything and just fallback to the input.
Fixes #4016
|
| |
|
|
|
|
|
|
|
|
|
| |
This should allow us to create the device in situations when
Direct3DCreate9 normally fails, for example if no user is logged in.
While the later use-case is not very interesting, I hope it to work in
some other situations as well, for example while certain drivers are in
exclusive full screen mode.
This is available since Windows 7, so I'm removing the old call
completely.
|
| |
|
|
| |
This makes the player spam timestamp warnings. Return NOPTS instead.
|
| |
|
|
|
|
| |
This could potentially have caused fun crashes if the --tv-channels
option was used, and something more advanced than tv:// was used to open
it. (This code is still untested.)
|
| |
|
|
|
|
|
|
| |
To make it easier for the eyes, multi line subtitles should
be left justified (for most languages).
This adds an option to define how subtitles are to be justified
inpendently of how they are aligned.
Also add option to enable --sub-justify to be applied on ASS subtitles.
|
| |
|
|
| |
Closes #4092
|
| |
|
|
|
| |
"python" usually maps to Python 2, while all Python 3 installations
provide "python3". And the script requires Python 3.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Requested. Supposedly "scenarist closed captions".
(The list of getting quite full. But it's probably still better than
trying to probe the files by contents, because the external subtitle
loader code will initially look at _all_ files in the same directory as
the main file.)
|
| |
|
|
|
| |
Dumb but simple thing. Requires the FFmpeg libvpx decoder wrapper, as
its native decoder doesn't support alpha.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
TOOLS/matroska.py can be used stand-alone for dumping Matroska file
contents. Fix some related issues.
Elements were treated as unknown if the element hex ID contained
uppercase characters.
Unknown elements stopped parsing. This was intentional, but I don't
really see any reason for it.
Dumping with Python 2 is broken. I don't care, but everytime I hit this,
I find myself trying to find out why. So make it error out explicitly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes seeking with:
https://bugs.chromium.org/p/chromium/issues/detail?id=497889
Haali also ignores the element's contents, and interprets its presence
as the block not being a keyframe. FFmpeg is going to have an equivalent
change.
I don't know yet whether the affected sample is valid - a reference
timestamp of 0 doesn't make too much sense to me.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Only used once for now.
Also, support switched format strings, like bestaudio+bestvideo.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
video/out/opengl/hwdec_cuda.c is enabled with cuda-hwaccel. But it makes
only sense to build if GL is enabled, and in fact it fails to link
without GL as it calls a specific GL helper function.
In theory it would be perfectly possible to use cuda-copy with GL
disabled. But I'm not bothering with the complexity.
|
| |
|
|
|
|
|
|
|
|
| |
setting a window level other than NSNormalWindowLevel always sets
NSWindowCollectionBehaviorTransient, which prevents certain things to
work properly. examples are automatic switching to the active Space when
mpv is made active and (de-)miniaturizing. latter always lead to a
vanishing window.
Fixes #1757 #1884
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See: https://msdn.microsoft.com/en-us/library/windows/desktop/dd743946.aspx
Microsoft example code often uses a SAFE_RELEASE macro like the one in
the above link. This makes it easier to avoid errors when releasing COM
interfaces. It also reduces noise in COM-heavy code.
ao_wasapi.h also had a macro called SAFE_RELEASE, though unlike the
version above, its SAFE_RELEASE macro accepted a second parameter which
allowed it to destroy arbitrary objects other than just COM interfaces.
This renames ao_wasapi's SAFE_RELEASE to SAFE_DESTROY, which should more
accurately reflect what it does and prevent confusion with the Microsoft
version.
|
| |
|
|
|
|
|
| |
Useful for distinguishing bit depth when hardware decoding. (To the
degree it's useful to show it at all. This just brings the hardware
decoding case on the same level of showing information as the software
decode call.)
|
| |
|
|
|
| |
Worked with librtmp, but ffrtmp needs to set rtmp_swfurl in addition
to rtmp_swfverify, even if they're the same value.
|
| |
|
|
| |
Try to actually explain what's up with this code.
|
| |
|
|
|
|
|
|
| |
The lock was disabled recently. This commit gets rid of the dummied out
calls. The main reason for removing it is that there is no apparent need
for it anymore, and the new FFmpeg vaapi code does not use or provide
such a lock (there are some places which we cannot control and which do
vaapi API calls, like frame destructors).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When mpv is being linked against static libraries which have shared
libraries as dependencies, linker will throw error because pkg-config
with --static flag will return shared libraries which will be placed
under the -Wl,-Bstatic section, while pkg-config without --static flag
will omit the private libraries required to link the static library.
With this function users can modify the wscript to insert the dependencies
when necessary. For example, linking FFmpeg with shared OpenSSL and zlib:
'func': check_pkg_config_mixed(['crypto','ssl','z'], 'libavcodec')
|
| |
|
|
|
|
| |
MinGW GCC seems to ignore LIBRARY_PATH which causes problem
when some libraries not using pkg-config were installed to
local directory
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Upstream provides pkgconfig files for quite some time now [1,2].
Use them to determine the required flags instead of hard coding.
This makes cross-compilation easy, which I dare to say is important for
many raspberry-pi users. This also prevents picking libEGL and libGLESv2
from mesa when they are present, which can happen with the current code.
Good distros should put these pkgconfig files into default pkg-config
search path or populate PKG_CONFIG_PATH for users. However, be nice to
everybody and manually look into '/opt/vc/lib/pkgconfig' just in case.
Hence the PKG_CONFIG_PATH mangling.
[1]: https://github.com/raspberrypi/userland/issues/245
[2]: https://github.com/raspberrypi/userland/commit/05d60a01d53dca363bb4286594db1826ffff8762
|
| |
|
|
|
|
|
| |
Disabled by default. The snap sensitivity value depends on
the screen DPI. The default value is 16px on a 96 DPI screen.
Fixes #2248
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a first pass, we check whether libavcodec is present.
Then we try to compile a snippet and check for FFmpeg vs. Libav. (This
could probably also be done by somehow checking the pkgconfig version.
But pkg-config can't deal with that idiotic FFmpeg idea that a micro
version number >= 100 identifies FFmpeg vs. Libav.)
After that we check the project-specific version numbers. This means it
can no longer happen that we accidentally allow older, unsupported
versions of FFmpeg, just because the Libav version numbers are somehow
this way.
Also drop the resampler checks. We hardcode which resampler to each with
each project. A user can no longer force use of libavresample with
FFmpeg.
|
| |
|
|
|
| |
It used to be optional. That's why it was separate. No need for that
anymore.
|
| |
|
|
|
|
|
|
|
|
| |
The correctness of the stdatomic.h emulation via the __sync builtins is
questionable, and we've been relying on exact stdatomic semantics for a
while, so just get rid of it. Compilers which support __sync but not
stdatomic.h will use to the slow mutex fallback.
Not sure about the __atomic builtins. It doesn't seem to harm either, so
leave it for now.
|
| |
|
|
|
|
|
| |
This is almost cosmetic, but removes the duplicated EOF-setting.
Somewhat oddly, this will enter the reconnect path and exit it
immediately again - should be fine.
|
| |
|
|
|
|
|
|
|
| |
Commit 7be495b3 added the cancellation test, but forgot to set the eof
flag. This could lead to demux_mkv.c not terminating if the stream was
cancelled in some code paths.
This function is what is supposed to set the EOF flag in the first
place, so just add the missing code.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A hacky, convoluted, half-working mess that attempts to cut off overlong
playlists.
It does so by relying on the ASS formatting rule that the font size is
specified in the virtual PlayResY resolution. This means we can
(normally) easily tell how many lines fit on the screen. On the other
hand, this does not work if the text is wrapped.
This as a kludge until a Better™ solution is available.
|
| | |
|
| |
|
|
|
|
| |
Apparently this is the maximum that can be preserved. There is also
something about the decoder being able only to use 3 frames at a time,
and I'm assuming these are part of the 8 frames.
|
| |
|
|
|
|
| |
It was basically inverted. Not sure how this even happened. Hopefully
it's more an "I don't know what I was doing" instead of an "I don't know
what I am doing" case.
|
| |
|
|
|
|
| |
Replace the reprecated --hwdec-preload option.
Add a comment about cuvid/cuda decoding.
|
| |
|
|
|
|
|
| |
Only FFmpeg supports them and they need to be in the format data://
like other protocols or prefixed with ffmpeg:// or lavf://.
Closes #4058
|
| |
|
|
|
|
|
|
|
| |
When playing with VOs which do not provide mp_hwdec_ctx, vf->hwdec_devs
will remain NULL. This would make it crash on hwdec_devices_get_first(),
even if no hardware decoding or filters using hardware decoding were
involved.
Fixes #4064.
|
| |
|
|
|
|
|
|
|
|
| |
avcodec_parameters_to_context() overwrites codec_type and codec_id. But
we already set these by passing the selected AVCodec to
avcodec_alloc_context3(). It's entirely possible that at least codec_id
is different when forcing codecs with --ad/--vd. It's probably better
not to cause confusion by overwriting them. It might even trigger
undefined behavior in libavcodec (how it behaves or whether codec_id is
supposed to be strictly set is unknown, though).
|
| |
|
|
|
|
|
|
| |
This can be useful in other contexts.
Note that we end up setting AVCodecContext.width/height instead of
coded_width/coded_height now. AVCodecParameters can't set coded_width,
but this is probably more correct anyway.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm still getting some crashes after issue #3210 was fixed in commit
5beb2306904b4437b5acf136b02aeaa073c351c7. It's hard to reproduce those
crashes, they happen maybe once a month, so I guess it could be a race
condition. But in any case, I don't see anything wrong in applying some
defensive programming here.
For reference, here is what was happening on 0.23.0-1 from Debian
testing:
Playing: ytdl://usL5CeP_row
(+) Video --vid=1 (*) (h264)
(+) Audio --aid=1 --alang=und (*) (aac)
[osc]
[osc] stack traceback:
[osc] @osc.lua:2074: in function 'process_event'
[osc] @osc.lua:2246: in function 'cb'
[osc] mp.defaults:107: in function 'fn'
[osc] mp.defaults:60: in function 'handler'
[osc] mp.defaults:339: in function 'handler'
[osc] mp.defaults:448: in function 'call_event_handlers'
[osc] mp.defaults:485: in function 'dispatch_events'
[osc] mp.defaults:441: in function <mp.defaults:440>
[osc] [C]: in ?
[osc] [C]: in ?
[osc] Lua error: @osc.lua:2074: attempt to index field 'eventresponder' (a nil value)
Note that the location is different from where issue #3210 happens.
Signed-off-by: Roland Hieber <rohieb@rohieb.name>
|
| |
|
|
|
|
|
|
| |
"show-text test; script-binding display_stats" can potentially crash. It
sends a message event. None of the string arguments can be NULL, which
fails if cmd->key_name is NULL. This in turn can be due to commands
combined with ";" (basically the key association doesn't consider nested
commands).
|
| |
|
|
|
|
|
|
|
|
| |
Some files appear to use them. In the sample I've seen, one field was
"Performer" instead of "PERFORMER".
This change is slightly risky, because it increases the chance of
misdetecting other formats as cue files.
Fixes #4057.
|
| |
|
|
|
|
|
|
|
| |
Benefits demux_mkv.c, or demux_lavf.c during probing. In particular
demux_lavf.c can sometimes get "stuck" when reading from a slow/blocking
source, and if probing needs more than a few iterations.
Since this is a read of an atomic variable with relaxed semantics, this
should have no impact on reading speed at all, not even theoretically.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This attempted to pass through double float timestamps in a bit exact
way by reinterpret casting them to int64_t. This usually worked, because
libavcodec (in decoding mode) is mostly not allowed to interpret
timestamps. libavcodec doesn't even know the unit of the timestamps,
unless the API user sets a timebase.
We've stopped doing this, and always set a timebase. Only ad_spdif.c
still used this (indirectly through mp_set_av_packet()), but doesn't
actually need timestamps on the packet. In fact, it's already explicitly
setting the packet timestamp fields to 0 before passing it to FFmpeg
API.
This code is unused, and the passthrough method wasn't terribly elegant
to begin with. Drop this code. Arbitrarily use AV_TIME_BASE_Q as
fallback in situations the passthrough was used.
|
| |
|
|
|
|
|
|
|
|
|
| |
Not even Libav does. Whoops. The developer who wrote the FFmpeg code for
this said he could not find any improvements when using the "GPU memcpy"
; instead, it made it actually slower on some hardware.
It's not clear to what extent the "GPU memcpy" was needed for vaapi, but
hopefully not very much (see #2317).
This commit enables use of the new vaapi API by default with FFmpeg.
|
| |
|
|
| |
Unused since the AVCodecParameters change.
|
| |
|
|
|
|
| |
The FFmpeg versions we support all have the APIs we were checking for.
Only Libav missed them. Simplify this by explicitly checking for FFmpeg
in the code, instead of trying to detect the presence of the API.
|
| |
|
|
|
|
|
| |
Since we set "skip_manual", we can actually get frames with this set.
Currently, only AV_PKT_FLAG_DISCARD will trigger this flag, and only
mov.c sets the latter flags, so this is related to FFmpeg's half-broken
mp4 edit list support.
|
| |
|
|
| |
Basically for debugging and dealing with broken files.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This core of this heuristic was once copied from MPlayer's spudec.c. I
think it was meant for the case when the resolution field was missing or
so.
I couldn't find a file for which this actually does something. On the
other hand, there are samples which actually have a smaller resolution
than 720x576, and which are broken by this old hack.
For subtitles that set no resolution (I'm not sure which codec/container
that would be), there's still the fallback on video resolution.
Just get rid of this hack. Also cleanup a bit. SD_CTRL_GET_RESOLUTION
hasn't been used since DVD menu removal. get_resolution() is left with 1
call site, and would be quite awkward to keep, so un-inline it.
|
| |
|
|
|
|
|
|
| |
Seems like quite on oversight.
For most of the better pthread implementations, pthread_mutex_init() on
an already 0-initialized memory block is probably a no-op, but of course
we should do things correctly. Also could setup analysis tools.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For display purposes, it's better to show scrambled text - at least
that's a more actionable failure mode than spamming the terminal with
FFmpeg nonsense error messages.
This avoids the obnoxious and pointless
"Invalid UTF-8 in decoded subtitles text; maybe missing -sub_charenc option"
FFmpeg error, which will be spammed on every single subtitle event. We
don't even have a -sub-charenc option, fuck FFmpeg.
Did I mention fuck FFmpeg yet? Because fuck FFmpeg.
|
| |
|
|
| |
Because it's the most commonly used one, and trivial to support.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was excessively useless, and I want my time back that was needed to
explain users why they don't want to use it.
It captured the byte stream only, and even for types of streams it was
designed for (like transport streams), it was rather questionable.
As part of the removal, un-inline demux_run_on_thread() (which has only
1 call-site now), and sort of reimplement --stream-dump to write the
data directly instead of using the removed capture code.
(--stream-dump is also very useless, and I struggled coming up with an
explanation for it in the manpage.)
|
| |
|
|
|
|
|
|
|
|
| |
"drop-frame-count" -> "decoder-frame-drop-count"
"vo-drop-frame-count" -> "frame-drop-count"
This gets rid of the backwards "drop-frame" part in the name.
Maybe calling the new property "frame-drops" would be better, but there
are already a bunch of similar properties that end in "-count".
|
| |
|
|
|
| |
Same deal as previous commit, except this time we just readd it as lone
global option, and read it directly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vo_opengl used to have it as sub-option, which made it very hard to pass
down option values to backends in a generic way (even if these options
were completely backend-specific). For --opengl-dcomposition we used a
VOFLAG to deal with this. Fortunately, sub-options are gone, and we can
just add it as global option.
Move the option to context_angle.c and add it as global option. I
thought about adding a mechanism to let backends declare options, which
would get magically picked up my m_config instead of having to add them
to the global option list manually (similar to VO vo_driver.options),
but decided against this complexity just for 1 or 2 backends. Likewise,
it could have been added as a single option to avoid the boilerplate of
an option struct, but then again there are probably going to be more
angle suboptions, and it's cleaner.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Scale the window by the assumed DPI scaling factor, using 96 DPI as
base. For example, a screen that reports 192 DPI is assumed to have a
DPI scale factor 2. The window will then be created with twice the size.
For robustness reasons, we accept only integer DPI scales between 1 and
9. We also error out if the X and Y scales are very different, as this
most likely indicates a multiscreen system with botched size reporting.
I'm not sure if reading the X server's DPI is such a good idea - maybe
the Xrdb "Xft.dpi" value should be used instead. The current method
follows what xdpyinfo does.
This can be disabled with --hidpi-window-scale=no.
|
| | |
|
| |
|
|
|
| |
Only simple selection works now. Using "-" to terminate codec selection
remains in the code (might get undeprecated).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
our constrainFrameRect prevents our window from positioning itself ontop
of the menubar, which is unwanted for a fullscreen window. this always
positioned our window vertically at -22/-23pt when going into fullscreen
because of the menubar. this bug doesn't show on newer versions of OS X
since the various flags we set force the window position. on OS X 10.9
though the fullscreen window was shifted 22pt downwards. even though
this bug doesn't show on newer OS X versions, it should still be fixed
for a possible behaviour changes in future version.
Fixes #4044
|
| |
|
|
|
|
|
|
|
|
|
| |
everytime we switched to a new video file a new displaylink was
initialised and started, but the old one was not stopped and released
beforehand. this lead to several displaylink callback calls per swap,
depending on how many files were switched beforehand. moving the
displaylink init call to the cocoa init functions will ever only init
one displaylink.
Fixes #4031
|
| |
|
|
|
|
| |
we are calling the method on a NSWindow object that may not respond to
that call, since its a method of MpvVideoWindow. add the method to our
protocol and rename that protocol to reflect the change.
|
| |
|
|
|
|
|
|
|
|
|
| |
in some circumstances cocoa isn't able to enter or exit fullscreen but
we still set window sizes and flags accordingly. this leaves us in a
hanging state between fullscreen and window. it also prevents the
toggleFullscreen method and its events to work properly afterwards. in
that state it's impossible to enter or exit this 'semi-fullscreen'.
add a proper fallback to recover from this state.
Fixes #4035
|
| |
|
|
|
|
| |
a combination of starting from bundle and fullscreen used the standard
window size (960x480) from the pseudo GUI instead of the wanted video
size.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Disabling cache readahead by default until at least 1 track is selected
is mainly for external files and such, where you don't want them to use
up resources until they're actually used.
It doesn't make sense to disable the cache for the demuxer opened for
prefetch. Also, it's fine to let it do that for the main file too (doing
or not doing it is of little consequence). That saves us from having to
distinguish them.
|
| |
|
|
| |
Seems like quite an important/interesting case?
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Since for mpv CLI, the player state is a singleton, full prefetching is
a bit tricky. We do it only on the demuxer layer.
The implementation reuses the old "open thread". This means there is
significant potential for regressions even if the new option is not
used. This is made worse by the fact that I barely tested this code.
The generic mpctx_run_reentrant() wrapper is also removed - this was its
only user, and its remains become part of the new implementation.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
As preparation for file prefetching, we basically have to get rid of
using mpctx->playback_abort for the main demuxer (i.e. the thing that
can be prefetched). It can't be changed on a running demuxer, and always
using the same cancel handle would either mean aborting playback would
also abort prefetching, or that playback can't be aborted anymore.
Make this more flexible with some refactoring.
Thi is a quite shitty solution if you ask me, but YOLO.
|
| |
|
|
|
| |
In particular, move demux_set_ts_offset() out of the loader thread.
There's no discernible reason for that, probably.
|
| |
|
|
| |
Found those useful.
|
| |
|
|
|
|
|
|
|
| |
Apparently you set the native sample rate when passing through AC3.
This fixes passthrough with 44100 Hz AC3.
Avoid opening a decoder for this and only open the parser. (Hopefully
DTS will also support this some time in the future or so - having to
open a decoder just to get the profile is dumb.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the only way to detect the API is by a version check, this had to
wait until the patches were actually pushed to FFmpeg git (which now
happened).
Since this does not include the new magic GPU memcpy libavutil function
yet, the new vaapi code would be slower if copy mode (like vaapi-copy)
is used. This would be quite bad to use by default, so check for the
function, and if not present, disable the new vaapi code. This
effectively disables it by default on FFmpeg.
(We assume that if the new GPU memcpy exists, vaapi's AVHWFramesContext
implementation will use it.)
|
| |
|
|
| |
Fixes vf_vavpp crashing with the new vaapi decode API.
|
| |
|
|
|
|
|
| |
libavutil does this for us. Although the new vaapi decode API does not
strictly introduce or even need av_image_copy_uc_from(), it's implied
that it will be present if the new decode API is present - even if it's
not, we can't use our own SSE code with it anyway.
|
| |
|
|
|
|
|
|
|
|
|
| |
Introduce the --opengl-hwdec-interop option, which replaces
--hwdec-preload. The new option allows explicit selection of the interop
backend.
This is relatively complex, and I would have preferred not to add this,
but it's probably useful to debug certain problems. In exchange, the
"new" option documents that pretty much any but the simplest use of it
will not be forward compatible.
|
| |
|
|
|
|
|
|
| |
Replace the old code, that played games to evade thread-safety issues,
with newer thread-safe option access functions.
This also means mp_opengl_create() doesn't need to cache the hwdec
settings anymore. (They're applied in mpv_opengl_cb_init_gl() instead.)
|
| |
|
|
|
|
|
|
|
|
|
| |
Tried to decode a High 4:2:2 file, since libavcodec code seemed to
indicate that it's supported. Well, it decodes to garbage.
I couldn't find out why ffmpeg.c actually appears to reject this
correctly. The API seems to be fine with, just that the output is
garbage.
Add a hack for now.
|
| |
|
|
|
|
|
|
|
|
| |
Successful decoding of a frame resets ctx->hwdec_fail_count to 0 - which
us ok, but prevents fallback if it fails if --vd-lavc-software-fallback
is set to something higher than 1.
Just fail it immediately, since failing here always indicates some real
error (or OOM), not e.g. a video parsing error or such, which we try to
tolerate via the error counter.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the libavutil vdpau frame allocation code instead of our own "old"
code. This also uses its code for copying a video surface to normal
memory (used by vdpau-copy).
Since vdpau doesn't really have an internal pixel format, 4:2:0 can be
accessed as both nv12 and yuv420p - and libavutil prefers to report
yuv420p. The OpenGL interop has to be adjusted accordingly.
Preemption is a potential problem, but it doesn't break it more than it
already is.
This requires a bug fix to FFmpeg's vdpau code, or vdpau-copy (as well
as taking screenshots) will fail. Libav has fixed this bug ages ago.
|
| |
|
|
|
|
|
|
|
|
| |
In a way it can be reused. For now, sw_format and initial_pool_size
determination are still vaapi-specific. I'm hoping this can be eventally
moved to libavcodec in some way. Checking the supported_formats array is
not really vaapi-specific, and could be moved to the generic code path
too, but for now it would make things more complex.
hw_cuda.c can't use this, but hw_vdpau.c will in the following commit.
|
| |
|
|
| |
Fixes #4045.
|
| |
|
|
|
|
| |
Should have done this a long time ago.
d3d.c remains as it is, because it's just a bunch of helper functions.
|
| |
|
|
| |
Messy mess. Unsure whether this will be resolved properly in FFmpeg.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even though the title list code was copied from FFmpeg/libbluray,
I didn't check that mpv used 0-based title indexing.
$ mpv bd://1 --bluray-device=. --msg-level=bd=v
[bd] Opening bd://
[bd] List of available titles:
[bd] idx: 1 duration: 00:00:36 (playlist: 00000.mpls)
[bd] idx: 2 duration: 01:31:30 (playlist: 00001.mpls)
[bd] idx: 3 duration: 00:00:50 (playlist: 00003.mpls)
bd://1 actually opens idx 2 from the list, not 1.
bd://mpls/1 opens playlist 00001.mpls as expected.
With this commit:
$ mpv bd://1 --bluray-device=. --msg-level=bd=v
[bd] Opening bd://
[bd] List of available titles:
[bd] idx: 0 duration: 00:00:36 (playlist: 00000.mpls)
[bd] idx: 1 duration: 01:31:30 (playlist: 00001.mpls)
[bd] idx: 2 duration: 00:00:50 (playlist: 00003.mpls)
should play the expected idx 1.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Requires a bunch of hacks:
- we access AVFilterLink.hw_frames_ctx. This is not a public API in
FFmpeg and Libav. Newer FFmpeg provides an accessor
(av_buffersink_get_hw_frames_ctx), but it's not available in Libav or
the current FFmpeg release or Libav. We need this value after filter
graph creation, so We have no choice but to access this.
One alternative is making filter creation and format negotiation
fully lazy (i.e. delay it and do it as filters are output), but this
would be a huge change.
So for now, we knowingly violate FFmpeg's and Libav's ABI and API
constraints because they don't provide anything better.
On newer FFmpeg, we use the (quite ugly) accessor, though.
- mp_image_params doesn't (and can't) have a field for the frames
context AVBufferRef. So we pass it via vf_set_proto_frame(), and even
more hacks.
- if a filter needs a hw context, but we haven't created one yet
(because normally we create them lazily), it will fail at init.
- we allow any hw format now, although this could go horrible wrong.
Why all this effort? We could move hw deinterlacing filters etc. to
FFmpeg, which is a very worthy goal.
|
| |
|
|
|
|
| |
Instead of using the awful older "API" that passed the parameters
formatted as string. AVBufferSrcParameters is also a prerequisite for
hardware frame filtering support.
|
| |
|
|
|
|
|
|
|
| |
Because it allows easier testing of filters + hwdec.
Make the texture setup code a bit more generic so it doesn't get too
much of a mess. We also use the GL renderer utility function
gl_find_unorm_format(), which saves us additional work with OpenGL's
semi-redundant format specifiers.
|
| |
|
|
| |
This was partially done. Strangely it worked anyway.
|
| |
|
|
| |
So we can use it for filtering later.
|
| |
|
|
| |
This makes "generic" interaction with libav* components easier.
|
| | |
|
| |
|
|
| |
Just in case.
|
| |
|
|
|
|
|
|
| |
Can break things quite badly.
Example: reloading a plugin linked against GTK 3.x can cause a segfault
if you call dlclose() on it. According to GTK developers, unloading the
GTK library is unsupported.
|
| |
|
|
|
|
|
|
| |
Give scripting backends a proper name, instead of calling everything
"scripts".
Log client exit directly in client.c, as that is more general (doesn't
change actual output).
|
| |
|
|
|
|
|
|
|
|
|
| |
If hardware decoding is enabled (via --hwdec anything), the player was
printing an informational message that software decdoing is used.
Basically, this confuses users, because they think there is a problem or
such. Just disable the message, it's semi-useless anyway.
This was suggested on IRC, after yet another user was asking why this
message was shown (with a follow up discussion which CPUs can decode
what kind of video codecs).
|
| |
|
|
| |
Pointless now.
|
| |
|
|
|
|
|
| |
EGL rendering + new decode API didn't work due to a certain libva bug
with sort-of legacy API use hitting again. It will report the wrong
vaapi pixel format. It's old code and always nv12 anyway, so stop
worrying about it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are going to be users who have a Mesa installation which do not
support 10 bit, but a GPU which can decode to 10 bit. So it's probably
better not to hardcode whether it is supported.
Introduce a more general way to signal supported formats from renderer
to decoder. Obviously this is imperfect, because it still isn't part of
proper format negotation (for example, what if there's a vavpp filter,
which accepts anything). Still slightly better than before.
I don't know any way to probe for vaapi dmabuf/EGL dmabuf support
properly (in particular testing specific formats, not just general
availability). So we stay with the current approach and try to create
and map dummy surfaces on init to probe for support. Overdo it and check
all formats that AVHWFramesConstraints reports, instead of only NV12 and
P010 surfaces.
Since we can support unknown formats now, add explicitly checks to the
EGL/dmabuf mapper code to reject unsupported formats. I also noticed
that libavutil signals support for RGB0/BGR0, but couldn't get it to
work. Remove the DRM formats that are unused/didn't work the way I tried
to use them.
With this, 10 bit decoding + rendering should work, provided you have
a capable CPU and a patched Mesa. The required Mesa patch adds support
for the R16 and GR32 formats. It was sent by a Kodi developer to the
Mesa developer mailing list and was not accepted yet.
|
| |
|
|
|
|
| |
For convenience. Since we still have code that works even if creating a
AVHWDeviceContext fails, failure is ignored. (Although currently, it
succeeds creation even with the stale/abandoned vdpau wrapper driver.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Application of options in the default section is "delayed" until the
whole config file is read in order to allow profile forward references.
This was run at the end of parsing a config file - but because of
"include" options, this means it's not always called at the end of the
main config file.
Use the recursion counter to prevent it from being processed after each
"include" option. This also gets rid of the resulting unintended
infinite recursion (which eventually stopped and failed loading the
config file) due to m_config_finish_default_profile() processing the
"include" option again.
Fixes #4024.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For surfaces allocated by libavutil, we assume that the sw_format (i.e.
in hw_subfmt in mp_image_params) is always correct. The API guarantees
that it explicitly sets the equivalent vaapi format on surface
allocation.
For surfaces allocated by mpv's old vaapi code, we explicitly retrieve
the format right after decoding. Unless the driver magically changes the
format asynchronously, it will still be correct once the surface reaches
the renderer.
In both cases, checking the format again is obviously redundant. In
addition, it doesn't require us to maintain a libva fourcc <-> mpfmt
table and the va_fourcc_to_imgfmt() function. This also unbreaks 10 bit
rendering support (still disabled by default).
|
| |
|
|
| |
Bad idea to call a component "pixel" - that's true only for the Y plane.
|
| |
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This basically reuses the scripting infrastructure.
Note that this needs to be explicitly enabled at compilation. For one,
enabling export for certain symbols from an executable seems to be quite
toolchain-specific. It might not work outside of Linux and cause random
problems within Linux.
If C plugins actually become commonly used and this approach is starting
to turn out as a problem, we can build mpv CLI as a wrapper for libmpv,
which would remove the requirement that plugins pick up host symbols.
I'm being lazy, so implementation/documentation are parked in existing
files, even if that stuff doesn't necessarily belong there. Sue me, or
better send patches.
|
| |
|
|
|
|
|
|
|
| |
We have to perform some silly acrobatics to make the playback_thread()
exit, as the mpv_command() will error out with MPV_ERROR_UNINITIALIZED.
Test case: mpv_terminate_destroy(mpv_create())
Reported by a user on IRC.
|
| | |
|
| |
|
|
|
| |
Mismatches between header file symbol visibility in FFmpeg and Libav.
Again.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This does not work, because Mesa has no support for the proposed
DRM_FORMAT_R16 and DRM_FORMAT_GR16 formats. It's also untested of
course.
As long as video/decode/vaapi.c doesn't hand down P010 surfaces, this is
fine anyway.
This can be tested by removing the code that disables P010 output:
diff --git a/video/decode/vaapi.c b/video/decode/vaapi.c
--- a/video/decode/vaapi.c
+++ b/video/decode/vaapi.c
@@ -55,13 +55,6 @@ static int init_decoder(struct lavc_ctx *ctx, int w, int h)
assert(!ctx->avctx->hw_frames_ctx);
- // If we use direct rendering, disallow 10 bit - it's probably not
- // implemented yet, and our downstream components can't deal with it.
- if (!p->own_ctx && required_sw_format != AV_PIX_FMT_NV12) {
- MP_WARN(ctx, "10 bit surfaces are currently supported.\n");
- return -1;
- }
-
|
| |
|
|
|
|
|
|
| |
Rendering support in Mesa probably doesn't exist yet. In theory it might
be possible to use VPP to convert the surfaces to 8 bit (like we do it
with dxva2/d3d11va as ANGLE doesn't support rendering 10 bit surface
either), but that too would require explicit mechanisms. This can't be
implemented either until I have a GPU with actual support.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Other hwdecs will also be able to use this (as soon as they are switched
to use AVHWFramesContext).
As an additional feature, failing to copy back the frame counts as
hardware decoding failure and can trigger fallback. This can be done
easily now, because it needs no way to communicate this from the hwaccel
glue code to the common code.
The old code is still required for the old decode API, until we either
drop or rewrite it. vo_vaapi.c's OSD code (fuck...) also uses these
surface functions to a higher degree.
|
| |
|
|
|
|
|
|
| |
mp_image_hw_download() is a libavutil wrapper added in the previous
commit. We drop our own code completely, as everything is provided by
libavutil and our helper wrapper.
This breaks the screenshot code, so that has to be adjusted as well.
|
| |
|
|
|
|
|
|
|
| |
Makes va_surface_download() call mp_image_hw_download() for
libavutil-allocated surfaces, which in turn calls
av_hwframe_transfer_data().
mp_image_hw_download() is actually not specific to vaapi, and can be
used for any hw surface allocated by libavutil.
|
| |
|
|
|
|
|
|
|
| |
Mostly affects conversion of the colorimetric parameters.
Not changing AV_FRAME_DATA_MASTERING_DISPLAY_METADATA handling - that's
too messy, as decoders typically output it for keyframes only, and would
require weird caching that can't even be done on the level of the frame
rewrapping functions.
|
| |
|
|
|
|
|
|
| |
This fixes direct rendering with hwdec_vaegl.c.
The code duplication between update_image_params() and
mp_image_copy_fields_from_av_frame() is quite annoying,
bit will have to be resolved in another commit.
|
| |
|
|
|
|
| |
AVHWDeviceContext.user_opaque is reserved to libavutil under certain
circumstances, while AVHWFramesContext.user_opaque is truly free for use
by us. It's slightly simpler too.
|
| |
|
|
|
| |
We can drop the weird acrobatics with the is_ffmpeg. We can distinguish
them directly within the vaapi check, duh.
|
| |
|
|
|
|
|
|
|
|
|
| |
Dummy out the locking around all libva calls, which in theory shouldn't
be needed anyway. Two years ago, these were added to prevent crashes
with vaapi decoding and direct rendering (vo_opengl/vo_vaapi) active.
It's not clear whether these are really needed - theory strongly points
towards no. Some developers familiar with vaapi expressed similar
thoughts. But past experience says differently. So let's try
without the locking for a while and see what happens.
|
| |
|
|
|
|
|
|
|
| |
A recent commit added code that checks some HAVE_ symbols in this file.
No config.h include was added, so they could be unavailable and break
compilation (in practice, just --hwdec=vaapi-copy would break).
Not sure how I missed this, maybe waf defined these symbols on the
compiler command line for some reason.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old API is deprecated, and libavcodec prints a warning at runtime.
The new API is a bit nicer and does many things for you, such as
managing the underlying hwaccel decoder. libavutil also provides code
for managing surfaces (we use their surface pool).
The new code does not contain any code from the original MPlayer VAAPI
patch (that was used as base for some of the vaapi code in mpv). Thus
the new code is LGPL.
The new API actually does not add any visible symbols, so the only way
to detect it is a version check. Of course, the versions overlap
between FFmpeg and Libav, which requires additional care. The new
API did not get merged into FFmpeg yet, so there's no check for
FFmpeg.
|
| |
|
|
|
|
|
|
|
|
|
| |
We usually attach some significant metadata and context to "our"
surfaces. Surfaces created by libavutil (such as we plan to do it when
using the new vaapi decode API in the following commit) don't have this
context, so e.g. copy decoding mode won't work.
Add tons of hacks to make this somehow work.
Eventually we will use libavutil's mechanisms and drop the hacks.
|
| |
|
|
| |
Preparation for the following commits.
|
| |
|
|
|
| |
vaapi.c will be reintroduced with the new code using the new libavcodec
vaapi API.
|
| |
|
|
| |
It's a quite important and fragile magic number.
|
| |
|
|
|
|
|
| |
circumvent undefined behavior when quitting in
fullscreen.
Fixes #3957
|
| |
|
|
|
|
|
|
|
|
|
|
| |
the display refresh rate can't be estimated
correctly in some cases and just increases till it
turns off display-resample. cases are
off-screen rendering (different space), mpv
being completely hidden behind another window or
the mission control view.
this utilise the unused displaylink callback to
limit the refresh rate to the actual display
refresh rate.
|
| |
|
|
| |
Fixes #2430
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This flips the y-coordinate to be consistent with
other platforms and the manual. furthermore it
fixes an unwanted behaviour of the cocoa
convertRectFromBacking method, where the x- and
y-coordinate was divided by the same factor as the
width and height instead of placing the new scaled
rectangle at the same relative position as the
original unscaled rectangle, by manually
calculating the new position.
Fixes #3867
|
| |
|
|
|
|
|
| |
Same deal as with video. Including the EOF handling.
(It would be nice if this code were not duplicated, but right now we're
not even close to unifying the audio and video code paths.)
|
| |
|
|
|
| |
There's only 1 caller now, so having it as separate function doesn't
make too much sense, and makes the code less readable, if anything.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is simpler and more robust, especially for the hwdec fallback case.
The most annoying issue is that C doesn't support multiple return values
(or sum types), so the decode call gets all awkward.
The hwdec fallback case does not need to try to produce some output
after the fallback anymore. Instead, it can use the normal "replay"
code path.
We invert the "eof" bool that vd_lavc.c used internally. The
receive_frame decoder API returns the inverse of EOF, because
returning "true" from the decode function if EOF was reached
feels awkward.
|
| |
|
|
| |
Wasn't a problem in most normal scenarios.
|
| |
|
|
|
|
| |
Usually they happen at the same time, but conflating them is still a bit
unclean and could possibly cause problems in the future. It's also
really unnecessary.
|
