| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Listening to kAudioDevicePropertyDeviceHasChanged does not send any
property change notifications when the device dies. Makes no sense,
but I suppose in CoreAudio logic a dead/removed device can't send
any notifications.
This caused the player to essentially pause playback if the audio
device was removed during playback.
Fix by listening to the kAudioHardwarePropertyDevices property too,
which will actually be sent in this specific case. Then, if
querying the already dead device fails, we know we have to reload.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In short, instead of letting the coreaudio property listener set atomic
flags (which are then polled), make the property listeners actually
active.
The format change listener used during audio output now simply calls
ao_request_reload() on its own. All code involved is thread-safe, so
there's no need to do it during this audio callback (we assumed the
callback was never run concurrently with itself).
The listener installed temporarily during ca_change_format() is changed
to post a semaphore. Get rid of the weird retry logic and replace it
with a flat loop + timeout. It appears the maximum wait time could be
2500ms; reduce the total timeout to 500ms instead.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This manually retrieved the remaining audio from the resampler. It
subtly missed a conversion which could leave to an unsubtle crash.
This could happen if reorder_planes() was supposed to insert NA
channels, and the resampler/actual output format were different.
Simplify it by reusing the normal drain path. One oddness is that
the filter will add an output frame outside of normal filtering,
but that should be fine.
|
| | |
|
| |
|
|
| |
Fixes a crash on exit under certain circumstances.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This was missing for extended deinterlacer.
Unfortunately, these deinterlacer still do not work. The provided future
frame (which is all the deinterlacers want) seems to be correct, though.
One minor behavioral change is that this always keeps the previous frame
for PTS computations. This could be avoided (in order to keep exactly
the same behavior as before), but it seems more elegant and should not
do any harm. (Also, if we really cared about reducing hw frame refs,
a more worthy goal is producing the field output incrementally.)
|
| |
|
|
| |
Stupid C.
|
| |
|
|
|
|
|
|
| |
The mapped data (pointed to by the param variable) is not needed before,
so the call can be moved down. Also, this prevents that the buffer
remains mapped forever if the other vaMapBuffer() call above fails (the
cleanup code forgets to unmap the buffer - this commit makes it
unnecessary).
|
| |
|
|
|
|
|
| |
This used a do-while loop, which runs only once, as replacement for a
cleanup goto. While this is ok, doing a goto directly is easier to
follow and is closer to idiomatic C. But mainly remove it so that the
indentation can be reduced.
|
| |
|
|
| |
Adjust coding style. Get rid of some useless consts too.
|
| |
|
|
| |
Slightly easier to follow.
|
| |
|
|
|
|
| |
Reconfiguring with the same video size should never cause the window to
resize back to the video size (if the user changed its size). This was
broken and it resized anyway.
|
| |
|
|
|
|
|
| |
This was a cosmetic issue. It's handled differently now (clamping the
display time to known duration range).
This reverts commit 33b57f55573e658b3af6c6e8ff3188c8f959e82e.
|
| | |
|
| |
|
|
|
| |
When running on Wayland, and vo_opengl is not available or rejected for
some reason, it's better to use vo_wayland instead of e.g. vo_x11.
|
| |
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We do not fill them, so we would pass random IDs to the driver. The code
was originally written to handle bob deinterlacing only, so I guess it
originally passed always 0 anyway, despite having code for reference
surface list allocation.
Also, move down the vaUnmapBuffer() call. This call actually "unmaps"
the param pointer, so accessing it after the unmap call would be
undefined behavior. The "example" in <va/vavpp.h> does this too, but
it's most likely an error.
(Additionally, not even bob deinterlacing worked correctly in my test,
sigh.)
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Normally, the cache keeps 50% of the buffer for seeking backwards. Until
now, the cache just used the full buffer size at the beginning of a
file, because the 50% normally reserved for the backbuffer are unused.
This caused a problem: when streaming from http, the player would first
read about 150MB (default cache size), then stop until 75MB of the cache
has been played. (Until the 75MB position, the cache is fully used, so
nothing new can be read. After that, part of the backbuffer starts
getting unreserved, and can be used for readahead.) This long read pause
can cause the server to terminate the connection. Reconnecting may be
possible, but if youtube-dl is used, the media URL may have become
invalid.
Fix this by limiting readahead to 50% even if unnecessary. The only
exception is when the whole file would fit in the cache. In this case,
it won't matter if we can't reconnect, because the cache covers
everything anyway, and hopefully the cache will stay valid.
Likely fixes #2000.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This must have been some non-sense in the original vaapi mplayer patch.
While I still have no good idea what this "direct mapping" business is
about, it appears to be pretty much pointless. Nothing can hold
additional "real" surface references (due to how the API and mpv/lavc
refcounting work), so removing the additional surfaces won't break
anything. It still could be that this was for achieving additional
buffering (not reusing surfaces as soon), but we buffer some additional
data anyway. Plus, the original intention of the vaapi mplayer code was
probably increasing surface count just by 1 or 2, not actually doubling
it, and/or it was a "trick" to get to the maximum count of 21 when h264
is in use.
gstreamer-vaapi uses "ref_frames + SCRATCH_SURFACES_COUNT" here, with
SCRATCH_SURFACES_COUNT defined to 4. It doesn't appear to check the
overlay attributes at all in the decoder.
In any case, remove this non-sense.
|
| |
|
|
|
|
|
|
|
| |
It polluted the global namespace, instead of exporting the function
properly.
For now, keep it compatible by explicitly keeping the bogus export.
Also fix a mistake in the manpage example.
|
| |
|
|
|
|
|
| |
On hw decoder reinit failure we did not actually always return a sw
format, because the first format (fmt[0]) is not always a sw format.
This broke some cases of fallback. We must go through the trouble to
determine the first actual sw format.
|
| |
|
|
|
|
|
|
| |
This reduces spam while preempted a bit.
The remaining message, "hardware accelerator failed to decode picture"
on every frame, can not be prevented because it's hardcoded in
libavcodec.
|
| |
|
|
|
|
|
|
|
|
| |
If gl_hwdec_driver.map_image fails, all textures will be set to 0. This
in turn makes pass_prepare_src_tex() skip generation of the texture
uniforms, which leads to a shader compilation error, as e.g. texture0 is
not defined but expected to exist and accessed.
Set the textures to an invalid non-0 ID instead. OpenGL can deal with
it.
|
| |
|
|
|
|
|
|
|
| |
Yet another of these dozens of hwaccel changes. This time, libavcodec
provides utility functions, which initialize the vdpau decoder and map
codec profiles. So a lot of work the API user had to do falls away.
This also will give us support for high bit depth profiles, and possibly
HEVC once libavcodec supports it.
|
| |
|
|
| |
vdpau.c will be used for new code.
|
| |
|
|
|
|
| |
...instead of relying on the hw decoding API to align it for us. The old
method could in theory have gone wrong if the video is cropped by an
amount large enough to step over several blocks.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Always configure the vdpau mixer based on the current surface sent to
it. Before this, we just hardcoded the chroma type, and the surface size
was essentially a guess.
Calling VdpVideoSurfaceGetParameters() on every surface is a bit
suspicious, but it appears it's a cheap function (just requiring some
locks and a table lookup). This way we avoid creating another
complicated mechanism to carry around the actual surface parameters
with a mp_image/AVFrame.
|
| |
|
|
|
|
|
| |
There's not much of a reason to keep get_surface_hwdec() and
get_buffer2_hwdec() separate. Actually, the way the mpi->AVFrame
referencing is done makes this confusing. The separation is probably
an artifact of the pre-libavcodec-refcounting compatibility glue.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of hardware decoding is initialized lazily. When the first packet
is parsed, libavcodec will call get_format() to check whether hw or sw
decoding is wanted. Until now, we've returned AV_PIX_FMT_NONE from
get_format() if hw decoder initialization failed. This caused the
avcodec_decode_video2() call to fail, which in turn let us trigger the
fallback. We didn't return a sw format from get_format(), because we
didn't want to continue decoding at all. (The reason being that full
reinitialization is more robust when continuing sw decoding.)
This has some disadvantages. libavcodec vomited some unwanted error
messages. Sometimes the failures are more severe, like it happened with
HEVC. In this case, the error code path simply acted up in a way that
was extremely inconvenient (and had to be fixed by myself). In general,
libavcodec is not designed to fallback this way.
Make it a bit less violent from the API usage point of view. Return a sw
format if hw decoder initialization fails. In this case, we let
get_buffer2() call avcodec_default_get_buffer2() as well. libavcodec is
allowed to perform its own sw fallback. But once the decode function
returns, we do the full reinitialization we wanted to do.
The result is that the fallback is more robust, and doesn't trigger any
decoder error codepaths or messages either. Change our own fallback
message to a warning, since there are no other messages with error
severity anymore.
|
| |
|
|
|
|
|
|
|
|
|
| |
Vobsubs come as .idx/.sub pair of files. The .idx file is the one that
should be opened, but the name of the .sub file is unknown. We can now
make our own guess what the name of that file is. In particular, improve
support with URLs (as these can have the file extension in the middle of
the filename string if there are HTTP parameters).
Note that this works only with newer ffmpeg versions, because the
recently added sub_name demuxer option is used for this.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This command has been deprecated in the 0.8.x and 0.9.x releases - get
rid of it. Its only point ever was MPlayer compatibility, which broke
years ago anyway.
|
| |
|
|
| |
It has been deprecated for ages.
|
| |
|
|
|
| |
There is not much of a reason to do this later. (Since some time ago,
the input_ctx is created right at the start, so this can be done now.)
|
| |
|
|
| |
This is about as early as possible.
|
| |
|
|
|
| |
As suggested by haasn. The term "full range" makes it sound like it has
to do with TV vs. PC range, which is not the case at all.
|
| |
|
|
|
| |
libmpv can be embedded in a cocoa view (without the mpv window). This has been
the case for serveral months, and the comment is just wrong now.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
They're completely orthogonal concepts, merged in the past due to
convenience and ease of implementing it in the old #ifdef hell renderer.
Especially after the CMS stuff was generalized by 634b4a, this was a
trivial change to implement and also means color management will be much
higher quality when enabled with vo=opengl (which had quantization
issues in the past due to the 8 bit FBO format and upscaling), since it
can be done in a single pass now.
|
| |
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
While all functions of input_ctx are inherently thread-safe, access to
the _inputContext field itself is not. It could be unset any time by
cocoa_set_input_context(). So even trivial input_ctx calls must be under
a lock, so that the input_ctx can not be destroyed while the function
call is "starting". (Even a function call in progress wouldn't be fine,
because mp_input_uninit() requires the caller to "own" the object, i.e.
no other threads can access it at this point.)
|
wm4
Rudolf Polzer
Filip Milivojevic
Marcin Kurczewski
Stefano Pigozzi
Niklas Haas