Sometimes there was an immediate return on error and other times it
destroyed things before returning the error. Make this consistent
whenever something fails while we open. Also remove the destruct
function since it is completely redundant with bluray_stream_close.
Sometimes a CD can have non-audio data at the start that is not
playable. libcdio/paranoia is smart enough to already skip this, but our
calculations for when the tracks/chapters start completely fall apart.
The beginning bytes are not valid CD audio so it should just be
subtracted and ignored. This probably doesn't work if a CD somehow has
its audio tracks in a non-continuous manner with non-audio data
in between tracks at random points. There's likely not much we could do
in such a case, and probably nobody has an audio CD like that anyways.
Ref: #8322
We hit a -Wstrict-prototypes error which was fixed in the latest release
of libcdio-paranoia but openbsd is too old. We already have coverage of
this in other CIs so remove it.
The same as 04a2450aab, but now cdda is
auto detected, so disable it explicitly.
This test requires that the OS language settings be English so the
--subs-match-os-language option is actually testable. In Linux, this can
be done by just setting LANG and it always will work. For macOS and
Windows, we use the OS APIs to get the languages and let the test
proceed if we find English. Gracefully fail and skip otherwise.
Internally, mpv uses '-' as a separator for language codes like
specifying the region/variant for the language. However, the posix
environment variables for this separate using a _. Since
5009e13431, support for the _ separator
was dropped which meant that --subs-match-os-language actually didn't
work on linux/bsd at all (mac has its own separate implementation).
Instead of adding _ back to the function, it makes more sense to just
replace _ with - while we parse through the languages since this
implementation of mp_get_user_langs is the only one that separates with
_.
Notably they are exchanged between demux and decode thread. It's fine
because we know those pointers will be alive as long as avctx is alive.
And only the value may change during decoding in rare situations. Make
those pointers atomic for the sake of it.
It shouldn't change anything, except some codegen.
From https://www.gnu.org/software/libc/manual/html_node/Atomic-Types.html#Atomic-Types:
In practice, you can assume that int is atomic. You can also assume that
pointer types are atomic; that is very convenient. Both of these
assumptions are true on all of the machines that the GNU C Library
supports and on all POSIX systems we know of.
We use the ext protocol, not the wlr specific protocol. Moreover,
"zwlr_data_control_manager_v1" is an interface within the protocol, not
the protocol name itself.
Loading the file and then waiting it for it to be loaded again doesn't
need to be two separate functions. Combine it into a simple
"reload_file" so it's more readable.
This got refactored so it only loads one file at a time and not
everything in a loop. The option resetting at the end of conditional
branches is pointless.
The amount of options we have that are related track selection is insane
and touching any of this stuff is scary. Add some track selection
testing to the CI to hopefully make it slightly less scary to touch any
of that. Since trying to work in media files from some outside source
would be a pain and need to live in some repo somewhere, it's nicer to
just generate dummy files on the fly with ffmpeg during the ci runs and
use that. Obviously, the actual tests themselves could be even more
thorough (external tracks were not even considered), but this is more
than a good enough start for now.
The big libmpv test file is really actually three different tests shoved
together into one. They do all use fairly similar underlying structures,
so put the shared stuff into an inline header. There's a little bit of
duplication with regards to the main function, but it's cleaner to
separate out the tests.
mpv internally treats all string options/properties with NULL or an empty string the same way. client.h explicitly forbids MPV_FORMAT_STRING from being NULL, but in the C API, it has been working accidentally due to how strings are copied. Nevertheless, none of the APIs allow this; JavaScript, Lua, IPC, and CLI all require strings to be at least empty. We cannot pass NULL.
Furthermore, currently passing NULL causes an assertion failure in the JSON formatter, so it is clearly not intended to be used that way.
Internally, all string options default to NULL, but in this case, they should behave exactly the same as an empty string. Hence, this change is applied to the `demuxer-lavf-format` option.
Note that get_property will never return a NULL value, regardless of the internal value.
Fixes: #15840
HDR or any color-space pass-through should be opt-in, as we cannot
control the user's compositor or display. Allowing HDR signals to be
pushed by default may lead to surprising results for some users.
Additionally, for an optimal experience, this option should be paired
with the target-peak of the display.
Make the pass-through opt-in and let the user decide if they want or
need it. By default, mpv should render a safe and consistent sRGB
output. mpv's tone mapping is generally of higher quality than any
external solution.
This reverts commit 23843b4aa5.
This is not only cosmetic, but also avoids dummy get key action with
empty key. While this was allowed previously, I'm bit concerned about
Hyrum's law. But let's be strict about it.
This commit fixes current-tracks property.
Fixes: 95019fc256
Updating input-commands string list causes all commands to be rerun.
This happens during load-config-file command, so even with few commands
it is easy to amplify single command to run hundreds of times instead of
one. This causes timeouts and OOMs when specific command for example
reopens current playlist appending an item.
Also avoid even single input-commands, we want to test load-config-file
parsing and input-commands can do loadfile and trigger heavy code
paths. We don't want to mix this. Unfortunately parsing of
input-commands will not be tested.
It's unfortunate that it is implemented this way since changing it will
take time. This option should *really* be like OPT_CHOICE but with
doubles and not integers. We don't have that though and implementing it
is something for the future. Even if that was done today, this still
couldn't be switched to since setting -1 has been the effective way for
years to undo video-aspect stuff. So the approach is to just add another
special keyword for this and tell people to use that instead. Note that
setting 0 isn't deprecated since M_RANGE(0, 10) is totally fine and
would work in the future if this option type ever gets redone.
Setting this to M_RANGE(-1, 10) meant that you could pass fractional
negative values without it being an error. This is, of course, nonsense.
-1 is the only special negative value with a meaning. Error out if we
get anything else by doing some additional parsing before we send it off
to parse_double which will then restrict the range to 0, 10 with these
changes. Note that this approach requires defval to be there which is
not the most extensible thing in the world. But there's literally only
two OPT_ASPECT type options out of the hundreds we have so not a big
deal. Ideally, this type should be OPT_CHOICE but with underlying
doubles but that's too much effort to implement cleanly.
These were still set to float. For some common aspect ratios (e.g. like
4:3), the loss of precision is significant. The underlying calculations
are already done with doubles so all that needs to be done is to change
the type of the sub-property.
The error message is completely incomprehensible and also inconsistent
about whether it wants two newlines or just one after an import.
Consider this python script:
import sys
sys.stdout.write("garbage")
That passes the ruff isort check just fine. But this does not:
import sys
def fake_function():
sys.stdout.write("garbage")
fake_function()
This will fail. Why? Because there should be two newlines after imports
but only for functions. This is because of PEP8 rules about blank lines,
but this is not explained or referenced anywhere in output from the
lint. You only get a cryptic "Import block is un-sorted or un-formatted"
with some visual that isn't clear in what it's trying to communicate.
Additionally, it seems to go a bit beyond PEP8 and also will fail if you
have too many blank lines (i.e. more than 1) in certain cases if the
succeeding line isn't a function or class definition.
Furthermore consider this example:
import os
import sys
from subprocess import check_output, DEVNULL
This also fails the lint. Why? Because DEVNULL should come before
check_output. Again, the lint doesn't explain this and you're left
guessing what horrible formatting sin you committed.
Considering the amount of time I wasted trying to even understand this
and I still don't, just delete it. How are contributors supposed to
understand what this lint wants when the project's own developers were
confused by it. Please just alphabetically sort your python imports and
don't do "from foo import *".
Dudemanguy