Although the libraries we use for resampling (libavresample and
libswresample) do not support changing sampelrate on the fly, this makes
it easier to make sure no audio buffers are implicitly dropped. In fact,
this commit adds additional code to drain the resampler explicitly.
Changing speed twice without feeding audio in-between made it crash
with libavresample inc ertain cases (libswresample is fine). This is
probably a libavresample bug. Hopefully this will be fixed, and also I
attempted to workaround the situation that crashes it. (It seems to
point in direction of random memory corruption, though.)
Use the (relatively new) libavformat image format probing functionality,
instead of letting demux_mf guess by file extension and MIME type.
The libavformat support is weird, though. Traditionally, it uses an
absolutely terrible hack to detect images by extension, _and_ (which is
the horrible part) will randomly interpret parts of the filename as
specifiers for matching by number. So something like '%03d' will be
interpreted as placeholder for a frame number. The worst part is that
such character sequences can be perfectly valid and common in http URLs.
This is known as "image2" demuxer. The newer support, which probes by
examining the file header, is split into several format-specific
demuxers with names ending in "_pipe". So we check for such a name
suffix. (At this point we're doing fine-grained hacking around ffmpeg
weirdness, so a clean solution is impossible anyway until upstream
changes.)
It was possible to make the player play local files by putting rar://
links into remote playlists, and some other potentially unsafe things.
Redo the handling of it. Now the rar-redirector (the thing in
demux_playlist.c) sets disable_safety, which makes the player open any
playlist entries returned. This is fine, because it redirects to the
same file anyway (just with different selection/interpretation of the
contents). On the other hand, rar:// itself is now considered fully
unsafe, which means that it is ignored if found in normal playlists.
This warning wasn't overly helpful in the past, and warned against
perfectly fine code. But at least with recent gcc versions, this is the
warning that complains about assignments in if expressions (why???), so
we want to enable it.
Also change all the code this warning complains about for no reason.
Semi-important, because --hwdec=dxva2 outputs NV12, and we really don't
want people to end up with the "old" StretchRect method.
Unfortunately, I couldn't actually get it to work. It seems most D3D
drivers (including the wine D3D implementation) reject D3DFMT_A8L8,
and I could not find any other 2-channel 8 bit Direct3D 9 format. It
seems newer D3D APIs have DXGI_FORMAT_R8G8_UNORM, but there's no way
to get it in D3D9.
Still pushing this; maybe it actually works on some drivers.
This time (there are a lot of times), libswscale randomly ignores
brightness/saturation/contrast settings.
Looking at MPlayer code, it appears the return value of
sws_setColorspaceDetails() signals if changing these settings is
supported at all.
(Nevermind that supporting this feature has almost 0 value, and
obviously eats maintenance time.)
When used with mp.get_screen_size(), mp.get_screen_margins() allows a
Lua script to determine what portion of the mpv window actually has the
video in it.
Breaks vo_opengl by default. I'm hot able to fix this myself, because I
have no clue about the overcomplicated color management logic. Also,
whilethis is apparently caused by commit fbacd5, the following commits
all depend on it, so revert them too.
This reverts the following commits:
e141caa97d653b0dd529729c8b3f64fbacd5de31Fixes#1636.
It is also used for initialization in channel-list setup.
Should fix compilation on FreeBSD, and is more correct
since it is used unconditionally.
Reverts 6445648 .
Just use makeFirstResponder on the mpv events view from client code
if you need the built in keyboard events (this is easier for dealing with view
nesting).
This relies on upstream support in lavc, and will hence basically not
work at all. The intent is to get support for writing this information
into ffmpeg's PNG encoders etc.
We have MP_CSP_TRC defined, but it wasn't being used by practically
anything. This commit adds missing conversion logic, adds it to
mp_image, and moves the auto-guessing logic to where it should be, in
mp_image_params_guess_csp (and out of vo_opengl).
Note that this also fixes a minor bug: csp_prim was not being copied
between mp_image structs if the format was not YUV in both cases, but
this is wrong - the primaries are always relevant.
Refactors an older hack, which for some reason used a more complicated
way. This generates the playlist representing the contents of the rar
file in demux_playlist.c. The pseudo-demuxer could easily be separate
from the the playlist parsers (and in fact there's almost no shared
code), but I don't think this obscure feature deserves a separate file.
Sample files created with:
rar a -v20000k -m0 files.rar file1.mkv file1.mkv
A use of NO_STREAM_ID_FILTER was added to the DVB code recently. While I
have no idea what it's needed for, it makes mpv fail to compile on
FreeBSD 10.1. Add it to the dvb configure check.
In the past it happened quite often that flag options (yes/no) were
changed to choice options (yes/no/some more). The problem with this was
that while flag options don't need a parameter, this wasn't the case
with choice options. A hack was introduced to compensate for this:
setting M_OPT_OPTIONAL_PARAM on the option, and an empty string ("") was
added as choice, so that the choice could be used like a flag. So, for
example, "--mute" would set the choice "".
Fix this by 1. not requiring a parameter if there's a "yes" choice, and
2. redirect an empty parameter to "yes". The effect is that a choice
option with the choices ["yes", "no"] is pretty much equivalent to a
flag option.
Now that we have fast stream switching, we can bump these sizes, as the
queues cause no delay in switching anymore.
Of course, the fast stream switching works for mkv and mp4 only. Other
formats will incur a quite terrible delay especially in network mode,
which this commit changes to 10 seconds. Let's see if someone
complains...
The way I interpreted it, it seemed like this was not default behavior
and could be enabled with --audio-pitch-correction - it should be made
clearer that this is actually *the default behavior*.
This is based on pretty much the same (somewhat naive) logic right now.
I'm not convinced that the extra logic that eg. madVR includes is worth
enough to warrant heavily confusing the logic for it.
This shouldn't slow down the logic at all in any sane shader compiler,
and indeed it doesn't on any shader compiler that I tested.
Note that this currently doesn't affect cscale at all, due to the weird
implementation details of that.
Broken drivers are an issue rather often. Maybe this gives the user an
idea that this could be the reason. (We can't dump much more info on a
80x24 terminal.)
Change test_fbo() so that it checks the FBO lazily, and restructure
check_gl_features() to invoke it only if we know that a FBO will be
needed for a certain enabled feature.
This can avoid strange error messages when using --vo=opengl and the
FBO format does not work. It's also less confusing when reading the
verbose log (users might think that the FBO is actually used, etc.).
This can happen with the "no-colorkey" suboption. Then the code in
xv_draw_colorkey() can be run before vo_x11_config_vo_window(), when
vo_gc is not allocated yet.
Fixes#1629.
This option allows the user to pass non-supported options directly to
youtube-dl, such as "--proxy URL", "--username USERNAME" and
'--password PASSWORD".
There is no sanity checking so it's possible to break things (i.e.
if you pass "--version" mpv exits with random JSON error).
Signed-off-by: wm4 <wm4@nowhere>
If the cache is enabled, the demuxer is closed and opened again (because
currently, the cache can not be enabled atfer data was already read).
The call for opening a new demuxer uses the same params struct, which
references the ctx->uids array. But there is a MP_TARRAY_GROW()
invocation somewhere on the way, which can reallocate the ctx->uids
array, making params.uids a dangling pointer.
This issue probably existed for a longer time, probably since 5cd33853
(slightly more obvious since f50b105d).
Again removes some indirections and extra arguments.
Also replace some memcpy/memmoves with assignments. (Assignments became
possible only later, when reference UIDs were turned into a struct.)
wm4
torque
Niklas Haas
Oliver Freyermuth
Stefano Pigozzi
zymos
Thiago Kenji Okada