1
0
mirror of https://github.com/mpv-player/mpv synced 2024-12-22 06:42:03 +00:00
Commit Graph

38620 Commits

Author SHA1 Message Date
wm4
0cce8fe64f audio: fix A/V sync in encoding mode
In encoding mode, the AO pretends to be infinitely fast (it will take
whatever we write, without ever rejecting input). Commit 261506e3 broke
this somehow. It turns out an old hack dealing with this was accidentally
dropped.

This is the hunk of code whose semantics were (partially) dropped:

    if (mpctx->d_audio && (mpctx->restart_playback ? !video_left :
                           ao_untimed(mpctx->ao) && (mpctx->delay <= 0 ||
                                                     !video_left)))
    {
        int status = fill_audio_out_buffers(mpctx, endpts);
        // Not at audio stream EOF yet
        audio_left = status > -2;
    }

This if condition is pretty wild, and it looked like it was pretty much
for audio-only mode, rather than subtle handling for encoding mode.
2014-07-31 04:49:44 +02:00
wm4
a1b54d3b89 client API: don't send internal events to the clients
"Internal" events were added in the previous commits to leverage the
client API property mechanism, without making weird properties public.

But they were sent to clients too (and returned by mpv_wait_event()).
2014-07-31 04:35:23 +02:00
wm4
c1b64cc693 command: add cache-idle property 2014-07-31 04:25:39 +02:00
wm4
b4f24544bb client API: make "cache" property and similar observable
Achieve this by polling. Will be used by the OSC. Basically a bad hack -
but the point is that the mpv core itself is in the best position to
improve this later.
2014-07-31 04:19:41 +02:00
wm4
aaa90e1a33 client API: fix deadlock when calling mpv_terminate_destroy before init
This is perfectly allowed, but was ignored, because it's a corner case.

It doesn't actually wait for other clients to be destroyed, but on the
other hand I think there's no way to have other clients before
initialization.

CC: @mpv-player/stable
2014-07-31 03:12:18 +02:00
wm4
dacbaea1a8 player: rename a variable
Make it clear that this condition happens when switching to a new
timeline segment. It doesn't even need to coincide with a chapter.
2014-07-30 23:29:01 +02:00
wm4
1423bd0bfd player: move video display code out of the playloop
Basically move the code from playloop.c to video.c. The new function
write_video() now contains the code that was part of run_playloop().

There are no functional changes, except handling "new_frame_shown"
slightly differently. This is done so that we don't need new a new
MPContext field or a return value for write_video() to signal this
condition. Instead, it's handled indirectly.
2014-07-30 23:29:00 +02:00
wm4
8f2e9f1d61 player: split seek_reset()
This also reduces some code duplication with other parts of the code.

The changfe is mostly cosmetic, although there are also some subtle
changes in behavior. At least one change is that the big desync message
is now printed after every seek.
2014-07-30 23:29:00 +02:00
wm4
c38013bffb video: actually flush filter chain
Frames buffered in filters weren't flushed, so on EOF, the last frames
were dropped, depending on how much filters buffered. Oops.

Test case: "mpv something.jpg --vf=buffer"
2014-07-30 23:29:00 +02:00
wm4
f8ab732ac3 video/filter: add vf_buffer
Mostly useful for debugging.
2014-07-30 23:29:00 +02:00
wm4
8d990408d7 audio: better sync behavior on bogus EOF
In situations when the demuxer reports EOF, but immediately "recovers"
after that and returns new data, it could happen that audio sync was
skipped. Deal with this by actually entering the EOF state, instead of
assuming this will happen later.
2014-07-30 23:29:00 +02:00
wm4
6afa1a2afc ao_alsa: disable use of non-interleaved formats by default
Some ALSA plugins take non-interleaved audio, but treat it as
interleaved, which results in various funny bugs. Users keep hitting
this issue, and it just doesn't seem worth the trouble.

CC: @mpv-player/stable
2014-07-30 23:28:44 +02:00
Stefano Pigozzi
c3d15b50b4 cocoa: fix key equivalent dispatching
Prior to this commit we had a list of key modifiers and checked against that.
Actually, the Cocoa framework has a built in way to do it and it involves
calling performKeyEquivalent: on the menu instance.

Fixes 

cc @mpv-player/stable: this should apply with no conflicts
2014-07-30 11:26:49 +02:00
wm4
471dfba018 client API: fix typos in documentation 2014-07-30 03:33:37 +02:00
wm4
0dd5228626 demux_lavf: don't consider EAGAIN as EOF condition
This happens apparently randomly with rtmp:// and after seeks. This
eventually leads to audio decoding returning an EOF status, which
basically disables audio sync. This will lead to audio desync, even if
audio decoding later "recovers" when the demuxer actually returns audio
packets.

Hack-fix this by special-casing EAGAIN.
2014-07-30 03:32:56 +02:00
wm4
6856d81c68 stream: hack-fix rtmp-level seeking
This didn't work, because the timebase was wrong. According to the
ffmpeg doxygen, if the stream index is -1 (which is what we used), the
timebase is AV_TIME_BASE. But this didn't work, and it really expected
the stream's timebase. Quite "surprising", since this feature
(avio_seek_time) is used by rtmp only.

Fixing this properly is too hard, so hack-fix our way around it.
STREAM_CTRL_SEEK_TO_TIME is also used by DVD/BD, so a new
STREAM_CTRL_AVSEEK is added. We simply pass-through the request
verbatim.
2014-07-30 02:21:51 +02:00
wm4
26d973ce82 stream_lavf: allow setting AVOptions with --stream-lavf-o
This commit also creates a private option struct for stream_lavf.c, but
since I'm lazy, I'm not moving any existing options to it.
2014-07-30 01:15:42 +02:00
wm4
da780309d7 audio: better initial sync for files where audio starts later
Some files have the first audio much later into the video (for whatever
reasons). Instead of appending large amounts of silence to the audio
buffer (and refusing to sync if the audio to append is "too large"),
just wait until enough video has played.
2014-07-30 00:40:45 +02:00
wm4
1cd2b5976d audio: cosmetics: remove unused return value 2014-07-30 00:24:57 +02:00
wm4
6b928fa2a0 demux_mf: allow seeking past the end
How's this for a corner case.
2014-07-30 00:23:16 +02:00
wm4
593ad996e0 player: fix time display wheen seeking past EOF with --keep-open
Regression since commit 261506e3. Internally speaking, playback was
often not properly terminated, and the main part of handle_keep_open()
was just executed once, instead of any time the user tries to seek. This
means playback_pts was not set, and the "current time" was determined by
the seek target PTS.

So fix this aspect of video EOF handling, and also remove the now
unnecessary eof_reached field.

The pause check before calling pause_player() is a lazy workaround for
a strange event feedback loop that happens on EOF with --keep-open.
2014-07-30 00:22:38 +02:00
wm4
b6a7c321db player: let explicitly imprecise seeks cancel precise seeks
If an imprecise seek is issues while a precise seek is ongoing,
don't wait up to 300ms (herustistic which usually improves user
experience), but instead let it cancel the seek.

Improves responsiveness of the OSC after the previous commit.

Note that we don't do this on "default-precise" seeks, because we
don't know if they're going to be precise or not.
2014-07-29 20:04:08 +02:00
ChrisK2
48f4f791f4 osc: Do precise seeks on simple clicks on seekbar 2014-07-29 19:26:32 +02:00
wm4
63d1d53d2f audio: ignore (some) decoding errors on initialization
It probably happens relatively often that the first packet (or even the
first N packets) of a stream will fail to decode, but decoding will
eventually succeed at a later point. Before commit 261506e3, this was
handled by an explicit retry loop (although this was also for other
purposes), but with then was changed to abort on the first error. This
makes it impossible to decode some audio streams.

Change this so that errors are ignored for the first 50 packets, which
should make it equivalent to the old code.
2014-07-29 18:05:55 +02:00
wm4
862d7d8a1a player: fix desync when seeking and switching external tracks
If you for example use --audio-file, disable the external track, seek,
and enable the external track again, the playback position of the
external file was off, and you would get major A/V desync. This was
actually supposed to work, but broke at some time ago (probably commit
2b87415f). It didn't work, because it attempted to seek the stream if it
was already selected, which was always true due to
reselect_demux_streams() being called before that.

Fix by putting the initial selection and the seek together.
2014-07-29 17:55:28 +02:00
wm4
6d15c491b0 player: remove a pointless field 2014-07-29 01:00:54 +02:00
wm4
25ceb3289d player: disable hr-seek in .ts files
Seeking in .ts files (and some other formats) is too unreliable, so
there's a separate code path for this case. But it breaks hr-seek.

Maybe hr-seek could actually be enabled in this case if we're careful
enough about timestamp resets, but for now nothing changes.
2014-07-29 00:59:00 +02:00
wm4
d6445d7ab6 player: allow precise seeking with percent seeks
I'm not sure why this was explicitly disabled. It's from mplayer2 times.
2014-07-29 00:26:52 +02:00
wm4
ecad4a20de manpage: lua: document timer timeout and oneshot fields
Might be useful for scripts, so document them. (Which means scripts
are allowed to use them, without risking breakage.)
2014-07-29 00:22:21 +02:00
wm4
fa34b4920a vdpau: don't upload video images in advance
With software decoding, images were uploaded to vdpau surfaces as they
were queued to the VO. This makes it slightly more complicated
(especially later on), and has no advantages - so stop doing it.

The only reason why this was done explicitly was due to attempts to keep
the code equivalent (instead of risking performance regressions). The
original code did this naturally for certain reasons, but now that we
can measure that it has no advantages and just requires extra code, we
can just drop it.
2014-07-29 00:21:02 +02:00
wm4
d563dc8cb9 player: update playback position on seek
If the actual PTS is not known yet right after a seek, the "time-pos"
property will just return the seek target PTS. For this purpose, trigger
a change event to make the client API update the "time-pos" and related
properties. (MPV_EVENT_TICK triggers this update.)
2014-07-29 00:20:54 +02:00
wm4
846257da13 player: logically speed up seek logic
Commit 261506e3 made constant seeking feel slower, because a subtle
change in the restart logic makes it now waste time showing another
video frame. The slowdown is about 20%.

(Background: the seek logic explicitly waits until a video frame is
displayed, because this makes it easier for the user to search for
something in the video. Without this logic, the display would freeze
until the user stops giving seek commands.)

Fix this by letting the seek logic issue another seek as soon as the
first video frame is displayed. This will prevent it from showing a
(useless, slow) second frame. Now it seems to be as fast as before the
change.

One side-effect is that the next seek happens after the first video
frame, but _before_ audio is restarted. Seeking is now silent. I guess
this is ok, so we don't do anything about it. Actually, I think whether
this happens is probably random; the seeking logic simply doesn't make
this explicit, so anything can happen.
2014-07-28 22:13:42 +02:00
wm4
26bfcc9c82 vo_x11: fix build with older Libav versions
Why does this happen everytime...
2014-07-28 21:48:43 +02:00
Niklas Haas
d0a8b571c9 video: add a default color space for files with no video
Usually mp_image_params_guess_csp takes care of finding *some* default
for a video channel, but files with no video (or with extremely broken
configurations) end up leaving the colorspace information as
MP_CSP_PRIM_AUTO, which has no associated primaries.

As a result of this, color managed OSD messages could not display
because they were being color managed to match the (non-existing/absurd)
video channel. With this change, such non-spaces will have BT.709
primaries as far as color management and the OSD is concerned.

This fixes .

CC: @mpv-player/stable

Signed-off-by: wm4 <wm4@nowhere>
2014-07-28 21:24:44 +02:00
wm4
261506e36e audio: change playback restart and resyncing
This commit makes audio decoding non-blocking. If e.g. the network is
too slow the playloop will just go to sleep, instead of blocking until
enough data is available.

For video, this was already done with commit 7083f88c. For audio, it's
unfortunately much more complicated, because the audio decoder was used
in a blocking manner. Large changes are required to get around this.
The whole playback restart mechanism must be turned into a statemachine,
especially since it has close interactions with video restart. Lots of
video code is thus also changed.

(For the record, I don't think switching this code to threads would
make this conceptually easier: the code would still have to deal with
external input while blocked, so these in-between states do get visible
[and thus need to be handled] anyway. On the other hand, it certainly
should be possible to modularize this code a bit better.)

This will probably cause a bunch of regressions.
2014-07-28 21:20:37 +02:00
wm4
58255e0e2b input: be stricter about rejecting mouse input with --no-input-cursor
Apparently this switch means all mouse input should be strictly
rejected. Some VO backends (such as X11) explicitly disable all mouse
events if this option is set, but others don't. So check them in
input.c, which increases consistency.
2014-07-27 22:00:55 +02:00
wm4
4c533fbb16 vo: remove vo_mouse_movement() wrapper
So that VO backends don't have to access the VO just for that.
2014-07-27 21:53:29 +02:00
wm4
89391e7c94 vo: different hack for VOs which need to mangle mouse input
Follow up on commit 760548da. Mouse handling is a bit confusing, because
there are at least 3 coordinate systems associated with it, and it
should be cleaned up. But that is hard, so just apply a hack which gets
the currently-annoying issue (VO backends needing access to the VO) out
of the way.
2014-07-27 21:33:11 +02:00
wm4
bc6359313f ao_pulse: allow disabling timing bug workarounds
Add an option that enables using native PulseAudio auto-updated timing
information, instead of the manual calculations added in mplayer2 times.
You can use --ao=pulse:no-latency-hacks to enable the new code. The code
is almost the same as the code that was removed with commit de435ed5,
but I didn't readd some bits I didn't understand. Likewise, the option
will disable the code added with that commit.

In my tests this seemed to work well, though the A/V sync display looks
funny when seeking.

The default is still the old behavior.

See issue .
2014-07-26 23:20:09 +02:00
wm4
77d9e4b8a9 ao_pulse: remove hacks for ancient PulseAudio versions
This was needed by very old (0.9) versions only. Get rid of it.

Unfortunately, I can't cross-check with the original bug report, since
the bug URL leads to this:

Internal Server Error

TracError: IOError: [Errno 2] No such file or directory: '/home/lennart/svn/trac/pulseaudio/VERSION'
2014-07-26 23:19:48 +02:00
wm4
3c7675ae9a manpage: eliminate the word "movie"
It's evil and sounds outdated. Use the words "media" and "video"
instead.

Closes .
2014-07-26 23:19:47 +02:00
wm4
025431a7ae win32: remove minor non-sense
This is done in the wrong thread. Was harmless and had no effect at all.
2014-07-26 23:19:43 +02:00
wm4
97a82bcd56 win32: move window handling to a separate thread
The windows message loop now runs in a separate thread. Rendering,
such as with Direct3D or OpenGL, still happens in the main thread.

In particular, this should prevent the video from freezing if the
window is dragged. (The reason was that the message dispatcher won't
return while the dragging is active, so mpv couldn't update the
video at all.)

This is pretty "rough" and just hacked in, and there's no API yet to
make this easier for other backends. It will be cleaned up later
once we're sure that it works, or when we know how exactly it should
work. One oddity is that OpenGL is actually completely managed in the
renderer thread, while e.g. Cocoa (which has its own threading code)
creates the context in the GUI thread, and then lets the renderer
thread access it.

One strange issue is that we now have to stop WM_CLOSE from actually
closing the window. Instead, we wait until the playloop handles the
close command, and requests the VO to shutdown. This is done mainly
because closing the window apparently destroys it, and then WM_USER
can't be handled anymore - which means the playloop has no way to
wakeup the GUI thread. It seems you can't really win here... maybe
there's a better way to have a thread receive messages with and
without a window, but I didn't find one yet.

Dragging the window (by clicking into the middle of it) behaves
strangely in wine, but didn't before the change. Reason unknown.
2014-07-26 20:36:46 +02:00
wm4
760548da28 vo: hack to avoid threading issues with mouse input
VO backends which are or will run in their own thread have a problem
with vo_mouse_movement() calling vo_control(). Restrict this to VOs
which actually need this.
2014-07-26 20:31:26 +02:00
wm4
3f268cc4f2 win32: use gcc TLS instead of WM_NCCREATE tricks for window context
win32 does not provide a proper per-window context pointer. Although it
does allow passing a user-chosen value to WM_CREATE/WM_NCCREATE, this
is not enough - the first message doesn't even have to be WM_NCCREATE.
This gets us in trouble later on, so go the easy route and just use a
TLS variable.

__thread is gcc specific, but Windows is a very "special" platform
anyway. We support only MinGW and Cygwin on it, so who cares. (C11
standardizes __thread as _Thread_local; we can use that later.)
2014-07-26 20:30:52 +02:00
wm4
559fe1daac Add Plan 9-style barriers
Plan 9 has a very interesting synchronization mechanism, the
rendezvous() call. A good property of this is that you don't need to
explicitly initialize and destroy a barrier object, unlike as with e.g.
POSIX barriers (which are mandatory to begin with). Upon "meeting", they
can exchange a value.

This mechanism will be nice to synchronize certain stages of
initialization between threads in the following commit.

Unlike Plan 9 rendezvous(), this is not implemented with a hashtable,
because that would require additional effort (especially if you want to
make it actually scele). Unlike the Plan 9 variant, we use intptr_t
instead of void* as type for the value, because I expect that we will be
mostly passing a status code as value and not a pointer. Converting an
integer to void* requires two cast (because the integer needs to be
intptr_t), the other way around it's only one cast.

We don't particularly care about performance in this case either. It's
simply not important for our use-case. So a simple linked list is used
for waiters, and on wakeup, all waiters are temporarily woken up.
2014-07-26 20:29:48 +02:00
wm4
8ed6d298c5 win32: make a flag explicit
This shouldn't change anything. But it's worth making this explicit,
since it's very subtle and unintuitive: if the X parameter is the
magic value CW_USEDEFAULT, then the Y parameter is used as nCmdShow
parameter to ShowWindow(). And in our case, this is SW_HIDE (0),
because we want to create a hidden window.
2014-07-26 20:29:18 +02:00
wm4
9969694ece win32: simplify some --wid embedding code
This looked a bit overcomplicated. We don't care about the window
position (it should always be 0/0, unless the parent program moved it,
which it shouldn't). We don't care about the global on-screen position.
Also, we will just retrieve a WM_SIZE message if our window is resized,
and we don't need to update it manually.

The only thing we have to do is making sure our window fills the parent
window completely.
2014-07-26 20:28:36 +02:00
wm4
9a3f1f24ca win32: don't use CS_OWNDC
CS_OWNDC will make GetDC() always return the same HDC. This might
become a problem when OpenGL rendering and window management are
on different threads. Although I'm not too sure about this; our
code never requests a HDC outside of the OpenGL backend, and it
depends on whether win32 will internally request DCs. But in any
case, this seems to be cleaner.

Move the GL pixelformat setup code to gl_w32.c, where it's actually
needed. This also fixes that SetPixelFormat() should be called only
once, and not every time video params change.
2014-07-26 20:28:01 +02:00
wm4
7f0d9a95fa win32: remove worthless doxygen comments
These mostly describe self-explanatory things, and fail to explain
actually tricky things. Which means you just waste your time reading
this, and have to figure it out from the code anyway.
2014-07-26 20:27:57 +02:00