| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
It is not defined in the current cygwin release.
|
|
|
|
|
| |
Some IEC958 flags we use have been introduced in 2008, which makes
compilation fail on older systems.
|
|
|
|
|
|
| |
Also clarify the statement about what we expect to happen by default.
It's well possible that distros at some point will fix their ALSA
configuration, and e.g. enable the upmix plugin by default.
|
|
|
|
|
|
| |
Padding with spaces is very useless for OSD (because most fonts are
variable width), but it's good when using it on the terminal, e.g. for
reproducing the default terminal status line.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should work well with most audio APIs, except ALSA. A long-winded
explanation is provided how to make ALSA multichannel output work.
All other AOs should have no such problems. Of course it's possible
that previously unknown issues arise, because I assume that enabling
multichannel audio is actually relatively rare.
This also disables codec downmix by default, which could change the
audio output due to different mixing in the codec and libavresample.
Fixes #1313.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The "old" method (before the ALSA channel map API) used device aliases
like "surround51" to set the channel layout. The "interesting" part was
that these devices usually redirect to a hardware device. This means
playing stereo would lead you to the "default" device (dmix), while e.g.
5.1 to "surround51", which automatically takes care of the fact that
dmix can't do 5.1.
This is pretty much nonsense, though. It shouldn't depend on the damn
input media file whether the player is going to use shared access (dmix)
or exclusive access (direct hw device).
As a consequence, by default ao_alsa will do only what dmix can do. If
the user actually wants multichannel, he has to select a suitable hw
device with --audio-device. From there on, the correct speaker mapping
will be ensured via the channel mapping API.
The change is preparation for making multichannel output the default (as
far as supported by the audio output API). Of the common APIs, only ALSA
messes up beyond repair, so I feel like this change is needed.
On ancient alsa-lib versions, only stereo and mono can be played with
this branch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dmix reports channel layouts it doesn't support. The rest of the
technical part of the story is in the code comment.
This seems to be the only reasonable way to fallback from trying to
initialize certain devices (like dmix) with multichannel audio. We could
probably add support for such padding channels to our audio chain or to
ao_alsa itself, but this would probably be much more work than this
commit.
What dmix does is probably a bug. I've tried to report it to ALSA. Thay
have a link on their website to a bug tracker, but it's a dead link, and
has been for years. I've posted to alsa-devel, but received no reply.
I'm thus assuming this absolutely retarded behavior is by design, and
nothing will happen to improve upon it.
I'm considering sending Lennart Poettering a "thank you" email, because
with PulseAudio, multichannel audio just works (although some other
things just don't work).
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this commit, this was defined to trigger undefined behavior. This
was nice because it required less code; but on the other hand, Lua as
well as IPC support had to check these things manually. Do it directly
in the API to avoid code duplication, and to make the API more robust.
(The total code size still grows, though...)
Since all of the failure cases were originally meant to ruin things
forever, there is no way to return error codes. So just print the
errors.
|
|
|
|
|
|
| |
Apparently, the atomics were used by the win32 subprocess code. This
code was moved to a separate file, but the atomics.h include was
forgotten.
|
|
|
|
| |
hopefully this fixes #1350
|
|
|
|
|
|
|
|
|
| |
The message was missing a '\n', so it was merged with the next line,
which also typically caused it not to be printed with the colors for
warnings.
Print the full new path in the warning message. (Normally, cfg should
never be NULL, so accounting for this case is just for robustness.)
|
|
|
|
|
|
|
|
| |
Obscure feature, and I've never heard of anyone using it.
The anaglyph effects can be reproduced with vf_stereo3d. The only thing
that can't be reproduced with it is "quadbuffer", which requires special
and expensive hardware.
|
|
|
|
|
|
|
|
|
|
|
|
| |
- --lua and --lua-opts change to --script and --script-opts
- 'lua' default script dirs change to 'scripts'
- DOCS updated
- 'lua-settings' dir was _not_ modified
The old lua-based names/dirs still work, but display a warning.
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
| |
Fixes #1347.
The previous commit actually fixes the crash.
|
|
|
|
| |
Avoids a crash if allocation fails.
|
| |
|
|
|
|
| |
The ctx->pic check must uninitialize the decoder.
|
|
|
|
|
| |
Or rather, the only reason av_buffer_create() can fail is a malloc
failure.
|
|
|
|
|
|
|
|
|
| |
This was requested.
It seems libdvdread can't get the duration for titlesets other than the
currently opened title. The data structures contain dangling pointers
for these, and MPlayer works this around by opening every title
separately for the purpose of dumping the title list.
|
|
|
|
|
|
| |
Apparently, we treat different tracks as titles, so returning the number
of titles (which is user-visible as "disc-titles" property) is
completely misguided.
|
|
|
|
|
|
|
| |
Apparently, libdvdnav always reports a last chapter that points to the
exact end of the title. This is useless for us.
Again, same possible caveats as with the previous commit.
|
|
|
|
|
|
|
| |
This way, chapter 0 will always point to the start of the title.
At least this is the intention; it's likely that DVDs as well as
libdvdnav do random things that lead to random results.
|
|
|
|
|
|
|
|
| |
GNU sed and BSD sed don't share the same options for editing files in-place,
so a workaround is needed.
The most simple way is to use a pure python implementation of applying the
changes.
|
| |
|
|
|
|
|
|
| |
Whatever.
Fixes #1281.
|
|
|
|
|
|
|
|
| |
The --keep-open behavior was recently changed to act only on the last
file due to user requests (see commit 735a9c39). But the old behavior
was useful too, so bring it back as an additional mode.
Fixes #1332 (or rather, should help with it).
|
|
|
|
| |
Editing mistake. Oops.
|
|
|
|
| |
Fixes #1337.
|
|
|
|
| |
Unrecommend mingw-w64-cmake, point out MXE host requirements.
|
|
|
|
| |
Fixes #1192.
|
|
|
|
| |
It's confusing. Whether the new behavior is less confusing... whatever.
|
|
|
|
|
|
|
|
| |
Do this by automatically adding the option, if the aliased option name
also has a "no-..." variant.
Could be easier by manually adding "no-..." variants to the option list,
but this seems better because you can't just forget it.
|
|
|
|
| |
The # from the IRC channel made it appear as a headline.
|
|
|
|
|
| |
This fixes a hang with the VirtualBox OpenGL drivers. It might help
with #1325 as well.
|
|
|
|
| |
Fixes #1331.
|
| |
|
|
|
|
| |
Meh.
|
|
|
|
| |
"script_binding name ..." just crashed it. Oops.
|
|
|
|
|
| |
This wasn't done, so the chapter marks of the previous file were
visible. It's harmless, but looks unpolished, so fix it.
|
|
|
|
| |
Instead of "(unavailable)".
|
|
|
|
|
|
|
|
| |
MP_NOPTS_VALUE (basically INT64_MIN) is basically an special timestamp
value that means "unset" or "unknown". Its exact value is internal, and
should never be returned or interpreted by any API.
So return "no" instead (what is also what the parser accepts).
|
|
|
|
|
|
|
|
|
| |
Commit d38bc531 is incorrect: the 50ms queue-ahead value and the flip
queue offset have different functions. The latter is about calling
flip_page in advance, so the change attempted to show video frames 50ms
in advance on all VOs.
The change was for vo_opengl_cb, but that can be handled differently.
|
|
|
|
| |
Yes, it's redundant with events.
|
|
|
|
|
|
|
|
|
|
| |
These actually are harmless. Even if the data the reader is working on
is essentially random, it's treated like untrusted input data, so there
should be no harm.
But it upsets tools like valgrind.
Probably fixes #1329.
|
|
|
|
|
| |
Also, don't use the "hw" device, but "plughw". ALSA docs say never to
use "hw".
|
|
|
|
|
|
|
| |
I thought setSamples() was some funky abstraction to set the number of
components, but it's actually something else.
Also fix the include paths.
|
|
|
|
| |
Can happen on Windows, I suppose.
|
|
|
|
| |
It was missing an indentation in some cases.
|
|
|
|
|
|
|
|
|
|
|
| |
In theory, vo_opengl supports operation without framebuffers. But this
has been broken for a while now (commit cc00b3ff is a contender). It
crashed because it unconditionally called gl->BindFramebuffer() (which
is NULL if framebuffers are missing).
Since this function is actually only called to set the default
framebuffer, the simplest way to deal with this is to provide a dummy
function, insteas of uglifying the code with additional if branches.
|
|
|
|
| |
Let's see who complains...
|
|
|
|
|
|
| |
The result isn't quite what I imagined, because the A-point is never
marked as a seek point (so you can't jump between A and B), but it's
still slightly better than before.
|
|
|
|
|
|
|
| |
I think that's expected; mpv shouldn't draw anything while no video is
active. This doesn't blend transparently, though.
Also document the vo_opengl_cb thing.
|
|
|
|
|
| |
This mainly affects the black bars that are drawn if the window and
video aspect ratios mismatch.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After being bitten by this, I decided that this mostly unnecessary
requirement sucks.
Allowing this makes it easier to use libmpv, because it can be set after
mpv_initialize(). The latest reasonable time an API user can set this
variable is before actually loading a file.
The previous 2 commits make sure nothing bad can happen if the option is
changed at runtime even if a VO is active. The Cocoa backend should be
fine and doesn't need a change.
|
|
|
|
| |
See previous and next commit.
|
|
|
|
| |
For the purpose of making "--wid" setable at any time.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds API to libmpv that lets host applications use the mpv opengl
renderer. This is a more flexible (and possibly more portable) option to
foreign window embedding (via --wid).
This assumes that methods like context sharing and multithreaded OpenGL
rendering are infeasible, and that a way is needed to integrate it with
an application that uses a single thread to render everything.
Add an example that does this with QtQuick/qml. The example is
relatively lazy, but still shows how relatively simple the integration
is. The FBO indirection could probably be avoided, but would require
more work (and would probably lead to worse QtQuick integration, because
it would have to ignore transformations like rotation).
Because this makes mpv directly use the host application's OpenGL
context, there is no platform specific code involved in mpv, except
for hw decoding interop.
main.qml is derived from some Qt example.
The following things are still missing:
- a way to do better video timing
- expose GL renderer options, allow changing them at runtime
- support for color equalizer controls
- support for screenshots
|
|
|
|
|
|
| |
A small refactor; shouldn't change any behavior.
Do this so immediate display can be achieved.
|
| |
|
|
|
|
| |
Fixes #1324.
|
|
|
|
|
|
| |
fixes #1323
Doesn't leak unless we switch video tracks on and off while in fullscreen.
|
|
|
|
|
| |
This is requested oftem, but I don't know if it should be an actual
default binding.
|
|
|
|
|
|
|
|
|
|
| |
The most awesome codec, not.
The actual code for svq3 is actually just the part that checks for
MKV_V_QUICKTIME (no other QT-muxed codecs are supported). The rest is
minor refactoring, that actually improves the code in general.
This is just enough to support the 2 svq3-in-mkv sample files I have.
|
|
|
|
|
|
| |
Still supported, but obviously untested.
You shouldn't use this option anyway.
|
|
|
|
|
|
|
|
| |
There were complaints that a chapter seek past the last chapter was
quitting the player. Change the behavior to what is expected: the last
frame.
If no chapters are available, this still does nothing.
|
|
|
|
|
|
| |
I guess most problems with it have been fixed.
It's still slower than necessary, though.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not all filter sizes the shaders could handle were in the filter_sizes
list. The shader can handle any multiple of 4 (the sizes 2 and 6 are
special-cased to keep it simple).
Add all possible filter sizes, up to 64. 64 is ridiculously high anyway.
Most of the larger filter sizes are completely useless for upscaling,
but help with the fancy-downscaling option. (Although it would still be
more efficient to use cascaded scalers to handle downscaling better.)
I considered doing something less stupid than the hardcoded array, but
it seems this is still the simplest solution.
|
|
|
|
|
|
|
|
|
|
|
< |