Commit Graph

111 Commits

Author SHA1 Message Date
wm4 a5f3083ae7 player: adjust A/V desync message
Broken drivers are an issue rather often. Maybe this gives the user an
idea that this could be the reason. (We can't dump much more info on a
80x24 terminal.)
2015-02-26 10:38:37 +01:00
Julian 349067a6ab vf_vapoursynth: add display refresh rate property
This value is not necessarily trustworthy (it might change) and can be
0.
2015-02-13 22:35:47 +01:00
wm4 c3c714b059 player: remove --fixed-vo
In ancient times, this was needed because it was not default, and many
VOs had problems with it. But it was always default in mpv, and all VOs
are required to deal with it. Also, running --fixed-vo=no is not useful
and just creates weird corner cases. Get rid of it.
2015-02-03 23:11:08 +01:00
wm4 5af4c81e5b player: dump audio jitter to stats file
This allows us to plot the difference between video timestamps, and the
adjusted video timestamps due to syncing video to audio speed.
2015-02-01 18:32:26 +01:00
wm4 48f96f43ec player: minor simplification in A/V-sync related code
Just minor things.
2015-01-30 23:49:30 +01:00
wm4 3813c3804f Revert "player: allow seeking audio between video frames"
This reverts commit 7b3feecbc2.

It's broken, hr-seek never ends at a video position before seek pts.
Not sure what I was thinking, although it did work anyway when
artificially forcing a video frame to display before seek pts.
2015-01-30 23:42:01 +01:00
wm4 a7c43babb7 player: print desync message on negative A/V-sync too
At least there is _some_ problem if this happens. It would mean that
audio is playing slower than video. Normally, video is synced to audio,
so if audio stops playback completely, video will not advance at all.
But using things like --autosync, it's well possible that this kind of
desync happens.
2015-01-30 21:26:29 +01:00
wm4 e123c1dfcd player: rearrange some A/V-sync related code
Move the update_avsync_before_frame() call further down. Moving it
closer to where the time_frame value is used (and which the function
updates) should make the code more readable. With this change, there's
no need anymore to reset the time_frame value on the video reconfig
path.

Move the update_avsync_after_frame() up. Now no meaningful amount of
time passes since the previous get_relative_time() call anymore, and the
second one can be removed.
2015-01-30 21:18:30 +01:00
wm4 9d57e7d23c player: use correct type for some relative times
We use double for these things everywhere, just this code didn't. It
likely doesn't matter much, and this code is for an optional feature
too.
2015-01-30 21:10:39 +01:00
wm4 86d4094b98 player: remove redundant variable
mpctx->audio_delay always has the same value as opts->audio_delay. (This
was not the case a long time ago, when the audio-delay property didn't
actually write to opts->audio_delay. I think.)
2015-01-29 15:15:01 +01:00
wm4 7b3feecbc2 player: allow seeking audio between video frames
This allows seeking audio between two video frames that are relatively
far away.

The implementation of this is a bit subtle. It pretend the audio
position is different, and the actual PTS adjustment happens in audio.c
with this line:

    sync_pts -= mpctx->audio_delay - mpctx->delay;

Effectively this is the same as setting sync_pts to hrseek_pts after
this line, though. (I'm actually not sure if this could be written in a
more straightforward way; probably yes.)
2015-01-28 19:40:12 +01:00
wm4 513344648f player: mention mpv encoding support for transcoding in desync. warning 2015-01-19 18:04:45 +01:00
wm4 234d632920 video: fix waiting for last frame/format reconfig
We still need to send the VO a duration in these cases. Disabling
framedrop has logically absolutely nothing to do with these cases; it
was overlooked in commit 918b06c4.

So we always send the frame duration (or a guess for it), and check
whether framedropping is actually enabled in the VO code. (It would
be cleaner to send framedrop as a flag, but I don't care about that
right now.)
2015-01-19 18:02:31 +01:00
wm4 918b06c42c player: respect --untimed on last frame
The last video frame is another case that has a separate code path,
although it's pretty similar to the one in commit 73e5aa87. Fix this
in a different way, which also takes care of the last frame case,
although without context the code becomes slightly more tricky.

As further cleanup, move the decision about framedropping itself to
the same place, so the check in vo.c becomes much simpler. The check
for the vo->driver->encode flag, which is remvoed completely, was
redundant too.

Fixes #1480.
2015-01-16 13:57:33 +01:00
wm4 73e5aa87d1 player: respect --untimed on video format changes
If the video format changes (e.g. different frame size), a special code
path is entered to wait until the currently displayed frame is done.
Otherwise, the frame before the change would be destroyed by the
vo_reconfig() call.

This code path didn't respect --untimed; correct this.

Fixes #1475.
2015-01-16 12:03:04 +01:00
wm4 24c805331d video: fix timeline with some container formats
Using edl or --merge-files with .avi files didn't work, because the DTS
was not offset. Only the PTS was adjusted, which led to nonsense
timestamps.
2015-01-06 19:32:57 +01:00
wm4 a7dddbacc6 video: batch query_format calls
There are currently 568 pixel formats (actually fewer, but the namespace
is this big), and for each format elaborate synchronization was done to
call it synchronously on the VO. This is completely unnecessary, and we
can do with just a single call.
2015-01-03 17:23:01 +01:00
wm4 bfac1e81a6 vf_vapoursynth: pass through container FPS value
This is basically a hack; but apparently a needed one, since many
vapoursynth filters insist on having a FPS set.

We need to apply the FPS override before creating the filters. Also
change some terminal output related to the FPS value.
2015-01-03 03:37:05 +01:00
wm4 f5ed13bcd4 video: better pipelining with vf_vapoursynth
Most of this is explained in the code comments. This change should
improve performance with vapoursynth, especially if concurrent requests
are used.

This should change nothing if vf_vapoursynth is not in the filter chain,
since non-threaded filters obviously can not asynchronously finish
filtering of frames.
2015-01-03 03:01:58 +01:00
wm4 65f2c6c716 vo_opengl_cb: pass context directly
This is simpler than setting the context after VO creation, which
requires the code to check for the context on every entrypoint.
2014-12-31 19:12:44 +01:00
wm4 282e3202d5 video: pass some VO params as struct
Not particularly elegant, but better than adding more and more stuff to
the relevant function signatures.
2014-12-31 19:01:28 +01:00
wm4 7593a1f638 player: fix a typo in message output
This typo has been around for over a year. Oops.
2014-12-24 14:35:04 +01:00
wm4 fb855b8659 client API: expose OpenGL renderer
This adds API to libmpv that lets host applications use the mpv opengl
renderer. This is a more flexible (and possibly more portable) option to
foreign window embedding (via --wid).

This assumes that methods like context sharing and multithreaded OpenGL
rendering are infeasible, and that a way is needed to integrate it with
an application that uses a single thread to render everything.

Add an example that does this with QtQuick/qml. The example is
relatively lazy, but still shows how relatively simple the integration
is. The FBO indirection could probably be avoided, but would require
more work (and would probably lead to worse QtQuick integration, because
it would have to ignore transformations like rotation).

Because this makes mpv directly use the host application's OpenGL
context, there is no platform specific code involved in mpv, except
for hw decoding interop.

main.qml is derived from some Qt example.

The following things are still missing:
- a way to do better video timing
- expose GL renderer options, allow changing them at runtime
- support for color equalizer controls
- support for screenshots
2014-12-09 17:59:04 +01:00
wm4 090f6cfc30 player: when seeking past EOF with --keep-open, seek to last frame
It feels strange that seeking past EOF with --keep-open actually leaves
the player at a random position. You can't even unpause, because the
demuxer is in the EOF state, and what you see on screen is just what was
around before the seek.

Improve this by attempting to seek to the last video frame if EOF
happens. We explicitly don't do this if EOF was reached normally to
increase robustness (if the VO got a frame since the last seek, it
obviously means we had normal playback before EOF).

If an error happens when trying to find the last frame (such as not
actually finding a last frame because e.g. the demuxer misbehaves), this
will probably turn your CPU into a heater. There is no logic to prevent
reinitiating the last-frame search if the last-frame search reached EOF.
(Pausing usually prevents that EOF is reached again after a successful
last-frame search.)

Fixes #819.
2014-12-07 02:47:54 +01:00
wm4 85fb2af369 Remove some superfluous NULL checks
In all of these situations, NULL is logically not allowed, making the
checks redundant.

Coverity complained about accessing the pointers before checking them
for NULL later.
2014-11-21 05:18:09 +01:00
wm4 975e98b3fe player: print anamorphic size only if video is anamorphic
Has been annoying me since forever.
2014-11-02 17:34:02 +01:00
wm4 dab6cbca16 player: update meaning of drop_frame_cnt
Rename the variable, update comments, and update the documentation of
the property which returns its value.
2014-11-01 01:07:21 +01:00
wm4 0e97808fc5 player: show AV-desync message in all framedrop modes
This was shown only if decoder-framedropping was enabled, and only if at
least 50 frames were dropped by it. Since drop_frame_cnt used to mean
"number of late frames", this code made sense, but this is not the case
anymore: drop_frame_cnt can be even 0, all while video gets hopelessly
behind audio.

One problem with this is that short desync spikes (which usually can
probably dealt with) will also cause this message to be shown. If it
gets triggered too often, the code will need to be adjusted.
2014-11-01 01:06:22 +01:00
wm4 65db3291b3 client API: better error reporting
Give somewhat more information on playback failure.
2014-10-28 20:30:12 +01:00
wm4 f4ad398b28 video: send MPV_EVENT_VIDEO_RECONFIG on uninit
This event basically means "something about video changed", and uninit
is certainly an important change.
2014-10-24 15:34:28 +02:00
wm4 c9234d769d player: fix exiting if both audio and video fail initializing
The player was supposed to exit playback if both video and audio failed
to initialize (or if one of the streams was not selected when the other
stream failed). This didn't work; for one this check was missing from
one of the failure paths. And more importantly, both checked the
current_track array incorrectly.

Fix these issues, and move the failure handling code into a common
function.

CC: @mpv-player/stable
2014-10-23 18:31:43 +02:00
wm4 596231bc97 player: fix --frames
This could produce an extra frame, because reaching the maximum merely
signals the playloop to exit, without strictly enforcing the limit.

Fixes #1181.

CC: @mpv-player/stable
2014-10-14 13:29:38 +02:00
wm4 299bf5c017 player: signal EOF when using --frames 2014-10-10 15:14:11 +02:00
wm4 bc6b8caa6d video: try harder to decode cover art picture only once
For cover art, we pretend that the video stream is infinite, but also
stop decoding once we have an image on the VO (this seems advantageous
for the case when strange filters are inserted or the VO image gets
lost). Since a while ago, the video chain started decoding 2 images
though ("Non-monotonic video pts: 0.000000 <= 0.000000"), which is
annoying and wasteful.

Improve this by handling a certain corner case at initialization, which
will decode a second image while the first one is still stuck in the
filter chain. Also, just in case there are filters which buffer a lot,
also force EOF filtering (which means we tell the filters to flush
buffered frames).

CC: @mpv-player/stable
2014-10-09 17:57:17 +02:00
wm4 9d5d031b6d player: remove central uninit_player() function and flags mess
Each subsystem (or similar thing) had an INITIALIZED_ flag assigned. The
main use of this was that you could pass a bitmask of these flags to
uninit_player(). Except in some situations where you wanted to
uninitialize nearly everything, this wasn't really useful. Moreover, it
was quite annoying that subsystems had most of the code in a specific
file, but the uninit code in loadfile.c (because that's where
uninit_player() was implemented).

Simplify all this. Remove the flags; e.g. instead of testing for the
INITIALIZED_AO flag, test whether mpctx->ao is set. Move uninit code
to separate functions, e.g. uninit_audio_out().
2014-10-03 23:05:09 +02:00
wm4 f62f984404 player: don't print audio/video init failure message twice
The messages "Audio: no audio" and "Video: no video" could be printed
twice each if initializing them failed. Prevent his silliness.

CC: @mpv-player/stable
2014-10-02 03:12:45 +02:00
wm4 cdb25d5a21 video: change automatic rotation and 3D filter insertion
We inserted these filters with fixed parameters, which was ok. But this
also didn't change image parameters for the filters down the filter
chain and the VO. For example, if rotation by 90° was requested by the
file, we would insert a filter and rotate the video, but the VO would
still receive image parameters that direct rotation by 90°.

This wasn't a problem, but it could become one.

Fix this by letting the filters automatically pick up the image params.
The image params are reset on application. (We could probably also
always try to apply and reset image params in a filter, instead of
having special "auto" parameters. This would probably work, and video.c
would insert a "rotate=0" filter. But I'm afraid this would be confusing
and the current solution is cosmetically slightly nicer.)

Unfortunately, the vf_stereo3d.c change turned out a big mess, but once
the "internal" filter is fully replaced with libavfilter, most of this
can be radically simplified.
2014-09-27 18:31:59 +02:00
wm4 d23ffd243f player: rate-limit OSD text update
There's no need to update OSD messages and the terminal status if nobody
is going to see it. Since the player doesn't block on video display
anymore, this update happens to often and probably burns slightly more
CPU than necessary. (OSD redrawing is handled separately, so it's just
mostly useless text processing and such.)

Change it so that it's updated only on every video frame or all 50ms
(whatever comes first).

For VO OSD, we could in theory try to lock to the OSD redraw heuristic
or the display refresh rate, but that's more complicated and doesn't
work for the terminal status.
2014-09-25 21:32:56 +02:00
wm4 f605b03f63 video: filter new frames at a better time (2)
We generally want 2 things:
1. minimal wakeups for decoding each frame
2. minimal number of frames decoded on continuous seeking

Commit 35810cb8 changed this a bit, and fixed 1. But it broke 2., and
now it decodes 2 frames instead of 1 when you keep seeking (arrow key
held down or such). This made seeking appear slower.

Fix this by making the logic more explicit. In particular, call the
filters only if we actually try to get a new frame.

When playing with --no-audio and all other distractions disabled (like
OSC), it still wakes up 2 times per frame - but the second time is
merely because the VO didn't accept the new frame yet.
2014-09-22 18:06:59 +02:00
wm4 771583c285 video: actually count decoder-dropped frames
Normally, feeding a packet to the decoder should always return a frame
_if_ we received a frame before. So while we can't know exactly whether
a frame was dropped, at least the normal case is easily detectable.

This means we display something closer to the actual framedrop count,
instead of a bad guess.
2014-09-20 00:45:39 +02:00
wm4 4047e7e6cb video: improve decoder-based framedropping mode
This is the "old" framedropping mode (derived from MPlayer). At least in
the mplayer2/mpv source base, it stopped working properly years ago (or
maybe it never worked properly). For one, it depends on the video
framerate, which assume constant framerate. Another problem was that it
could lead to freezing video display: video could get so much behind
that it couldn't recover from framedrop.

Make some small changes to improve this.

Don't use the current audio position to check how much we are behind.
Instead, use the last known A/V difference. last_av_difference is
updated only when a video frame is scheduled for display. This means we
can keep stop dropping once we're done catching up, even if video is
technically still behind. What helps us here that this forces a video
frame to be displayed after a while. Likewise, we reset the
dropped_frames count only when scheduling a new frame for display as
well.

Some inspiration was taken from earlier work by xnor (see issue #620),
although the implementation turned out quite different.

This still uses the demuxer-reported (possibly broken) FPS value. It
also doesn't account for filters changing FPS. We can't do much about
this, because without decoding _and_ filtering, we just can't know how
long a frame is. In theory, you could derive that from the raw packet
timestamps and the filter chain contents, but actually doing this is
too involved. Fortunately, the main thing the FPS affects is actually
the displayed framedrop count.
2014-09-20 00:45:11 +02:00
wm4 70f4721574 player: reset last_av_difference if not applicable
Don't let stale values linger around.

Also fix a slightly related case in audio.c.
2014-09-20 00:44:37 +02:00
wm4 5c8549ac68 video: separate calling decoder/filter
Rename video_decode_and_filter to video_filter, and add a new
video_decode_and_filter function. This function now calls the decoder.
This is done so that we can check filters a second time after decoding,
which avoids a useless playloop iteration.

(This and the previous commits are really just microoptimizations, which
simply reduce the number of times the playloop has to recheck
everything.)
2014-09-18 19:35:23 +02:00
wm4 e37ad620aa video: check whether there are enough frames after filtering
Move the check to a function. Run the check a second time after
decoding/filtering. This second check is strictly speaking redundant
(which is why it wasn't done until now), but it avoids a useless
playloop iteration.
2014-09-18 19:34:56 +02:00
wm4 35810cb8b4 video: filter new frames at a better time
Move this code below the code that "shifts" the newly filtered frame.
This allows us to skip a useless playloop iteration later, because
obviously we need to filter a new frame after the previous frame has
been "shifted", and not before that.
2014-09-18 19:32:25 +02:00
wm4 8599c959fe video: initial Matroska 3D support
This inserts an automatic conversion filter if a Matroska file is marked
as 3D (StereoMode element). The basic idea is similar to video rotation
and colorspace handling: the 3D mode is added as a property to the video
params. Depending on this property, a video filter can be inserted.

As of this commit, extending mp_image_params is actually completely
unnecessary - but the idea is that it will make it easier to integrate
with VOs supporting stereo 3D mogrification. Although vo_opengl does
support some stereo rendering, it didn't support the mode my sample file
used, so I'll leave that part for later.

Not that most mappings from Matroska mode to vf_stereo3d mode are
probably wrong, and some are missing.

Assuming that Matroska modes, and vf_stereo3d in modes, and out modes
are all the same might be an oversimplification - we'll see.

See issue #1045.
2014-08-30 23:24:46 +02:00
wm4 f104ef1282 player: minor changes
This shouldn't change anything functionally.

Change the A/V desync message. --framedrop is enabled by default now, so
the text must be changed a little. I've never heard of audio outputs
messing up A/V sync recently, so remove that part.

Remove the unused ao_pts field.

Reorder 2 A/V sync related expressions so that they look the same.
2014-08-25 21:39:24 +02:00
wm4 39b42814e0 player: restore silent seeking
Commit 846257da introduced an accidental feature: if you kept seeking
(so playback never really resumes), the audio would never be played.
This was nice, but commit 4c25b000 accidentally removed it again (due
to the video_next_pts being earlier available than it used to be, so
audio could be played before the player executed the next queued seek).

Implicitly reintroduce the old behavior again by not decoding a second
video frame immediately. Usually, the second frame is used to compute
the frame duration needed to for accurate framedropping, but since the
first frame after a seek is never dropped, we don't need this.

Now the video code will queue the new frame to the VO immediately, and
since fill_audio_out_buffers() is called in the playloop before
write_video() and execute_queued_seek(), it never gets the chance to
enter STATUS_READY, and seeks will be silent.

This also has a nice side-effect: since the second frame is not decoded
and filtered, seeking becomes slightly faster (back to the same level
as with framedrop disabled).

It seems this still sometimes plays a period of audio when keeping a
seek key down. In my tests, this appeared to happen because the seek
finished before the next key repeat was sent.
2014-08-23 12:02:40 +02:00
wm4 4c25b000b5 player: fix recent speed change regression
Commit 5afc025c broke this. The reason is that mpctx->delay is updated
when a new video frame is added. This value is also needed to resync
audio, but it will be for the wrong PTS. They must be consistent with
each other, and if they aren't, initial sync will be off by N video
frames, which results at least in worse user experience.

This can be reproduced by for example heavily switching between normal
and 2x speed, or similar.

Fix by readding the video_next_pts field (keeping its use minimal,
instead of reverting the commit that removed it).
2014-08-22 15:36:48 +02:00
wm4 e9e73f8d03 video: refactor queue handling
This simplifies the code, and fixes an odd bug: the second-last frame
was displayed for a very short duration if framedrop was enabled. The
reason was that basically the time difference between second-last and
last frame were skipped, because at this point EOF was already
signaled. Also see commit b0959488 for a similar issue in the
same code.

This removes the messiness of the next_frame 2-frame queue, and
strictly runs the "new frame" code when a frame is moved to the first
position of the queue, instead of somehow messing with return codes.

This also merges update_video() into video_output_image().
2014-08-22 14:22:06 +02:00