| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
The old FFmpeg API and the new Libav API disagree about mp4 display
rotation direction. Well, whatever, fix it trial-and-error-style.
CC: @mpv-player/stable: add
|
|
|
|
|
|
|
|
| |
No reason to wait until the audio has been played. This isn't a problem
with gapless audio disabled, and since gapless is now default, this
behavior might be perceived as regression.
CC: @mpv-player/stable
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Logic for this was missing from pull.c. For push.c it was missing if the
driver didn't support it. But even if the driver supported it (such as
with ao_alsa), strange behavior was observed by users. See issue #933.
Always check explicitly whether the AO is in paused mode, and if so,
don't drain.
Possibly fixes #933.
CC: @mpv-player/stable
|
|
|
|
| |
found
|
|
|
|
|
|
| |
Also silences the bogus message if that happens.
CC: @mpv-player/stable
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Happens when playing from a pipe.
Note that seeking forward doesn't work. It would be possible to create a
workaround for that by reading and skipping data until the target
position is reached (and writing the skipped data into the cache file),
but I'm not sure about that.
Fixes #928.
CC: @mpv-player/stable
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Key bindings are decided on the "down" event, so if the prefix is not
unique, the first/shortest will be used (e.g. when both "a" and "a-b"
are mapped, "a" will always be chosen).
This also breaks combining multiple mouse buttons. But it seems users
expect it to work, and it's indeed a bit strange that it shouldn't work,
as mouse bindings are emitted on the key "up" event, not "down" (if the
shorter binding didn't emit a command yet, why shouldn't it be
combinable).
Deal with this by clearing the key history when a command is actually
emitted, instead of when a command is decided. This means if both
MOUSE_BTN0 and MOUSE_BTN0-MOUSE_BTN1 are mapped, the sequence of holding
down BTN0 and then BTN1 will redecide the current command. On the other
hand, if BTN0 is released before BTN1 is pressed, the command is
emitted, and the key history is deleted. So the BTN1 press will not
trigger BTN0-BTN1.
For normal keys, nothing should change, because commands are emitted on
the "down" event already, so the key history is always cleared.
Might fix #902.
CC: @mpv-player/stable (if this fix is successful)
|
|
|
|
|
|
|
|
|
| |
Doesn't work quite right, and will pause for the latency duration after
seeking. Some users use --ao=null to disable audio (even though they
should probably use --no-audio), and this use-case is broken by this
issue too.
CC: @mpv-player/stable
|
|
|
|
|
|
|
|
|
|
|
|
| |
When seeking, we violently destroy the filter, because vapoursynth has
no proper API for terminating a video with unknown frame count. This
looks like an error to vapoursynth, and the error is returned via the
frame callbacks. The bug is that we remember this error state across
reinitialization, so on the first filter call after reinitialization, we
thought filtering the current frame failed. This caused a shift by 1
frame on each seek.
CC: @mpv-player/stable
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not all compilers on all platforms have atomics available (even if they
could, technically speaking).
We don't use atomics that much, only the following things rely on it:
1. the audio pull code, and all audio outputs using it
2. updating global msg levels
3. reading log messages through the client API
Just disable 1. and 3. if atomics are not available. For 2., using fake-
atomics isn't too bad; at worst, message levels won't properly update
under certain situations (but most likely, it will work just fine).
This means if atomics are not available, the client API function
mpv_request_log_messages() will do nothing.
CC: @mpv-player/stable
|
|
|
|
| |
CC: @mpv-player/stable
|
|
|
|
| |
CC: @mpv-player/stable
|
|
|
|
|
|
|
|
|
|
|
| |
Suggested by tholin on github issue #882.
This is not entirely clean, but the fields we're accessing might be
considered internal to libavformat. On the other hand, existence of the
fields is guaranteed by the ABI, and nothing in the libavformat doxygen
suggestes they're not allowed to be accessed.
CC: @mpv-player/stable
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recently, libavformat added demuxers to open image files like normal
demuxers. This is a good thing, but for now they interfere with the
operation of demux_mf. Add them to the blacklist until there is a proper
solution.
(The list doesn't contain _all_ recognized image formats, just those
that might interfere with demux_mf.)
CC: @mpv-player/stable
|
|
|
|
|
|
|
|
| |
The last title was ignored before.
CC: @mpv-player/stable
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
| |
CC: @mpv-player/stable
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
|
| |
libdvdnav returns an error is the seek position is out of range.
CC: @mpv-player/stable
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
| |
This is an oversight and a bug.
CC: @mpv-player/stable
|
|
|
|
|
|
|
|
| |
This stops options that are prefixes of other options from blocking
completion of values for the longer ones.
Conflicts:
TOOLS/zsh.pl
|
|
|
|
|
|
|
|
|
|
|
|
| |
Completion now uses "--opt=value" instead of "--opt value". Once the
user presses space and starts a new argument, the option just
completed is out of the picture, whether or not it was given an
argument. This handles options with no arguments or optional arguments
much better; previously, completing such an option would effectively
disable completion for the next argument.
Custom completed options such as "--ao" and friends will no longer
claim to consume an extra argument.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When resizing the cache, the buffer for the DVD timestamps is
initialized with 0. This causes the player to always return playback
position 0 with any file format (not just DVD), and also makes all
relative seeks relative to position 0. Fix this by clearing the
timestamps explicitly.
Closes #899.
CC: @mpv-player/stable
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently clearing on every map can cause problems with vdpau when
switching virtual desktops and such. This was observed with at least
XMonad and nvidia-340.17. It's not observed on some other setups without
XMonad.
It's not clear why this happens. Normally, the window background is not
saved, so clearing should have no additional affect. It's a complete
mystery. Possible, the use of legacy X drawing commands (used to clear
the window) interferes with vdpau operation in non-trivial ways.
Work this around by clearing on initial map only. This probably only
hides the underlying issue, but good enough.
Closes #897.
CC: @mpv-player/stable
|
|
|
|
| |
CC: @mpv-player/stable
|
| |
|
|
|
|
|
|
|
|
|
| |
It was intended to be set to "weak" (and that was even documented), but
the actual setting was "no".
Closes #890.
CC: @mpv-player/stable
|
|
|
|
|
|
|
|
|
|
|
| |
Some of these might be security relevant.
The RealAudio code was especially bad. I'm not sure if all RealAudio
stuff still plays correctly; I didn't have that many samples for
testing. Some checks might be unnecessary or overcomplicated compared
to the (obfuscated) nature of the code.
CC: @mpv-player/stable
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rgain is not an additive value. It's a multiplier/gain.
Previous behaviour produced negative level values in some cases
(when rgain < 1.0) which caused volume to be louder when its value
was lowered.
CC: @mpv-player/stable
Signed-off-by: Mohammad Alsaleh <CE.Mohammad.AlSaleh@gmail.com>
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
| |
The string could get reallocated.
CC: @mpv-player/stable
|
| |
|
|
|
|
| |
Requested by a user. Closes #878.
|
| |
|
|
|
|
|
| |
Now it's at least actually relayed to the TV code. I didn't/couldn't
test whether it actually works, though.
|
|
|
|
| |
Oops.
|
|
|
|
|
|
| |
This is hopefully better for web streams.
Temporary workaround for #870.
|
| |
|
|
|
|
|
|
| |
Close #837
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
| |
These consult the vertical resolution, matching against 576 for
PAL and 480/486 for NTSC. The documentation has also been updated.
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
| |
Notably, we now conform to SMPTE 428-1-2006 when decoding XYZ12 input,
and we can support rendering intents other than colorimetric when
converting between BT.709 and BT.2020, like with :srgb or :icc-profile.
|
|
|
|
|
|
|
|
|
| |
With this change, XYZ input is directly converted to the output
colorspace wherever possible, and to the colorspace specified by the
tags and/or --primaries option, otherwise.
This commit also restructures some of the CMS code in gl_video.c to
hopefully make it clearer which decision is being done where and why.
|
|
|
|
|
|
|
|
|
| |
This also avoids an extra matrix multiplication when using :srgb, making
that path both more efficient and also eliminating more hard-coded
values.
In addition, the previously hard-coded XYZ to RGB matrix will be
dynamically generated.
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
| |
This add support for reading primary information from lavc, categorized
into BT.601-525, BT.601-625, BT.709 and BT.2020; and passes it on to the
vo. In vo_opengl, we always generate the 3dlut against the wider BT.2020
and transform our source into this colorspace in the shader.
|
|
|
|
| |
Source: http://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2020-0-201208-I!!PDF-E.pdf
|
| |
|
|
|
|
|
|
|
|
|
| |
For remarks, pretty much see the manpage additions. Could help with
network streams that require too much seeking (maybe), or might be
extended to help with the use case of watching and downloading a file
at the same time.
In general, it might be a useless feature and could be removed again.
|
|
|
|
|
| |
Remove unused stream type constants. Move some now DVD specific crap
to stream_dvd.c.
|
|
|
|
|
| |
One message pointed to a removed file, so just get rid of the messages.
They were helpful in the earlier 2000s, but now they're just confusing.
|
|
|
|
|
| |
This additional sub-directory doesn't serve any purpose anymore. Get rid
of it.
|
| |
|
|
|
|
| |
I wish I could make github run a hook to reject these.
|
|
|
|
|
|
| |
It seems it's generally cleaner to leave this stuff to the BSDs.
Additionally, the NetBSD part wasn't even correct, because it made the
compiler prefer the system include path before local include files.
|
|
|
|
| |
The old stream_dvd.c implementation is still available under dvdread://.
|
|
|
|
|
| |
Attempt to fix a reported freeze with some DVDs. Unknown if this helps,
and it still might read the whole DVD before terminating.
|
|
|
|
|
|
|
|
| |
It is reasonably stable, so all further changes will be versioned.
Also change how the libmpv version number is generated. Fix the patch
version number to 0; I don't think we have a use for this. In
particular, the version doesn't version mpv, just the client API.
|
| |
|
|
|
|
| |
Recent regression.
|
| |
|
|
|
|
|
|
| |
Reallocating an array while you still have pointers to it -> bad idea.
Recent regression.
|
|
|
|
|
|
| |
Do this simply by clearing the mapped buffer on every draw_image() call
without an actual video frame. (Maybe this is a bit expensive, but at
least not more expensive than regular video display.)
|
|
|
|
|
|
| |
Clear the texture on reconfig(). (We could probably also do this simpler
with a flag, but this is actually less complicated - except that we move
the code to "map" a texture to a separate function.)
|
|
|
|
|
|
| |
With the change to merge osd drawing into video frame drawing, some
bogus logic got in: they skipped drawing the OSD if no video frame is
available. This broke --no-video --force-window mode.
|
|
|
|
|
| |
Signed-off-by: Timothy Gu <timothygu99@gmail.com>
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
| |
In the pbo case, mpi was reassigned to a stack pointer, and later
deallocated. Just change the code so it doesn't need to be reassigned.
|
|
|
|
| |
Made the first line formatted differently.
|