| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
av_get_default_channel_layout() fails with channel counts larger than 8.
The channel layout doesn't need to make sense, so pick an arbitrary
fallback.
libswresample also has options for setting the channel counts directly,
but better not introduce new concepts in the code. Also, libavresample
doesn't have these options.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change it so that it will always return a bitmask with the correct
number of channels set if an unknown channel map is passed. This didn't
work for channel counts larger than 8, as there are not any standard
channel layouts defined with more than 8 channels (both in mpv and
FFmpeg). Instead, it returned 0.
This will help when raising the maximum allowed channel count in mpv.
Some code in af_lavrresample relies on it, more or less.
One change is that unknown channel maps won't result in lavc standard
channel layouts anymore, just a set of random speakers. This should be
fine, as the caller of mp_chmap_to_lavc_unchecked() should handle these
cases. For mp_chmap_reorder_to_lavc() this is not so clear anymore, but
should also be ok.
For normal channel maps, simply dropping NA channels is still the
correct and wanted behavior.
Currently, the mpv maximum channel count is 8. This commit is
preparation for raising this limit.
|
|
|
|
|
| |
Until now, this was done only in debug verbosity, while some AOs logged
equivalent information in verbose mode. Clean this up.
|
|
|
|
|
|
|
|
|
| |
mNumberChannelDescriptions being 0 is pretty much an error, but if it
can happen, then the code checking the chmap below will trigger UB, as
chmap is not initialized at all.
Also, simplify the code a little: we never change the number of
channels, so this is just fine.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This code removes filters which can not take spdif inout. This was made
so that PCM filters are transparently dropped in spdif mode.
This entered an endless loop with:
--af=lavcac3enc:::2 --audio-channels=5.1
The forced number of output channels is incompatible with spdif. It's
trying to insert af_lavrresample as conversion filter to compensate for
it. Of course this doesn't work, which triggers the PCM filter removal.
Then it goes on normally - since the new state is exactly as before, it
will try the same thing again, forever.
Fix by reusing the retry counter, which is a very dumb but very
effective measure against these cases of filter negotiation failure. We
could try to be more clever (for example, if the removed filter is a
conversion filter, we can be sure this won't work, and error out
immediately). But better keep it simple and robust.
|
|
|
|
|
| |
And also remove a redundant log message. (We can tell from the following
probe or error message whether or not the format test is successful.)
|
| |
|
| |
|
|
|
|
|
|
| |
Defaults stay the same (--all-subs is used if sub-lang wasn't used.)
Don't forget to also add "write-sub=" if using sub-lang or else it won't
work.
|
|
|
|
| |
The source shader was removed after deband was introduced.
|
| |
|
|
|
|
|
|
| |
This speeds up redraws considerably (improving eg. <60 Hz material on a 60 Hz
monitor with display-sync active, or redraws while paused), but slightly
slows down the worst case (eg. video FPS = display FPS).
|
|
|
|
|
| |
It's not clear why this was originally hidden, but the information is
useful for allowing the VO backend to make decisions about caching.
|
|
|
|
|
|
|
|
|
|
| |
The IME is not useful for key-bindings. Handle the base ASCII chars
instead and don't show the IME window. For the sake of libmpv users, the
IME should only be disabled on mpv's GUI thread and not application-
wide.
No IME on the GUI thread should also mean that VK_PROCESSKEY will never
have to be handled, so the logic for that can be removed as well.
|
|
|
|
|
| |
They're the same, but EGL_CONTEXT_MAJOR_VERSION_KHR technically is an
extension, while EGL_CONTEXT_CLIENT_VERSION is the standardized alias.
|
|
|
|
|
|
|
| |
Older systems have certain EGL extension definitions missing. We
redefine them to make the build system easier, and because it's trivial.
But we forgot to define the EGL_LINUX_DMA_BUF_EXT identifier. (I hope
it's the only missing one.)
|
| |
|
|
|
|
|
|
|
|
| |
This makes the bitrate properties unavailable, instead of
returning 0 when:
1. No track is selected, or
2. Not enough packets have been read to have a bitrate estimate yet
|
|
|
|
|
|
| |
Some mkv files can have this. The chapter times are still timestamps
(and thus not affected by the start time), but it misplaces the OSD
chapter ticks.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The equalizer code as it exists in vo_opengl works perfectly fine. The
situation in vo_opengl_cb is pretty different. The playback thread can't
communicate with the renderer thread synchronously (essentially to give
the API user more flexibility). So the equalizer communication has to be
done in an asynchronous way too.
There were two problems. First, the eq capabilities can change with the
pixel format, and the renderer initializes them on config only. This
means equalizers were disabled on the first config run, and options like
--video-output-levels or --brightness would not work. So we just
initialize the caps with a known superset. The player will not correctly
indicate when setting an eq doesn't work, but we're fine with it, as it
is a relatively cosmetic issue.
Second, it copied back the eq settings in the "wrong" moment (what
for?), which overwrote the settings in some cases.
Third, the eq was not reset correctly on vo init. This is needed to make
it behave the same as vo_opengl.
|
| |
|
|
|
|
| |
Let's not waste precious lines.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the aspect ratio of the video resolution and the subtitle resolution
(the implied subtitle coordinate system) mismatch, the subtitles
obviously can't be overlayed over the video perfectly. Either you get
video that can't be covered by subtitles, or the subtitles could go
beyond the video. We don't want to stretch the subtitle to compensate
for the aspect ratio, because it would look terrible.
Until now, mpv used to fit the subtitle rectangle into the video
rectangle (letterboxing/pillarboxing). This looks odd with some sample
files with subtitle canvas being wider than the video. Also, mpc-hc
displays them in a better way. vlc stretches them, which looks bad.
While you probably can't win this game with all those broken files
around, pick the mpc-hc method to handle this.
|
|
|
|
|
|
| |
There was a complaint that the naming is inaccurate. That's probably
right. Just use the official name instead, which is a bit clunky, but
surely correct.
|
|
|
|
| |
"Let's apply cosmetic last minute changes without testing them."
|
|
|
|
|
|
|
| |
Deserves its own name, because just like SPACE it's a printable
character, but invisible.
Fixes #2349... I think.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Helps with broken vobsubs, which have an incorrect resolution header
set.
So we just extend the subtitle resolution to the video size, if the
video size is larger. This helps somewhat with readability, or makes
them visible at all. It should be a pretty safe change, because normally
no sub pictures are supposed to go outside of the area. It should make a
difference with broken files only.
The sample in question had a video resolution of 1888x1072, and a
subtitle resolution of 720x480. Note that always using video resolution
as subtitle resolution would break other files.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Coreaudio gives us a channel map with all entries set to
kAudioChannelLabel_Unknown. This is translated to a mpv channel map with
all channels set to NA, which has special meaning: it's an "unknown"
channel map, which acts as wildcard and can be converted from/to any
channel layout. Not really what we want.
I've got this with USB audio, playing stereo. The multichannel layout
consisted of 2 unknown channels, while the stereo channel map was
stereo (as expected).
Note that channel maps with _some_ NA entries are not affected by this,
and must still work.
|
|
|
|
|
|
|
|
|
| |
If the device returns an unexpected number of channels instead of the
requested count on init, don't immediately error out. Instead, look if
there's a channel map with the given number of channels.
If there isn't, still error out, because we don't want to guess the
channel layout.
|
|
|
|
|
| |
Not particularly important; just being nice and potentially avoiding
problems caused by format setting.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
It's great that the new algorithm supports multiple placebo iterations
and all, but it's really not necessary and hurts performance in the
general case for the sake of the 0.1% that actually pause the screen
and look for minute differences.
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
|
| |
Client certificates are supported by ffmpeg as documented here:
> https://www.ffmpeg.org/ffmpeg-protocols.html#tls
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
|
|
|
| |
Reportedly fixes operation with "USB connected Parasound ZDAC v.2". (OSX
and USB audio sure is not nice at all.)
This might be perceived as hang by some users, so it's quite possible
that this will have to be adjusted again somehow.
Fixes #2409.
|
|
|
|
|
|
| |
This reverts commit c10fb4ce9fcd3dbbf69741eb8499c4cfabbf5412.
This is already done in vo_wayland.c:resize,324 doing it here makes the window bigger before the video resizes showing a black area while dragging the border.
|
|
|
|
|
| |
1 to 2 frames desync is still tolerable, and will be quickly compensated
(if everything works).
|
|
|
|
|
|
|
| |
Apparently this function caused weird problems to me. I have no idea
why. The usage of the function looks perfectly fine to me, and even
rounding issues can be excluded. In any case, getting rid of this solved
my problem, and makes the code actually more readable.
|
|
|
|
|
|
|
|
|
|
| |
The previous commit moved the av_frame_unref() after the got_picture
check. This accidentally also deferred the software fallback
reinitialization to until a software picture was decoded (instead of the
exact time of the fallback), which is not ideal.
Just rely on the fact that calling av_frame_unref() on a frame is ok
even if nothing was decoded.
|
|
|
|
|
|
|
|
|
|
| |
Commit 12cd48a8 started setting the hwdec_failed field even if hwdec was
not active, and because it also checked this field even if hwdec was not
active, broke decoding forever.
Fix this, and also avoid a memory leak or API misuse by releasing the
decoded picture. Passing an unreleased frame to the decoder has as far
as I know no defined effects.
|
|
|
|
|
|
| |
If this is not done, libavformat could change the headers while
demuxing, all while the decoder thread reads these fields during
initialization.
|
|
|
|
|
|
|
| |
This fixes initial decoding of some samples. See #1341.
According to Libav devs, this should be considered a libavcodec bug, but
as it's hard to fix, here we go.
|
|
|
|
|
|
|
|
| |
Adds support for AV_PIX_FMT_GBRP9, AV_PIX_FMT_GBRP10, AV_PIX_FMT_GBRP12,
AV_PIX_FMT_GBRP14, AV_PIX_FMT_GBRP16, AV_PIX_FMT_GBRAP, and
AV_PIX_FMT_GBRAP16.
(Not that it matters, because nobody uses these anyway.)
|
| |
|
|
|
|
|
| |
This was once done when old versions of libva without VPP had to be
supported. Some parts of it were removed earlier already.
|
|
|
|
|
|
|
| |
This VA_FOURCC isn't even defined by latest drivers, so I'm just
assuming it doesn't exist and never existed. For planar 4:2:0,
VA_FOURCC_YV12 is normally preferred, and there's even a VA_FOURCC_IYUV
for 4:2:0 with unswapped planes.
|
|
|
|
|
|
|
|
| |
0.34 and 0.35 don't have the buffer API, such as vaAcquireBufferHandle.
This is only needed for the EGL interop, but why bother staying
compatible for such old things (0.36 was released over a year ago).
We also can drop some minor compatibility ifdeffery.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MKV files can very well start with timestamps other than 0. While mpv
has support for such files in general, and demux_lavf enables this
feature, demux_mkv didn't export a start time.
Implement this by simply reading the first cluster timestamp. This in
turn is done by reading 1 block. While we don't need the block for this
prupose at all, it's the easiest way to get the cluster timestamp read
correctly without code duplication. In theory this could be wrong, and
a packet could start at a much later time, but in practice this won't
happen.
This commit also adds an option to disable this feature. It's not
documented because nobody should use it. (But I happen to have a need
for this.)
|
|
|
|
|
|
| |
Let's hope this doesn't confuse client API users too much. It's still
the best solution to get rid of corner cases where it actually return
the wrong timestamp on start, and then suddenly jump.
|
|
|
|
|
|
|
|
| |
matplotlib is pathetically slow, which makes using stats-conv.py to view
dumps longer than a few seconds a huge pain.
pyqtgraph is slightly faster than matplotlib. Other than that, it seems
to be worse in every aspect (at least for plotting), but such is life.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When seeking, the current frame will have the wrong timestamp, until the
seek is done and a new frame from the seek target is shown. We still use
the "old" frame for redrawing during seeks. This frame has to be
explicitly marked with still=true in order not to confuse the
interpolation queue. If this is not done, it will ignore frames until a
frame with approximately the same timestamp as the "old" frame is
reached. (Does this mean interpolation handles timestamp resets
incorrectly? I have no idea.)
Of course we also have to clear possibly queued frames on seeks.
Also, in pausing, explicitly let the frame redraw.
|
|
|
|
|
|
| |
This adjustment is supposed to improve the audio speed calculation in
case of unexpected desync. The flipped sign made it actually worse,
although the total impact of this bug was very minor.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Small adjustments to the playback speed use swr_set_compensation()
to stretch the audio as it is required. But since large adjustments
are now handled by actually reinitializing libswresample, the small
adjustments get rounded off completely with typical frame sizes.
Compensate for this by accounting for the rounding error and keeping
track of fractional samples that should have been output to achieve
the correct ratio.
This fixes display sync mode behavior, which requires these adjustments
to be relatively accurate.
|
|
|
|
|
| |
The origin of the stats line was added as a comment (starting with '#').
It was useless and just blowing up file sizes.
|
|
|
|
|
|
|
| |
Simple oversight which made it not work at all.
How did this ever work, and if it was never tested, then why did it work
when fixing this oversight?
|
|
|
|
| |
This is all kinds of wonderfully stupid.
|
|
|
|
|
|
|
|
|
| |
Newer nVidia drivers support EGL, but they seem to work badly,
apparently don't support some needed features or not in a form we want
(such as swap control), and vdpau interop is not available. Disable it
by default, because I'm tired of explaining this issue.
Can be reverted as soon as nVidia release working drivers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The libavcodec h264 decoder contains some idiotic code with unknown
purpose (no sample or explanation known that necessitates its
existence), that causes the AVCodecContext.get_format callback to be
invoked at a time when hwaccels can't be initialized. By definition, the
get_format callback is supposed to initialize hwaccels (another idiotic
thing now part of the API, but different story). This causes hwdec
initialization sometimes to fail (WolfensteinTwitch.mp4): the first
get_format callback will mark it as failed, so the second get_format
(the "proper" normal one) will not bother restoring the state, and hwdec
init fails.
While this should be fixed in libavcodec (good luck with that), it's
quite easy to workaround.
|
|
|
|
|
|
| |
This affects the subtitle preroll mode during seeking. It could matter
somewhat with insane files with ten-thousands of subtitle events, which
now seem to pop up, and will avoid packet queue overflow.
|
|
|
|
|
|
| |
swr/avresample_set_compensation() was made for small speed adjustments.
Non-documentation says it should be used for changes not larger than 1%,
so reinitialize the sampler if the change is larger than that.
|
| |
|