| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Until now, we just blocked SIGPIPE globally. Fix it properly to get away
from it.
MSG_NOSIGNAL should be widely available and is part of the POSIX.1-2008
standard. But it's not available on OSX, because Apple is both evil and
retarded. Thus we continue to ignore the problem on such shitty systems.
|
|
|
|
|
|
|
|
|
|
|
| |
Interrupt video timing. This means the Cocoa event loop does not have
to up to 2 video frame durations until redrawing the frame finally has
finished.
We abuse the VO event flags for this. Eventually this should use
wait_vo() or so in the video timing wait function, but for now the
interaction this would require with the code of other VOs/backends
would cause too much of a mess.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of requiring a complicated mechanism to share the entire OpenGL
and renderer state between VO and Cocoa thread just to do the redrawing
during live-resize on the Cocoa thread, let the Cocoa thread wait on the
VO thread. This wil allow some major simplifications and cleanups in the
future.
One problem with this is that it can enter a deadlock whenever the VO
tries to sync with the Cocoa thread. To deal with this, the Cocoa thread
waits with a timeout. This can probably be improved later, though in
general this situation can always happen, unless the Cocoa thread waits
in a reentrant way.
Some other details aren't completely clean either. For example,
pending_events should be accessed atomically. This will also be fixed
later.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Will be used to make video waiting interruptible with Cocoa (see the
following commit).
One worry was that this could cause hangs if the system clock jumps
backwards. Normally we don't support such behavior, because it's
almost impossible to handle it reasonably. E.g. we would have to
change the default clock type for condition variables, which in turn
would require a custom function for creating condition variables,
or so. If the OS even supports different clocks.
But it turns out that this is no issue, because other events seem
to wakeup the wait call anyway, and mpv internal absolute times use
a monotonic clock.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This uses the OpenGL frame interpolation code, which before could be
used by vo_opengl only.
Some effort was made to make it behave like vo_opengl, for the better or
the worse. As a consequence, there is a minor duplication of code and
mechanism. Hopefully this can all be wiped as soon as the VO frame
queue/timing mechanism is cleaned up.
This also attempts to use mpv_opengl_cb_report_flip() (as called by the
API user) to determine the vsync interval. This might need refinement as
well.
(In general, we simply expect the API user to work in vsync-blocking
manner.)
|
|
|
|
|
|
|
|
|
| |
(I have no idea why there are different modes.)
Instead of risking to drop frames too early, give it some margin. Since
there are situations this could deadlock, wait with a timeout. This can
happen if e.g. the API user is refusing to render anything, or if
uninitialization is happening.
|
|
|
|
| |
Quite an oversight.
|
|
|
|
|
|
|
| |
Gives the VOs more flexibility.
gl_video.c already ignores the timing info if no interpolation is
active, so this requires no further changes.
|
|
|
|
|
|
|
| |
There is not much of a reason to have these wrappers around. Use POSIX
standard functions directly, and use a separate utility function to take
care of the timespec calculations. (Course POSIX for using this weird
format for time values.)
|
|
|
|
|
| |
The main reason for this was compatibility; but some associated problems
have been solved in the previous commit.
|
|
|
|
|
|
|
|
|
|
| |
As usual, we prefer plain C11 names and semantics, and have to emulate
them if C11 atomics are not available.
For the non-atomic fallback (which is just there to make code compile in
situations the atomic property is not overly important), we require a
gross hack to make the generic macros work without using compiler-
specific extensions.
|
| |
|
|
|
|
|
| |
The first one (for VOCTRL_GET_DISPLAY_FPS) could have led to undefined
behavior if the FPS was unknown. The second is for general symmetry.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OpenSSL and GnuTLS are still causing this problem (although FFmpeg could
be blamed as well - but not really). In particular, it was happening to
libmpv users and in cases the pseudo-gui profile is used. This was
because all signal handling is in the terminal code, so if terminal is
disabled, it won't be set. This was obviously a questionable shortcut.
Avoid further problems by always blocking the signal. This is done even
for libmpv, despite our policy of not messing with global state.
Explicitly document this in the libmpv docs. It turns out that a version
bump to 1.17 was forgotten for the addition of MPV_FORMAT_BYTE_ARRAY, so
document that change as part of 1.16.
|
| |
|
| |
|
|
|
|
|
| |
When --no-video is set, the ytdl-format is set to "bestaudio/best". This
wasn't documented in the man page yet.
|
|
|
|
| |
We don't allow tabs in normal source code.
|
|
|
|
|
|
|
| |
It's useless, and creates a bogus warning in subprocess-posix.c.
Since I don't know which compilers might have it by default, just change
it to -Wno-redundant-decls.
|
|
|
|
| |
It shouldn't be used, but it's still in the repo because I say so.
|
|
|
|
| |
Fixes #1927.
|
|
|
|
|
| |
This has the side-effect that now all encoding-profiles.conf files are
loaded. It's not clear if not doing this was intended or not.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mp_find_config_file() will print the filename lookup and its result in
verbose mode. This is wanted, but gets inconvenient when it is done for
every playlist entry (for resuming).
Lookup the watch_later subdir only once and cache the result instead.
This drops the logic for loading the resume file from other locations,
which should generally be unnecessary, though might lead to confusion if
the user has mixed old and new config paths (which the user shouldn't).
Also add a mp_find_user_config_file() function for a more
straightforward and reliable way to get actual local configpaths,
instead of possibly global and unwritable locations.
Also, for symmetry, check the resume option in mp_load_playback_resume()
just like mp_check_playlist_resume() does.
|
|
|
|
| |
These device options can be NULL, and NULL can't be passed for %s.
|
|
|
|
|
| |
Instead of bstr. Most callers of this function do not need bstr. The
bstr version of this function is now mp_path_join_bstr().
|
|
|
|
|
| |
The compatibility code and the deprecation warning were at least in
releases 0.8 and 0.9 - time to get rid of them.
|
|
|
|
|
|
|
|
|
|
|
| |
Share most of the implementation of config file lookup between
mp_find_all_config_files() and mp_find_config_file().
Also move the check for config path overrides to mp_get_platform_path()
directly. From the point of view of config file lookup, this is a bit
stupid, but on the other hand increases consistency, as user path
resolution exposes the mp_get_platform_path() functionality directly to
the user.
|
|
|
|
|
|
|
|
|
| |
Now among other things panscan can be changed during playback.
Unfortunately, it flickers. The issue is that reconfig() clears the
framebuffer. Removing the clearing shows that the "unused" parts of
the picture are not cleared - even though OSD could render there. As
such, this is a separate issue.
|
|
|
|
|
|
| |
When running with --panscan=1, this could crash - because the current
frame was reduced in size each time the image was redrawn, which would
result in a failed assertion the second time it's drawn.
|
|
|
|
| |
Prevents the OSC from showing up on start on Cocoa.
|
|
|
|
|
|
|
| |
This creates the window before the first file is loaded. This was
requested a bunch of times, but on the other hand a change to make this
behavior the default was reverted some time ago, because other users
hated it.
|
|
|
|
|
|
| |
Drop mp_chmap_diff() (which is unused too now), and implement
mp_chmap_diffn() in a slightly simpler way. (Too bad there is no
standard function for counting set bits.)
|
|
|
|
| |
It's unsued now.
|
|
|
|
| |
Useful for debugging cases when no standard orders are used.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of somehow having 4 different cases with each their own weight,
do it with a single function that decides which channel layout is the
better fallback.
This is simpler, and also introduces new (fixed) semantics. The new test
added to test/chmap_sel.c actually works now. This is a mixed case with
no perfect upmix or downmix, but the better choice is the one which
loses the least channels from the original layout.
One test also changes. If the input is 7.1(wide-side), and the available
layouts are 7.1 and 5.1(side), the latter is now chosen instead of the
former. This makes sense: both layouts contain 6 out of 8 channels from
the original layout, but the 5.1(side) one is smaller. This follows the
general logic. The 7.1 layout has FLC/RLC speakers instead of BL/BR,
and judging by the names, "front left center" is completely different
from "back left". If these should be exchangeable, a separate exception
would have to be added.
|
| |
|
| |
|
| |
|
|
|
|
| |
This made no sense and always evaluated to true.
|
|
|
|
|
|
| |
Reuse MP_SPEAKER_ID_NA for this. If all mp_chmap entries are set to NA,
the channel layout has special "unknown channel layout" semantics, which
are used to deal with some corner cases.
|
|
|
|
|
| |
Remove the requirement from mp_chmap that speaker entries must be
unique. Use this to get rid of all the redundant NA speaker IDs.
|
|
|
|
|
|
|
|
| |
The client API (libmpv) and encoding (--o) have slightly different
defaults from the command line player. Instead of doing a bunch of calls
to set the options explicitly, use profiles. This is simpler and has the
advantage that they can be listed on command line (instead of possibly
forcing the user to find and read the code to know all the details).
|
|
|
|
| |
Is simpler and avoids exposing profile structs to a degree.
|
| |
|
|
|
|
|
| |
While mpv has no internal equivalent representation, they can still be
used as physical CoreAudio formats. Thus this label is confusing.
|
|
|
|
|
| |
Should prevent the EDL parser from tripping over = and , in the
URL.
|
|
|
|
| |
(I won't do this, but someone else seeing this might.)
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes, ALSA will return channel layouts with padded channels (NA
speakers). Use them instead of failing.
This still includes the old "braindeath" code to retry with a layout
without NA channels. This might be helpful for performance, and also the
padded channel layout string looks confusing.
To be fair, I have not encountered a case yet which would really need
this, and for which the old "braindeath" code did not fix it.
|
|
|
|
|
| |
One side effect is that the warning about too many channels goes away,
and is replaced with printing the ALSA channel map as "unknown".
|
| |
|
| |
|
|
|
|
|
| |
It seems if the format was already set, setting the same format will
not cause a property change.
|
|
|
|
|
|
|
|
|
|
|
| |
volatile barely means anything.
The polling is kind of bad too, but relatively harmless as device
opening/closing is a rare event, and the format change is not expected
to take long.
Remove the pointless talloc call too (must have been a leftover
from previous refactoring).
|
|
|
|
| |
PCM is digital too.
|
| |
|
|
|
|
|
|
| |
No reason to keep them separate. It's an artifact from the old
ao_coreaudio.c, which kept usage of two different APIs in the same file.
Removes a forward reference too.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should fix some crashes due to dangling pointers.
The problem was that with_cocoa_lock_on_main_thread() is asynchronous.
It will not wait until it is finished. In the uninit case, this means
the VO could be deallocated and destroyed while cocoa was still running
uninit code.
So simply wait until it is done by using dispatch_sync(). There were
concerns that this could introduce a deadlock by the main thread trying
to wait for something on the VO thread. But from what I can see, this
never happens, and even if it does, it would crash anyway since the VO
is already gone.
One remaining worry is the video_resize_redraw_callback. From what I can
see, it still can mess things up, and will need a more elaborate fix.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of trying to use af_format_conversion_score() (which tries to be
all kinds of clever), just compare the raw bits as a quality measure. Do
this because otherwise, weird formats like padded 24 bit formats will be
excluded, even though they might be the highest precision formats for
some hardware.
This means that for now, the user would have to check whether the format
is usable at all before calling ca_asbd_is_better(). But since this is
currently only used for ao_coreaudio.c and for the physical format, it
doesn't matter.
If coreaudio-exclusive should get PCM support, the best would be to
revert this change, and to add support for 24 bit formats directly.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some time ago, a mechanism was added for automatically removing PCM-only
filters if the input format is spdif.
This could cause an infinite loop if the AO did not support spdif, but
was falling back to some PCM format. Then this code tried to remove the
last filter, which is a dummy filter for receiving and queuing filter
output. af_remove() simply fails gracefully in this case, so this
happens over and over again.
Fix by explicitly checking whether the filter to remove is a dummy
filter. (af_remove() also fails only if the dummy filters are attempted
to be removed - checking this directly is simpler.)
|
|
|
|
|
| |
These ( ) were probably not removed when the format constants were
changed from defines to an enum.
|
|
|
|
|
|
|
|
|
|
| |
Move all of the channel map retrieval/negotiation code to a separate
file. This will (probably) be helpful when extending
ao_coreaudio_exclusive.c.
Nothing else changes, other than some minor cosmetics and renaming,
and changing some details for decoupling it from the ao_coreaudio.c
internals.
|
|
|
|
|
| |
Instead, apply a trick to make the caller allocate enough space on the
stack.
|
|
|
|
|
|
|