| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This was previously duplicated between the reset/resume functions, and
not properly handled in the "impossible" invalid thread state case.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This eliminates some intermittent pops heard in a HRT MicroStreamer DAC
uncorrelated with user interaction. As a bonus, this resolves #1773 which I can
o longer reproduce as of this commit. Leave the 50ms buffer for shared mode
since that seems to be working quite well.
This is also the way exclusive mode is done in the MSDN example code:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd370844%28v=vs.85%29.aspx
This was originally increased in c545c40 to mitigate glitches that subsequent
refactorings have eliminated.
|
|
|
|
|
|
|
|
|
|
| |
A COM message loop is apparently totally inappropriate for a low latency
thread. It leads to audio glitches because the thread doesn't wake up fast
enough when it should. It also causes mysterious correlations between the vo
and ao thread (i.e., toggling fullscreen delays audio feed events). Instead use
an mp_dispatch_queue to set/get volume/mute/session display name from the audio
thread. This has the added benefit of obviating the need to marshal the
associated interfaces from the audio thread.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't wait for WASAPI to send another feed event if we detect an underfull
buffer. It seems that WASAPI doesn't always send extra feed events if
something causes rendering to fall behind. This causes every subsequent playback
buffer to under-run until playback is reset. The fix is simply to do a one-shot
double feed when this happens, which allows rendering to catch up with playback.
This was observed to happen when using MsgWaitForMultipleObjects to wait for the
feed event and toggling fullscreen with vo=opengl:backend=win. This commit
improves the behaviour in that specific case and more generally makes exclusive
mode significantly more robust.
This commit also moves the logic to avoid *over*filling the exclusive mode
buffer into thread_feed right next to the above described underfil logic.
|
| |
|
| |
|
|
|
|
| |
Pretty useful for debugging surround nonsense.
|
|
|
|
|
|
|
|
| |
OpenSL ES is used on Android. At the moment only stereo output is
supported. Two options are supported: 'frames-per-buffer' and
'sample-rate'. To get better latency the user of libmpv should pass
values obtained from AudioManager.getProperty(PROPERTY_OUTPUT_FRAMES_PER_BUFFER)
and AudioManager.getProperty(PROPERTY_OUTPUT_SAMPLE_RATE).
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Report the underlying demuxer's format. Since there can be many demuxers
participating, pick the "main" segment.
|
|
|
|
|
| |
Instead of having reselect_demux_streams() look at all streams, make it
look at the current stream that is being enabled/disabled.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
_Of course_ the previous commit broke --force-window behavior (like it
does every single time I touch it).
vo_has_frame() gets cleared after a seek, so e.g. stopping playback of a
file and going to the next by keeping the seek key down will enter a
short moment without video at the end of the first file, which will set
the stalled_video variable to true. Prevent it by using the indication
whether the window was properly created (which is probably exactly what
we want here).
This function is also responsible for destroying the window when needed,
and obviously we should never do that while video is active. (This is
the actual bug, although the other change in this commit already hides
the common breakage it caused.)
|
|
|
|
|
| |
If a video track is selected, but no video is decoded from it (mostly
with broken files), then create the window anyway.
|
|
|
|
|
|
|
|
|
| |
If a stream is marked as EOF (due to no packets found in reach), then we
need to wakeup the decoder. This is important especially if no packets
are found at the start of the file, so the A/V sync logic actually
starts playback, instead of waiting for packets that will never come.
(It would randomly start playback when running the playback loop due to
arbitrary external events like user input.)
|
|
|
|
|
| |
It's used to interpolate timestamps for sub-packets ("block laces").
It's occasionally broken, and not really needed by us.
|
|
|
|
|
| |
Commit 2f562825 didn't remove the "color" declaration for these. Since
the shader header already declares it, shader compilation broke.
|
|
|
|
|
| |
This is the unfortunate video timer; it's already reset when it actually
matters (after video was prepared and before video is actually started).
|
|
|
|
|
| |
No need for this crazy loop anymore, and we can simply enable it for
each demuxer when it's opened.
|
|
|
|
|
|
|
| |
It was just dead code.
Also fixes the stream-open-filename property, which is supposed to be
read-only if a file was already opened.
|
|
|
|
|
|
| |
Some oddity that is not needed anymore. The only thing which still
referenced them was avoiding loading external files more than once,
which is now prevented by checking the list of tracks instead.
|
|
|
|
|
|
| |
Why was this done so stupidly, with so many complicated special cases,
before? Declare it once so the shader bits don't have to figure out where
and when to do so themselves.
|
|
|
|
|
| |
pixel_size is often used variable, also reciprocal is a costly operation
for AMD and older nVidia (prior to Kepler) GPUs.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Commit 943f76e6, which already tried this, was very stupid: it didn't
actually override the samplerate for Opus, but overrode it for all
codecs other than Opus. And even then, it failed to use the overridden
samplerate. (Sigh...)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes relative seeks. Without this, a seek back could skip so much data
that the seek would effectively jump forward. (Or insert silence for
files with video.)
There's the question whether the frontend should do this instead (by
using information from the decoders), but for now this seems more
proper.
demux_mkv.c does this already, sort of.
libavformat doesn't for seeks in .ogg (aka .opus), but might be doing it
for mkv. Seems to be a mess as well.
|
|
|
|
| |
Slight simplification/cleanup.
|
|
|
|
|
|
|
|
| |
Fixes correctness_trimming_nobeeps.opus. One nasty thing is that this
mechanism interferes with the container-signalled mechanism with
AV_FRAME_DATA_SKIP_SAMPLES. So apply it only if that is apparently not
present. It's a mess, and it's still broken in FFmpeg CLI, so I'm sure
this will get fucked up later again.
|
|
|
|
|
|
| |
I'm not quite sure what the FFmpeg AV_FRAME_DATA_SKIP_SAMPLES API
demands here. The code so far assumed that skipping can be more than a
frame, but not trimming. Extend it to trimming too.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is actually already done by dec_audio.c. But if
AV_FRAME_DATA_SKIP_SAMPLES is applied, this happens too late here. The
problem is that this will slice off samples, and make it impossible for
later code to reconstruct the timestamp properly.
Missing timestamps can still happen with some demuxers, e.g. demux_mkv.c
with Opus tracks. (Although libavformat interpolates these itself.)
|
| |
|
|
|
|
|
|
|
| |
I think the conclusion is that AV_PKT_DATA_SKIP_SAMPLES is misdesigned
(at least for some formats), and an alternative mechanism using
durations would be better. (Combining it with a proper timebase would
keep sample-accuracy.)
|
| |
|
|
|
|
| |
The actual location of input.conf the user has to find out himself.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This happens only if the new segment wasn't read yet.
This is not quite proper and a problem with dec_sub.c internals.
Ideally, it'd wait with rendering until a new enough segment has been
read. Normally, the new segment is available immediately, so the end
will be automatically clipped by switching to the right segment in the
exact moment it's supposed to become effective.
Usually shouldn't cause any problems, though.
|
|
|
|
|
| |
You can e.g. reference ordered chapters or other EDL files in EDLs.
There were some bugs left which broke this in some cases.
|
|
|
|
|
| |
Instead of checking whether the format is a hwaccel format, check
whether it's the exact format we've requested for hardware decoding.
|
|
|
|
|
|
|
|
|
|
|
| |
Doing --hwdec=auto ends up picking dxva2, creating a decoder, and then
sending D3D frames down the video chain, which immediately fails and
falls back to software.
Consider dxva2 only if the VO provides a context. If this fails,
autoprobing will proceed to try dxva2-copy as usual.
Fixes #2844.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is in preparation for a hypothetical API change in libavcodec,
which would allow the decoder to return multiple video frames before
accepting a new input packet.
In theory, the body of the if() added to vd_lavc.c could be replaced
with this code:
packet->buffer += ret;
packet->len -= ret;
but currently this is not needed, as libavformat already outputs one
frame per packet. Also, using libavcodec this way could lead to a
"deadlock" if the decoder refuses to consume e.g. garbage padding, so
enabling this now would introduce bugs.
(Adding this now for easier testing, and for symmetry with the audio
code.)
|
|
|
|
|
|
|
|
|
|
| |
There is some strange code which sets the DTS of the packet to PTS (but
only if it's not AVI), which apparently helps with timestamp
determination with some broken files. This code is annoying because it
tries to avoid mutating the packet (which it logically doesn't own).
Move it to where it does and get rid of the packet_copy mess.
Needed for the following commit.
|
|
|
|
|
|
|
| |
This tries to determine whether packet PTS values are accurate and can
be used for frame dropping during seeking. Move both checks (PTS is
missing; PTs is non-monotonic) to the earliest place where they can be
done.
|
|
|
|
|
|
| |
Accidental leftover from commit ae55896f. (This seek ised to be done
with ordered chapters, and was accidentally changed to always being
done.)
|
|
|
|
|
|
|
|
|
|
|
| |
The WGL_NV_DX_interop spec says that a shared IDirect3DSurface9 must not
be lockable, but off-screen plain surfaces are always lockable and using
them causes Nvidia drivers to crash. Use a rendertarget for the shared
surface instead.
This also changes the name of the DX_interop handle for the rendertarget
to match the name of the DirectX object (rather than the GL one) to
match the convention used in context_dxinterop.c.
|
|
|
|
|
|
| |
This file was rewritten from scratch in 0cef033, so it should be okay.
As mentioned in #730, it's a complete rewrite referencing only MSDN and
POSIX, rather than the original code.
|
|
|
|
|
| |
p->gl_target and plane->gl_target are always the same value here, but
semantically plane->gl_target is the correct one.
|
|
|
|
| |
Fixes #2831.
|
|
|
|
|
|
|
|
| |
Apple crap (namely hardware decoding interop) forces us to use rectangle
textures for input. But after that we continue with normal textures.
This was not considered for debanding, and the sampler type used for it
can be different depending on the exact render chain. Simply use the
target type of the input texture.
|
|
|
|
| |
Wasn't really necessary as it was equivalent to gl-dxinterop.
|
|
|
|
|
| |
Use dxva2 surface to fill RGB IDirect3DSurface9 shared with opengl via
DXRegisterObjectNV.
|
|
|
|
|
| |
This always falls back to software decoding right now. VO support will be added
in future commits.
|
|
|
|
|
|
|
| |
* use mp_HRESULT_to_str/mp_LastError_to_str
* make some messages non-identical
* replace "GL" -> "OpenGL"
* change some MP_FATAL to MP_ERR that don't actually kill the vo
|
|
|
|
|
|
| |
This is useful in particular for GetLastError, unfortunately, it's stil pretty
dumb with regards to WASAPI or D3D specific errors, so keep the
hresult_to_string switch.
|
|
|
|
|
|
|
| |
The new code is essentially equivalent, but compiles against older
ffmpeg.
Fixes #2832.
|
| |
|
|
|
|
|
| |
This makes it more explicit that the pool doesn't ever actually do any
allocating itself.
|
|
|
|
| |
previously, this may have caused a leak
|
|
|
|
|
|
|
|
|
|
| |
Apparently, some drivers require you to allocate all of the decoder d3d surfaces
at once. This commit changes the strategy from allocating surfaces as needed via
mp_image_pool_set_allocator, to allocating all the surfaces in one call to
IDirectXVideoDecoderService_CreateSurface and adding them to the pool with
mp_image_pool_add.
fixes #2822
|
|
|
|
|
|
| |
Provide a way for the user to add mp_images to the pool. This is required for
dxva2, for which using set_allocator is extremely awkward since all the d3d9
surfaces must be allocated in advance and all together.
|
|
|
|
|
|
| |
I mistakenly copied the wrong license text into these files when
I created them. Since I'm the only one to have touched these files,
it should be OK to change them.
|
|
|
|
| |
Gets rid of a forward declaration.
|
|
|
|
|
|
|
|
| |
This is achieved indirectly by deslecting all streams for the non-
current segment (and if the segment doesn't share the demuxer with the
currently active one).
Restores functionality added with commit 46bcdb70.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This uses a different method to piece segments together. The old
approach basically changes to a new file (with a new start offset) any
time a segment ends. This meant waiting for audio/video end on segment
end, and then changing to the new segment all at once. It had a very
weird impact on the playback core, and some things (like truly gapless
segment transitions, or frame backstepping) just didn't work.
The new approach adds the demux_timeline pseudo-demuxer, which presents
an uniform packet stream from the many segments. This is pretty similar
to how ordered chapters are implemented everywhere else. It also reminds
of the FFmpeg concat pseudo-demuxer.
The "pure" version of this approach doesn't work though. Segments can
actually have different codec configurations (different extradata), and
subtitles are most likely broken too. (Subtitles have multiple corner
cases which break the pure stream-concatenation approach completely.)
To counter this, we do two things:
- Reinit the decoder with each segment. We go as far as allowing
concatenating files with completely different codecs for the sake
of EDL (which also uses the timeline infrastructure). A "lighter"
approach would try to make use of decoder mechanism to update e.g.
the extradata, but that seems fragile.
- Clip decoded data to segment boundaries. This is equivalent to
normal playback core mechanisms like hr-seek, but now the playback
core doesn't need to care about these things.
These two mechanisms are equivalent to what happened in the old
implementation, except they don't happen in the playback core anymore.
In other words, the playback core is completely relieved from timeline
implementation details. (Which honestly is exactly what I'm trying to
do here. I don't think ordered chapter behavior deserves improvement,
even if it's bad - but I want to get it out from the playback core.)
There is code duplication between audio and video decoder common code.
This is awful and could be shareable - but this will happen later.
Note that the audio path has some code to clip audio frames for the
purpose of codec preroll/gapless handling, but it's not shared as
sharing it would cause more pain than it would help.
|
| |
|