| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the past, --video-unscaled also disabled zooming and aspect ratio
corrections. But this didn't make much sense in terms of being a useful
option. The new behavior just sets the initial video size to be
unscaled, but it's still affected by zoom commands and aspect ratio
corrections.
To get the old behavior back, --video-aspect=0 --video-zoom=0 need to be
added as well (in the general case). Most of the time it should not make
a difference though.
Also, there seems to have been some additional dst_rect clamping code
inside src_dst_split_scaling that didn't seem to either be necessary nor
ever get triggered. (The code immediately above it already makes sure to
crop the video if it's larger than the dst_rect)
No idea why it was there, but I just removed it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
It's pretty "unfriendly" and causes too many issues. (Probably. At least
they're more obvious to a user than e.g. broken frame timing.)
Potentially we could apply heuristics like applying this only on
fullscreen, but let's not. It's up to the user to configure this to
get best results.
Fixes #2997.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The past behavior was a bit weird, especially when zooming out. There
was no simple way to zoom in or out in consistent increments using
keybindings alone.
The new behavior preserves most of the old behavior's semantics but
scales out to infinity better. It coincidentally also makes it
really easy to get clean power of 2 ratios (e.g. 2x, 4x, 8x and their
inverses).
Fixes #3004.
|
| |
|
|
|
|
| |
I guess the syntax is not necessarily very obvious.
|
|
|
|
|
|
| |
This commit adds the d3d11va-copy hwdec mode using the ffmpeg d3d11va
api. Functions in common with dxva2 are handled in a separate decode/d3d.c
file. A future commit will rewrite decode/dxva2.c to share this code.
|
| |
|
| |
|
| |
|
|
|
|
| |
Also mention dxva2-copy along with vaapi-copy.
|
|
|
|
| |
It's useless, but can be used for fancy --lavfi-complex nonsense.
|
|
|
|
| |
Pretty useful for debugging surround nonsense.
|
| |
|
|
|
|
|
| |
You can e.g. reference ordered chapters or other EDL files in EDLs.
There were some bugs left which broke this in some cases.
|
|
|
|
| |
It's not exactly obvious how they interact.
|
| |
|
|
|
|
| |
Mostly intended for use with --lavfi-complex.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See --lavfi-complex option.
This is still quite rough. There's no support for dynamic configuration
of any kind. There are probably corner cases where playback might freeze
or burn 100% CPU (due to dataflow problems when interaction with
libavfilter).
Future possible plans might include:
- freely switch tracks by providing some sort of default track graph
label
- automatically enabling audio visualization
- automatically mix audio or stack video when multiple tracks are
selected at once (similar to how multiple sub tracks can be selected)
|
|
|
|
| |
Not needed anymore, because the decoder was merged with FFmpeg.
|
|
|
|
| |
Pointed out by der_richter on IRC.
|
|
|
|
|
|
| |
This is probably the 3rd time the user-visible behavior changes. This
time, switch back because not normalizing seems to be the more expected
behavior from users.
|
|
|
|
|
|
|
|
| |
Too many problems. Well, actually it's just Linux audio systems which
cause problems, and exclusive audio access on other platforms.
In any case, it seems you have to do some manual configuration if you
want multichannel audio output.
|
|
|
|
|
| |
Make it more conservative. In most cases, mpv should be able to
determine it correctly on all supported platforms.
|
|
|
|
|
|
|
| |
Since the streams are chosen from the full TS by the player frontend,
one should not expect that the program which is shown matches the chosen
channel which was used for tuning to the frequency.
Also, reformulate slightly to simplify reading.
|
|
|
|
|
| |
Very helpful to switch between the different programs
on a transponder in full-transponder-mode for DVB.
|
|
|
|
| |
Fixes #2707. (Not entirely following the suggestions there.)
|
|
|
|
| |
It's indeed completely useless. Pointed out in #2647.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Always preroll by default if the cue (index) information indicates
overlapping subtitles.
Increase the amount of maximum data it will skip to get such subtitles
to 10 seconds. Since the index information can reliably tell whether
reading earlier is needed, the maximum should be rarely actually used,
thus we can set it high. On the other hand, the "old" prerolling
mechanism always has to skip the maximum amount of data; thus the method
using the index gets its own option to control the maximum amount of
data to skip.
(As more and more files With newer mkvtoolnix versions are muxed, and
with this new and hopefully sane default established, these options can
probably be removed in the future.)
|
|
|
|
|
|
|
|
| |
Requested. It works like --sub-paths. This will also load audio files
from a "audio" sub directory in the config file (because the same code
as for subtitles is used, and it also had such a feature).
Fixes #2632.
|
| |
|
|
|
|
|
|
|
|
|
| |
This is only for specific Hauppage cards. According to the comments in
who is actively using this feature. Get it out of the way.
Anyone who still wants to use this should complain. Keeping this code
would not cause terribly much additional work, and it could be restored
again. (But not if the request comes months later.)
|
|
|
|
| |
Don't ask why.
|
|
|
|
| |
This was requested.
|
| |
|
|
|
|
|
|
|
| |
This logic was kind of questionable anyway, and --display-sync should
give much better results. (I would even go as far as saying that the
FPS-dependent framedrop code made things worse in some situations. Not
all, though.)
|
|
|
|
|
| |
there were a few places that that used an upper case D
and one that still actually said Shift+D
|
|
|
|
|
|
|
| |
Maybe this is a good idea. Also add an option to disable it again, for
the sake of testing.
Fixes #2502.
|
|
|
| |
`--vd--lavc-o becomes --vd-lavc-o`
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Because apparently there's no ideal universally working format.
The weird OpenGL texture format for kCVPixelFormatType_32BGRA is from:
http://stackoverflow.com/questions/22077544/draw-an-iosurface-to-an-opengl-context
(Which apparently got it from the linked Apple example code.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of this is explained in the DOCS additions.
This gives us slightly more sanity, because there is less interaction
between the various parts. The goal is getting rid of the video_offset
entirely.
The simplification extends to the user API. In particular, we don't need
to fix missing parts in the API, such as the lack for a seek command
that seeks relatively to the start time. All these things are now
transparent.
(If someone really wants to know the real timestamps/start time, new
properties would have to be added.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently Windows treats windows that use OpenGL, cover an entire
screen and have the WS_POPUP style set or are topmost windows as
exclusive fullscreen windows that bypass DWM and cannot be covered
by other windows.
This means we can’t use dwmflush in fullscreen mode, and it also
means that no other window can cover mpv, and it makes the screen
flicker when switching to fullscreen mode.
This can be avoided by not setting the WS_POPUP flag.
Users can still access the old behavior by enabling stay-on-top
(which IMO at least makes sense—now we just need to get dwmflush
autodetection right to avoid nasty surprises).
fixes #2177
|
|
|
|
|
|
|
|
| |
While it seemed like a pretty good idea at first, it's just a dead end
and works only in the simplest cases. While it may or may not help
slightly with audio sync mode, the display-sync mode already compensates
this in a better way. The main issue is that timestamps at this layer
are not in order, so it can look at single timestamps only.
|
|
|
|
|
| |
We didn't include this codec in the whitelist because of past problems
with vdpau and interlacing. (I can't reproduce any problems anymore.)
|
|
|
|
|
|
|
|
|
|
|
|
| |
A hw decoder might fail to decode a frame for multiple reasons, and not
always just because decoding is impossible. We can't generally
distinguish these reasons well. Make it more tolerant by accepting
failures of 3 frames, but not more. The threshold can be adjusted by the
repurposed --vd-lavc-software-fallback option.
(This behavior was suggested much earlier in some PR, but at the time
the "proper" hwdec fallback was indistinguishable from decoding error.
With the current situation, "proper" fallback is still instantious.)
|
|
|
|
| |
Not very robust in the moment.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Client certificates are supported by ffmpeg as documented here:
> https://www.ffmpeg.org/ffmpeg-protocols.html#tls
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
|
|
|
|
| |
Thanks to rcombs, ffmpeg now properly supports DASH and we can
remove our hacks for it and use it by default whenever
available. If you don't like this for whatever reason, you
can get the "normal" streams back with --ytdl-format=best .
Closes #579
Closes #1321
Closes #2359
|
|
|
|
|
|
| |
libass 0.13.0 breaks this due to removal of fontconfig from its core
(instead, fontconfig is one possible backend, and pattern lookup is
apparently not possible anymore).
|
|
|
|
|
|
|
|
|
| |
Useless. Sometimes it might be useful to make some extremely broken
files work, but on the other hand --no-correct-pts is sufficient for
these cases.
While we still need some of the code for AVI, the "auto" mode in
particular inflated the size of the code.
|
|
|
|
|
|
|
|
|
| |
The manpage entry explains this.
(Maybe this option could be always enabled and removed. I don't quite
remember what valid use-cases there are for just disabling audio
entirely, other than that this is also needed for audio decoder init
failure.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The vf_format suboption is replaced with --video-output-levels (a global
option and property). In particular, the parameter is removed from
mp_image_params. The mechanism is moved to the "video equalizer", which
also handles common video output customization like brightness and
contrast controls.
The new code is slightly cleaner, and the top-level option is slightly
more user-friendly than as vf_format sub-option.
|
|
|
|
|
|
|
|
|
| |
VideoToolbox is preferred. Now that FFmpeg released 2.8, there's no
reason to support VDA anymore. In fact, we had a bug that made VDA not
useable with older FFmpeg versions in some newer mpv releases.
VideoToolbox is supported even on slightly older OSX versions, and if
not, you still can run mpv without hw decoding.
|
|
|
|
| |
fixes #2289
|
|
|
|
|
|
| |
Utterly idiotic bullshit.
Fixes #2259.
|
|
|
|
| |
Oddly often requested.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If this mode is enabled, the player tries to strictly synchronize video
to display refresh. It will adjust playback speed to match the display,
so if you play 23.976 fps video on a 24 Hz screen, playback speed is
increased by approximately 1/1000. Audio wll be resampled to keep up
with playback.
This is different from the default sync mode, which will sync video to
audio, with the consequence that video might skip or repeat a frame once
in a while to make video keep up with audio.
This is still unpolished. There are some major problems as well; in
particular, mkv VFR files won't work well. The reason is that Matroska
is terrible and rounds timestamps to milliseconds. This makes it rather
hard to guess the framerate of a section of video that is playing. We
could probably fix this by just accepting jittery timestamps (instead
of explicitly disabling the sync code in this case), but I'm not ready
to accept such a solution yet.
Another issue is that we are extremely reliant on OS video and audio
APIs working in an expected manner, which of course is not too often
the case. Consequently, the new sync mode is a bit fragile.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This doesn't work too well if sections of the file change to a different
framerate. It lowers our chances to guess the correct FPS in the display
sync code.
For normal playback, this (probably) doesn't help that much anyway,
except that the "estimated-vf-fps" property will regress in the simplest
mkv case. This will be fixed with the next commit.
The now disabled code will probably be removed; it's not useful anymore.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add --demuxer-max-packets and --demuxer-max-bytes, which control the
maximum size of the packet queue. These can be helpful to avoid
excessive memory usage.
Memory usage is the reason why there's a limit in the first place. If a
file is more or less broken, and audio and video don't line up, the
decoders will fill up the packet queue trying to read more audio or
video, and the maximum sizes are required to avoid unbounded memory
allocation. Being able to override the maximum sizes is useful; either
for restricting memory usage further, or enlarging the sizes when
attempting to play various broken files.
|
|
|
|
|
|
|
|
| |
Remove --demuxer-readahead-packets and --demuxer-readahead-bytes. These
were a bit useless. They could force a minimum packet queue size, but
controlling the queue size with --demuxer-readahead-secs is much nicer.
It's fairly certain nobody ever used these options.
|
|
|
|
|
| |
If mpv is not built with uchardet, "enca" is |