2013-10-29 21:38:29 +00:00
|
|
|
/*
|
2015-04-13 07:36:54 +00:00
|
|
|
* This file is part of mpv.
|
2013-10-29 21:38:29 +00:00
|
|
|
*
|
2015-04-13 07:36:54 +00:00
|
|
|
* mpv is free software; you can redistribute it and/or modify
|
2013-10-29 21:38:29 +00:00
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
2015-04-13 07:36:54 +00:00
|
|
|
* mpv is distributed in the hope that it will be useful,
|
2013-10-29 21:38:29 +00:00
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
2015-04-13 07:36:54 +00:00
|
|
|
* with mpv. If not, see <http://www.gnu.org/licenses/>.
|
2013-10-29 21:38:29 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <stddef.h>
|
|
|
|
#include <stdbool.h>
|
|
|
|
#include <inttypes.h>
|
|
|
|
#include <math.h>
|
|
|
|
#include <assert.h>
|
|
|
|
|
|
|
|
#include "config.h"
|
|
|
|
#include "talloc.h"
|
|
|
|
|
2013-12-17 01:39:45 +00:00
|
|
|
#include "common/msg.h"
|
2013-12-17 01:02:25 +00:00
|
|
|
#include "options/options.h"
|
2014-04-20 21:54:13 +00:00
|
|
|
#include "options/m_config.h"
|
|
|
|
#include "options/m_option.h"
|
2013-12-17 01:39:45 +00:00
|
|
|
#include "common/common.h"
|
|
|
|
#include "common/encode.h"
|
2013-12-17 01:02:25 +00:00
|
|
|
#include "options/m_property.h"
|
2014-07-30 21:24:08 +00:00
|
|
|
#include "osdep/timer.h"
|
2013-10-29 21:38:29 +00:00
|
|
|
|
|
|
|
#include "audio/out/ao.h"
|
|
|
|
#include "demux/demux.h"
|
|
|
|
#include "stream/stream.h"
|
2013-11-24 11:58:06 +00:00
|
|
|
#include "sub/osd.h"
|
2013-11-23 20:26:31 +00:00
|
|
|
#include "video/hwdec.h"
|
2013-10-29 21:38:29 +00:00
|
|
|
#include "video/filter/vf.h"
|
|
|
|
#include "video/decode/dec_video.h"
|
2013-12-10 18:07:29 +00:00
|
|
|
#include "video/decode/vd.h"
|
2013-10-29 21:38:29 +00:00
|
|
|
#include "video/out/vo.h"
|
2015-08-10 16:43:25 +00:00
|
|
|
#include "audio/filter/af.h"
|
|
|
|
#include "audio/decode/dec_audio.h"
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2013-12-17 00:08:53 +00:00
|
|
|
#include "core.h"
|
2013-10-29 21:38:29 +00:00
|
|
|
#include "command.h"
|
2014-07-30 21:24:08 +00:00
|
|
|
#include "screenshot.h"
|
|
|
|
|
|
|
|
enum {
|
|
|
|
// update_video() - code also uses: <0 error, 0 eof, >0 progress
|
|
|
|
VD_ERROR = -1,
|
|
|
|
VD_EOF = 0, // end of file - no new output
|
|
|
|
VD_PROGRESS = 1, // progress, but no output; repeat call with no waiting
|
|
|
|
VD_NEW_FRAME = 2, // the call produced a new frame
|
|
|
|
VD_WAIT = 3, // no EOF, but no output; wait until wakeup
|
2014-10-09 15:57:17 +00:00
|
|
|
VD_RECONFIG = 4,
|
2014-07-30 21:24:08 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static const char av_desync_help_text[] =
|
2015-06-30 17:06:00 +00:00
|
|
|
"\n"
|
|
|
|
"Audio/Video desynchronisation detected! Possible reasons include too slow\n"
|
|
|
|
"hardware, temporary CPU spikes, broken drivers, and broken files. Audio\n"
|
|
|
|
"position will not match to the video (see A-V status field).\n"
|
|
|
|
"\n";
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2015-06-18 16:39:46 +00:00
|
|
|
static bool decode_coverart(struct dec_video *d_video);
|
|
|
|
|
2013-12-10 18:24:58 +00:00
|
|
|
static void set_allowed_vo_formats(struct vf_chain *c, struct vo *vo)
|
|
|
|
{
|
2015-01-03 16:23:01 +00:00
|
|
|
vo_query_formats(vo, c->allowed_output_formats);
|
2013-12-10 18:24:58 +00:00
|
|
|
}
|
|
|
|
|
2014-04-20 21:54:13 +00:00
|
|
|
static int try_filter(struct MPContext *mpctx, struct mp_image_params params,
|
|
|
|
char *name, char *label, char **args)
|
|
|
|
{
|
|
|
|
struct dec_video *d_video = mpctx->d_video;
|
|
|
|
|
|
|
|
struct vf_instance *vf = vf_append_filter(d_video->vfilter, name, args);
|
|
|
|
if (!vf)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
vf->label = talloc_strdup(vf, label);
|
|
|
|
|
|
|
|
if (video_reconfig_filters(d_video, ¶ms) < 0) {
|
|
|
|
vf_remove_filter(d_video->vfilter, vf);
|
|
|
|
// restore
|
|
|
|
video_reconfig_filters(d_video, ¶ms);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-05-01 21:53:18 +00:00
|
|
|
// Reconfigure the filter chain according to decoder output.
|
|
|
|
// probe_only: don't force fallback to software when doing hw decoding, and
|
|
|
|
// the filter chain couldn't be configured
|
|
|
|
static void filter_reconfig(struct MPContext *mpctx,
|
|
|
|
bool probe_only)
|
2013-12-10 18:24:58 +00:00
|
|
|
{
|
|
|
|
struct dec_video *d_video = mpctx->d_video;
|
|
|
|
|
2014-05-01 21:53:18 +00:00
|
|
|
struct mp_image_params params = d_video->decoder_output;
|
2013-12-10 18:24:58 +00:00
|
|
|
|
2014-08-06 17:25:30 +00:00
|
|
|
mp_notify(mpctx, MPV_EVENT_VIDEO_RECONFIG, NULL);
|
|
|
|
|
2013-12-10 18:24:58 +00:00
|
|
|
set_allowed_vo_formats(d_video->vfilter, mpctx->video_out);
|
|
|
|
|
2014-04-20 21:54:13 +00:00
|
|
|
if (video_reconfig_filters(d_video, ¶ms) < 0) {
|
2013-12-10 18:24:58 +00:00
|
|
|
// Most video filters don't work with hardware decoding, so this
|
2014-05-01 21:53:18 +00:00
|
|
|
// might be the reason why filter reconfig failed.
|
2013-12-10 18:24:58 +00:00
|
|
|
if (!probe_only &&
|
|
|
|
video_vd_control(d_video, VDCTRL_FORCE_HWDEC_FALLBACK, NULL) == CONTROL_OK)
|
|
|
|
{
|
|
|
|
// Fallback active; decoder will return software format next
|
|
|
|
// time. Don't abort video decoding.
|
|
|
|
d_video->vfilter->initialized = 0;
|
2014-05-01 21:53:18 +00:00
|
|
|
mp_image_unrefp(&d_video->waiting_decoded_mpi);
|
|
|
|
d_video->decoder_output = (struct mp_image_params){0};
|
|
|
|
MP_VERBOSE(mpctx, "hwdec falback due to filters.\n");
|
2013-12-10 18:24:58 +00:00
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-04-20 21:54:13 +00:00
|
|
|
if (d_video->vfilter->initialized < 1)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (params.rotate && (params.rotate % 90 == 0)) {
|
|
|
|
if (!(mpctx->video_out->driver->caps & VO_CAP_ROTATE90)) {
|
|
|
|
// Try to insert a rotation filter.
|
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 16:13:14 +00:00
|
|
|
char *args[] = {"angle", "auto", NULL};
|
2014-04-20 21:54:13 +00:00
|
|
|
if (try_filter(mpctx, params, "rotate", "autorotate", args) >= 0) {
|
|
|
|
params.rotate = 0;
|
|
|
|
} else {
|
|
|
|
MP_ERR(mpctx, "Can't insert rotation filter.\n");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2014-08-30 21:24:46 +00:00
|
|
|
|
|
|
|
if (params.stereo_in != params.stereo_out &&
|
|
|
|
params.stereo_in > 0 && params.stereo_out >= 0)
|
|
|
|
{
|
2015-04-02 21:54:08 +00:00
|
|
|
char *to = (char *)MP_STEREO3D_NAME(params.stereo_out);
|
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 16:13:14 +00:00
|
|
|
if (to) {
|
|
|
|
char *args[] = {"in", "auto", "out", to, NULL, NULL};
|
2014-08-30 21:24:46 +00:00
|
|
|
if (try_filter(mpctx, params, "stereo3d", "stereo3d", args) < 0)
|
|
|
|
MP_ERR(mpctx, "Can't insert 3D conversion filter.\n");
|
|
|
|
}
|
|
|
|
}
|
2013-12-10 18:24:58 +00:00
|
|
|
}
|
|
|
|
|
2013-10-29 21:38:29 +00:00
|
|
|
static void recreate_video_filters(struct MPContext *mpctx)
|
|
|
|
{
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
2013-11-23 20:36:20 +00:00
|
|
|
struct dec_video *d_video = mpctx->d_video;
|
|
|
|
assert(d_video);
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2013-12-07 18:32:44 +00:00
|
|
|
vf_destroy(d_video->vfilter);
|
2013-12-21 16:43:25 +00:00
|
|
|
d_video->vfilter = vf_new(mpctx->global);
|
2014-08-11 21:08:35 +00:00
|
|
|
d_video->vfilter->hwdec = d_video->hwdec_info;
|
2015-01-03 02:01:58 +00:00
|
|
|
d_video->vfilter->wakeup_callback = wakeup_playloop;
|
|
|
|
d_video->vfilter->wakeup_callback_ctx = mpctx;
|
2015-01-03 02:37:05 +00:00
|
|
|
d_video->vfilter->container_fps = d_video->fps;
|
2015-02-08 23:05:09 +00:00
|
|
|
vo_control(mpctx->video_out, VOCTRL_GET_DISPLAY_FPS,
|
|
|
|
&d_video->vfilter->display_fps);
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2013-12-07 18:32:44 +00:00
|
|
|
vf_append_filter_list(d_video->vfilter, opts->vf_settings);
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2013-12-07 18:32:44 +00:00
|
|
|
// for vf_sub
|
2014-01-18 00:19:20 +00:00
|
|
|
osd_set_render_subs_in_filter(mpctx->osd,
|
2015-06-05 16:59:13 +00:00
|
|
|
vf_control_any(d_video->vfilter, VFCTRL_INIT_OSD, mpctx->osd) > 0);
|
2013-12-10 18:24:58 +00:00
|
|
|
|
|
|
|
set_allowed_vo_formats(d_video->vfilter, mpctx->video_out);
|
2013-10-29 21:38:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
int reinit_video_filters(struct MPContext *mpctx)
|
|
|
|
{
|
2013-11-23 20:36:20 +00:00
|
|
|
struct dec_video *d_video = mpctx->d_video;
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2014-03-30 17:21:54 +00:00
|
|
|
if (!d_video)
|
|
|
|
return 0;
|
|
|
|
bool need_reconfig = d_video->vfilter->initialized != 0;
|
2013-10-29 21:38:29 +00:00
|
|
|
|
|
|
|
recreate_video_filters(mpctx);
|
|
|
|
|
2014-03-30 17:21:54 +00:00
|
|
|
if (need_reconfig)
|
2014-05-01 21:53:18 +00:00
|
|
|
filter_reconfig(mpctx, true);
|
2014-03-30 17:21:54 +00:00
|
|
|
|
|
|
|
return d_video->vfilter->initialized;
|
2013-10-29 21:38:29 +00:00
|
|
|
}
|
|
|
|
|
2014-07-30 21:01:55 +00:00
|
|
|
void reset_video_state(struct MPContext *mpctx)
|
|
|
|
{
|
|
|
|
if (mpctx->d_video)
|
|
|
|
video_reset_decoding(mpctx->d_video);
|
|
|
|
if (mpctx->video_out)
|
|
|
|
vo_seek_reset(mpctx->video_out);
|
|
|
|
|
2015-07-01 17:22:40 +00:00
|
|
|
for (int n = 0; n < mpctx->num_next_frames; n++)
|
|
|
|
mp_image_unrefp(&mpctx->next_frames[n]);
|
|
|
|
mpctx->num_next_frames = 0;
|
2014-12-07 01:47:09 +00:00
|
|
|
mp_image_unrefp(&mpctx->saved_frame);
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
|
2014-07-30 21:01:55 +00:00
|
|
|
mpctx->delay = 0;
|
|
|
|
mpctx->time_frame = 0;
|
2014-08-22 12:20:00 +00:00
|
|
|
mpctx->video_pts = MP_NOPTS_VALUE;
|
2014-08-22 13:28:05 +00:00
|
|
|
mpctx->video_next_pts = MP_NOPTS_VALUE;
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
mpctx->num_past_frames = 0;
|
2014-07-30 21:01:55 +00:00
|
|
|
mpctx->total_avsync_change = 0;
|
2015-05-24 18:57:31 +00:00
|
|
|
mpctx->last_av_difference = 0;
|
2014-11-01 00:07:21 +00:00
|
|
|
mpctx->dropped_frames_total = 0;
|
2014-07-30 21:01:55 +00:00
|
|
|
mpctx->dropped_frames = 0;
|
2015-10-30 13:05:41 +00:00
|
|
|
mpctx->mistimed_frames_total = 0;
|
2014-07-30 21:01:55 +00:00
|
|
|
mpctx->drop_message_shown = 0;
|
2015-08-10 16:43:25 +00:00
|
|
|
mpctx->display_sync_drift_dir = 0;
|
2014-07-30 21:01:55 +00:00
|
|
|
|
|
|
|
mpctx->video_status = mpctx->d_video ? STATUS_SYNCING : STATUS_EOF;
|
|
|
|
}
|
|
|
|
|
2014-10-03 17:57:49 +00:00
|
|
|
void uninit_video_out(struct MPContext *mpctx)
|
|
|
|
{
|
|
|
|
uninit_video_chain(mpctx);
|
2015-09-22 09:19:39 +00:00
|
|
|
if (mpctx->video_out) {
|
2014-10-03 17:57:49 +00:00
|
|
|
vo_destroy(mpctx->video_out);
|
2015-09-22 09:19:39 +00:00
|
|
|
mp_notify(mpctx, MPV_EVENT_VIDEO_RECONFIG, NULL);
|
|
|
|
}
|
2014-10-03 17:57:49 +00:00
|
|
|
mpctx->video_out = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
void uninit_video_chain(struct MPContext *mpctx)
|
|
|
|
{
|
|
|
|
if (mpctx->d_video) {
|
|
|
|
reset_video_state(mpctx);
|
|
|
|
video_uninit(mpctx->d_video);
|
|
|
|
mpctx->d_video = NULL;
|
|
|
|
mpctx->video_status = STATUS_EOF;
|
|
|
|
mpctx->sync_audio_to_video = false;
|
|
|
|
reselect_demux_streams(mpctx);
|
2015-07-21 19:54:15 +00:00
|
|
|
remove_deint_filter(mpctx);
|
2015-09-22 09:19:39 +00:00
|
|
|
mp_notify(mpctx, MPV_EVENT_VIDEO_RECONFIG, NULL);
|
2014-10-03 17:57:49 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-10-29 21:38:29 +00:00
|
|
|
int reinit_video_chain(struct MPContext *mpctx)
|
|
|
|
{
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
2013-11-23 20:36:20 +00:00
|
|
|
assert(!mpctx->d_video);
|
2013-12-24 16:46:08 +00:00
|
|
|
struct track *track = mpctx->current_track[0][STREAM_VIDEO];
|
2014-07-29 15:55:28 +00:00
|
|
|
struct sh_stream *sh = track ? track->stream : NULL;
|
2013-11-23 20:36:20 +00:00
|
|
|
if (!sh)
|
2013-10-29 21:38:29 +00:00
|
|
|
goto no_video;
|
|
|
|
|
2015-02-03 22:09:02 +00:00
|
|
|
if (!mpctx->video_out) {
|
2014-12-31 18:01:28 +00:00
|
|
|
struct vo_extra ex = {
|
|
|
|
.input_ctx = mpctx->input,
|
|
|
|
.osd = mpctx->osd,
|
|
|
|
.encode_lavc_ctx = mpctx->encode_lavc_ctx,
|
2014-12-31 18:12:44 +00:00
|
|
|
.opengl_cb_context = mpctx->gl_cb_ctx,
|
2014-12-31 18:01:28 +00:00
|
|
|
};
|
|
|
|
mpctx->video_out = init_best_video_out(mpctx->global, &ex);
|
2013-10-29 21:38:29 +00:00
|
|
|
if (!mpctx->video_out) {
|
|
|
|
MP_FATAL(mpctx, "Error opening/initializing "
|
|
|
|
"the selected video_out (-vo) device.\n");
|
2014-10-28 15:19:07 +00:00
|
|
|
mpctx->error_playing = MPV_ERROR_VO_INIT_FAILED;
|
2013-10-29 21:38:29 +00:00
|
|
|
goto err_out;
|
|
|
|
}
|
|
|
|
mpctx->mouse_cursor_visible = true;
|
|
|
|
}
|
|
|
|
|
2013-11-09 23:49:13 +00:00
|
|
|
update_window_title(mpctx, true);
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2013-11-23 20:36:20 +00:00
|
|
|
struct dec_video *d_video = talloc_zero(NULL, struct dec_video);
|
|
|
|
mpctx->d_video = d_video;
|
2013-12-21 16:47:38 +00:00
|
|
|
d_video->global = mpctx->global;
|
|
|
|
d_video->log = mp_log_new(d_video, mpctx->log, "!vd");
|
2013-11-23 20:36:20 +00:00
|
|
|
d_video->opts = mpctx->opts;
|
|
|
|
d_video->header = sh;
|
2013-11-23 20:41:40 +00:00
|
|
|
d_video->fps = sh->video->fps;
|
2013-12-10 18:08:56 +00:00
|
|
|
d_video->vo = mpctx->video_out;
|
2013-11-23 20:36:20 +00:00
|
|
|
|
2015-04-20 21:19:19 +00:00
|
|
|
MP_VERBOSE(d_video, "Container reported FPS: %f\n", sh->video->fps);
|
|
|
|
|
2015-01-03 02:37:05 +00:00
|
|
|
if (opts->force_fps) {
|
|
|
|
d_video->fps = opts->force_fps;
|
|
|
|
MP_INFO(mpctx, "FPS forced to %5.3f.\n", d_video->fps);
|
|
|
|
MP_INFO(mpctx, "Use --no-correct-pts to force FPS based timing.\n");
|
|
|
|
}
|
2015-04-20 21:21:38 +00:00
|
|
|
|
|
|
|
#if HAVE_ENCODING
|
|
|
|
if (mpctx->encode_lavc_ctx && d_video)
|
|
|
|
encode_lavc_set_video_fps(mpctx->encode_lavc_ctx, d_video->fps);
|
|
|
|
#endif
|
2015-01-03 02:37:05 +00:00
|
|
|
|
2013-11-23 20:39:07 +00:00
|
|
|
vo_control(mpctx->video_out, VOCTRL_GET_HWDEC_INFO, &d_video->hwdec_info);
|
2013-11-23 20:36:20 +00:00
|
|
|
|
2013-10-29 21:38:29 +00:00
|
|
|
recreate_video_filters(mpctx);
|
|
|
|
|
2013-11-23 20:38:39 +00:00
|
|
|
if (!video_init_best_codec(d_video, opts->video_decoders))
|
2013-10-29 21:38:29 +00:00
|
|
|
goto err_out;
|
|
|
|
|
2015-06-18 18:48:30 +00:00
|
|
|
if (d_video->header->attached_picture && !decode_coverart(d_video))
|
2015-06-18 16:39:46 +00:00
|
|
|
goto err_out;
|
|
|
|
|
2013-10-29 21:38:29 +00:00
|
|
|
bool saver_state = opts->pause || !opts->stop_screensaver;
|
|
|
|
vo_control(mpctx->video_out, saver_state ? VOCTRL_RESTORE_SCREENSAVER
|
|
|
|
: VOCTRL_KILL_SCREENSAVER, NULL);
|
|
|
|
|
video: add VO framedropping mode
This mostly uses the same idea as with vo_vdpau.c, but much simplified.
On X11, it tries to get the display framerate with XF86VM, and limits
the frequency of new video frames against it. Note that this is an old
extension, and is confirmed not to work correctly with multi-monitor
setups. But we're using it because it was already around (it is also
used by vo_vdpau).
This attempts to predict the next vsync event by using the time of the
last frame and the display FPS. Even if that goes completely wrong,
the results are still relatively good.
On other systems, or if the X11 code doesn't return a display FPS, a
framerate of 1000 is assumed. This is infinite for all practical
purposes, and means that only frames which are definitely too late are
dropped. This probably has worse results, but is still useful.
"--framedrop=yes" is basically replaced with "--framedrop=decoder". The
old framedropping mode is kept around, and should perhaps be improved.
Dropping on the decoder level is still useful if decoding itself is too
slow.
2014-08-15 21:33:33 +00:00
|
|
|
vo_set_paused(mpctx->video_out, mpctx->paused);
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2013-11-23 20:36:20 +00:00
|
|
|
mpctx->sync_audio_to_video = !sh->attached_picture;
|
2013-10-29 21:38:29 +00:00
|
|
|
mpctx->vo_pts_history_seek_ts++;
|
|
|
|
|
2014-07-28 18:40:43 +00:00
|
|
|
// If we switch on video again, ensure audio position matches up.
|
|
|
|
if (mpctx->d_audio)
|
|
|
|
mpctx->audio_status = STATUS_SYNCING;
|
|
|
|
|
2014-07-30 21:01:55 +00:00
|
|
|
reset_video_state(mpctx);
|
|
|
|
reset_subtitle_state(mpctx);
|
2013-10-29 21:38:29 +00:00
|
|
|
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
err_out:
|
|
|
|
no_video:
|
2014-10-03 17:57:49 +00:00
|
|
|
uninit_video_chain(mpctx);
|
2014-10-02 01:12:45 +00:00
|
|
|
if (track)
|
2014-10-23 16:31:43 +00:00
|
|
|
error_on_track(mpctx, track);
|
2013-10-29 21:38:29 +00:00
|
|
|
handle_force_window(mpctx, true);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Try to refresh the video by doing a precise seek to the currently displayed
|
|
|
|
// frame. This can go wrong in all sorts of ways, so use sparingly.
|
|
|
|
void mp_force_video_refresh(struct MPContext *mpctx)
|
|
|
|
{
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
2014-03-30 17:21:54 +00:00
|
|
|
struct dec_video *d_video = mpctx->d_video;
|
|
|
|
|
|
|
|
if (!d_video || !d_video->decoder_output.imgfmt)
|
|
|
|
return;
|
2013-10-29 21:38:29 +00:00
|
|
|
|
|
|
|
// If not paused, the next frame should come soon enough.
|
2015-07-10 16:07:39 +00:00
|
|
|
if (opts->pause && mpctx->video_status == STATUS_PLAYING &&
|
|
|
|
mpctx->last_vo_pts != MP_NOPTS_VALUE)
|
|
|
|
{
|
2015-03-04 16:21:05 +00:00
|
|
|
queue_seek(mpctx, MPSEEK_ABSOLUTE, mpctx->last_vo_pts,
|
|
|
|
MPSEEK_VERY_EXACT, true);
|
|
|
|
}
|
2013-10-29 21:38:29 +00:00
|
|
|
}
|
|
|
|
|
2014-08-13 19:50:23 +00:00
|
|
|
static int check_framedrop(struct MPContext *mpctx)
|
2014-05-01 21:53:18 +00:00
|
|
|
{
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
|
|
|
// check for frame-drop:
|
2014-08-13 19:50:23 +00:00
|
|
|
if (mpctx->video_status == STATUS_PLAYING && !mpctx->paused &&
|
|
|
|
mpctx->audio_status == STATUS_PLAYING && !ao_untimed(mpctx->ao))
|
2014-05-01 21:53:18 +00:00
|
|
|
{
|
|
|
|
float fps = mpctx->d_video->fps;
|
2014-08-13 19:50:23 +00:00
|
|
|
double frame_time = fps > 0 ? 1.0 / fps : 0;
|
2014-05-01 21:53:18 +00:00
|
|
|
// we should avoid dropping too many frames in sequence unless we
|
|
|
|
// are too late. and we allow 100ms A-V delay here:
|
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-19 21:46:20 +00:00
|
|
|
if (mpctx->last_av_difference - 0.100 > mpctx->dropped_frames * frame_time)
|
|
|
|
return !!(opts->frame_dropping & 2);
|
2014-05-01 21:53:18 +00:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-06-18 16:39:46 +00:00
|
|
|
static bool decode_coverart(struct dec_video *d_video)
|
|
|
|
{
|
|
|
|
d_video->cover_art_mpi =
|
|
|
|
video_decode(d_video, d_video->header->attached_picture, 0);
|
|
|
|
// Might need flush.
|
|
|
|
if (!d_video->cover_art_mpi)
|
|
|
|
d_video->cover_art_mpi = video_decode(d_video, NULL, 0);
|
|
|
|
|
|
|
|
return !!d_video->cover_art_mpi;
|
|
|
|
}
|
|
|
|
|
2014-05-01 21:53:18 +00:00
|
|
|
// Read a packet, store decoded image into d_video->waiting_decoded_mpi
|
2014-07-18 13:11:21 +00:00
|
|
|
// returns VD_* code
|
2014-05-01 21:53:18 +00:00
|
|
|
static int decode_image(struct MPContext *mpctx)
|
2013-10-29 21:38:29 +00:00
|
|
|
{
|
2013-11-23 20:36:20 +00:00
|
|
|
struct dec_video *d_video = mpctx->d_video;
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2014-05-01 21:53:18 +00:00
|
|
|
if (d_video->header->attached_picture) {
|
2015-06-18 16:39:46 +00:00
|
|
|
d_video->waiting_decoded_mpi = mp_image_new_ref(d_video->cover_art_mpi);
|
|
|
|
return VD_EOF;
|
2014-05-01 21:53:18 +00:00
|
|
|
}
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2014-07-18 13:10:28 +00:00
|
|
|
struct demux_packet *pkt;
|
|
|
|
if (demux_read_packet_async(d_video->header, &pkt) == 0)
|
2014-07-18 13:11:21 +00:00
|
|
|
return VD_WAIT;
|
2014-05-01 21:53:18 +00:00
|
|
|
if ((pkt && pkt->pts >= mpctx->hrseek_pts - .005) ||
|
2014-05-07 20:01:17 +00:00
|
|
|
d_video->has_broken_packet_pts ||
|
|
|
|
!mpctx->opts->hr_seek_framedrop)
|
2014-05-01 21:53:18 +00:00
|
|
|
{
|
|
|
|
mpctx->hrseek_framedrop = false;
|
|
|
|
}
|
2014-07-28 18:40:43 +00:00
|
|
|
bool hrseek = mpctx->hrseek_active && mpctx->video_status == STATUS_SYNCING;
|
|
|
|
int framedrop_type = hrseek && mpctx->hrseek_framedrop ?
|
2014-08-13 19:50:23 +00:00
|
|
|
2 : check_framedrop(mpctx);
|
2014-05-01 21:53:18 +00:00
|
|
|
d_video->waiting_decoded_mpi =
|
|
|
|
video_decode(d_video, pkt, framedrop_type);
|
2014-05-02 12:44:53 +00:00
|
|
|
bool had_packet = !!pkt;
|
2014-05-01 21:53:18 +00:00
|
|
|
talloc_free(pkt);
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2014-09-19 21:57:48 +00:00
|
|
|
if (had_packet && !d_video->waiting_decoded_mpi &&
|
2015-04-16 19:55:10 +00:00
|
|
|
mpctx->video_status == STATUS_PLAYING &&
|
|
|
|
(mpctx->opts->frame_dropping & 2))
|
2014-09-19 21:57:48 +00:00
|
|
|
{
|
2014-11-01 00:07:21 +00:00
|
|
|
mpctx->dropped_frames_total++;
|
2014-09-19 21:57:48 +00:00
|
|
|
mpctx->dropped_frames++;
|
|
|
|
}
|
|
|
|
|
2014-07-18 13:11:21 +00:00
|
|
|
return had_packet ? VD_PROGRESS : VD_EOF;
|
2013-10-29 21:38:29 +00:00
|
|
|
}
|
|
|
|
|
2014-05-01 21:53:18 +00:00
|
|
|
|
2013-12-10 18:24:58 +00:00
|
|
|
// Called after video reinit. This can be generally used to try to insert more
|
|
|
|
// filters using the filter chain edit functionality in command.c.
|
2013-10-29 21:38:29 +00:00
|
|
|
static void init_filter_params(struct MPContext *mpctx)
|
|
|
|
{
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
|
|
|
|
2013-12-10 18:07:29 +00:00
|
|
|
// Note that the filter chain is already initialized. This code might
|
|
|
|
// recreate the chain a second time, which is not very elegant, but allows
|
|
|
|
// us to test whether enabling deinterlacing works with the current video
|
|
|
|
// format and other filters.
|
2015-07-21 19:54:15 +00:00
|
|
|
if (opts->deinterlace >= 0) {
|
|
|
|
remove_deint_filter(mpctx);
|
|
|
|
set_deinterlacing(mpctx, opts->deinterlace != 0);
|
|
|
|
}
|
2013-12-10 18:07:29 +00:00
|
|
|
}
|
|
|
|
|
2014-09-18 17:22:39 +00:00
|
|
|
// Feed newly decoded frames to the filter, take care of format changes.
|
|
|
|
// If eof=true, drain the filter chain, and return VD_EOF if empty.
|
|
|
|
static int video_filter(struct MPContext *mpctx, bool eof)
|
2013-12-10 18:07:29 +00:00
|
|
|
{
|
|
|
|
struct dec_video *d_video = mpctx->d_video;
|
2014-05-01 21:53:18 +00:00
|
|
|
struct vf_chain *vf = d_video->vfilter;
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2014-05-01 21:53:18 +00:00
|
|
|
if (vf->initialized < 0)
|
2014-07-18 13:11:21 +00:00
|
|
|
return VD_ERROR;
|
video: display last frame, drain frames on video reconfig
Until now, the player didn't care to drain frames on video reconfig.
Instead, the VO was reconfigured (i.e. resized) before the queued frames
finished displaying. This can for example be observed by passing
multiple images with different size as mf:// filename. Then the window
would resize one frame before image with the new size is displayed. With
--vo=vdpau, the effect is worse, because this VO queues more than 1
frame internally.
Fix this by explicitly draining buffered frames before video reconfig.
Raise the display time of the last frame. Otherwise, the last frame
would be shown for a very short time only. This usually doesn't matter,
but helps when playing image files. This is a byproduct of frame
draining, because normally, video timing is based on the frames queued
to the VO, and we can't do that with frames of different size or format.
So we pretend that the frame before the change is the last frame in
order to time it. This code is incorrect though: it tries to use the
framerate, which often doesn't make sense. But it's good enough to test
this code with mf://.
2013-12-10 18:33:11 +00:00
|
|
|
|
2014-05-01 21:53:18 +00:00
|
|
|
// There is already a filtered frame available.
|
2015-01-03 02:01:58 +00:00
|
|
|
// If vf_needs_input() returns > 0, the filter wants input anyway.
|
|
|
|
if (vf_output_frame(vf, eof) > 0 && vf_needs_input(vf) < 1)
|
2014-07-18 13:11:21 +00:00
|
|
|
return VD_PROGRESS;
|
2014-05-01 21:53:18 +00:00
|
|
|
|
|
|
|
// Decoder output is different from filter input?
|
|
|
|
bool need_vf_reconfig = !vf->input_params.imgfmt || vf->initialized < 1 ||
|
2014-06-17 21:30:16 +00:00
|
|
|
!mp_image_params_equal(&d_video->decoder_output, &vf->input_params);
|
2014-05-01 21:53:18 +00:00
|
|
|
|
|
|
|
// (If imgfmt==0, nothing was decoded yet, and the format is unknown.)
|
|
|
|
if (need_vf_reconfig && d_video->decoder_output.imgfmt) {
|
|
|
|
// Drain the filter chain.
|
|
|
|
if (vf_output_frame(vf, true) > 0)
|
2014-07-18 13:11:21 +00:00
|
|
|
return VD_PROGRESS;
|
2014-05-01 21:53:18 +00:00
|
|
|
|
|
|
|
// The filter chain is drained; execute the filter format change.
|
|
|
|
filter_reconfig(mpctx, false);
|
|
|
|
if (vf->initialized == 0)
|
2014-07-18 13:11:21 +00:00
|
|
|
return VD_PROGRESS; // hw decoding fallback; try again
|
2014-05-01 21:53:18 +00:00
|
|
|
if (vf->initialized < 1)
|
2014-07-18 13:11:21 +00:00
|
|
|
return VD_ERROR;
|
2014-05-01 21:53:18 +00:00
|
|
|
init_filter_params(mpctx);
|
2014-10-09 15:57:17 +00:00
|
|
|
return VD_RECONFIG;
|
2013-10-29 21:38:29 +00:00
|
|
|
}
|
2013-12-10 18:07:29 +00:00
|
|
|
|
2014-05-01 21:53:18 +00:00
|
|
|
// If something was decoded, and the filter chain is ready, filter it.
|
|
|
|
if (!need_vf_reconfig && d_video->waiting_decoded_mpi) {
|
|
|
|
vf_filter_frame(vf, d_video->waiting_decoded_mpi);
|
|
|
|
d_video->waiting_decoded_mpi = NULL;
|
2014-07-18 13:11:21 +00:00
|
|
|
return VD_PROGRESS;
|
2013-12-10 18:07:29 +00:00
|
|
|
}
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2014-09-18 17:22:39 +00:00
|
|
|
return eof ? VD_EOF : VD_PROGRESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Make sure at least 1 filtered image is available, decode new video if needed.
|
|
|
|
// returns VD_* code
|
|
|
|
// A return value of VD_PROGRESS doesn't necessarily output a frame, but makes
|
|
|
|
// the promise that calling this function again will eventually do something.
|
|
|
|
static int video_decode_and_filter(struct MPContext *mpctx)
|
|
|
|
{
|
|
|
|
struct dec_video *d_video = mpctx->d_video;
|
|
|
|
|
|
|
|
int r = video_filter(mpctx, false);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
2014-05-01 21:53:18 +00:00
|
|
|
if (!d_video->waiting_decoded_mpi) {
|
|
|
|
// Decode a new image, or at least feed the decoder a packet.
|
2014-09-18 17:22:39 +00:00
|
|
|
r = decode_image(mpctx);
|
2014-07-22 19:08:42 +00:00
|
|
|
if (r == VD_WAIT)
|
|
|
|
return r;
|
2014-05-01 21:53:18 +00:00
|
|
|
if (d_video->waiting_decoded_mpi)
|
|
|
|
d_video->decoder_output = d_video->waiting_decoded_mpi->params;
|
|
|
|
}
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2014-09-18 17:22:39 +00:00
|
|
|
bool eof = !d_video->waiting_decoded_mpi && (r == VD_EOF || r < 0);
|
2014-10-09 15:57:17 +00:00
|
|
|
r = video_filter(mpctx, eof);
|
|
|
|
if (r == VD_RECONFIG) // retry feeding decoded image
|
|
|
|
r = video_filter(mpctx, eof);
|
|
|
|
return r;
|
video: display last frame, drain frames on video reconfig
Until now, the player didn't care to drain frames on video reconfig.
Instead, the VO was reconfigured (i.e. resized) before the queued frames
finished displaying. This can for example be observed by passing
multiple images with different size as mf:// filename. Then the window
would resize one frame before image with the new size is displayed. With
--vo=vdpau, the effect is worse, because this VO queues more than 1
frame internally.
Fix this by explicitly draining buffered frames before video reconfig.
Raise the display time of the last frame. Otherwise, the last frame
would be shown for a very short time only. This usually doesn't matter,
but helps when playing image files. This is a byproduct of frame
draining, because normally, video timing is based on the frames queued
to the VO, and we can't do that with frames of different size or format.
So we pretend that the frame before the change is the last frame in
order to time it. This code is incorrect though: it tries to use the
framerate, which often doesn't make sense. But it's good enough to test
this code with mf://.
2013-12-10 18:33:11 +00:00
|
|
|
}
|
|
|
|
|
2015-01-03 02:01:58 +00:00
|
|
|
static int video_feed_async_filter(struct MPContext *mpctx)
|
|
|
|
{
|
|
|
|
struct dec_video *d_video = mpctx->d_video;
|
|
|
|
struct vf_chain *vf = d_video->vfilter;
|
|
|
|
|
|
|
|
if (vf->initialized < 0)
|
|
|
|
return VD_ERROR;
|
|
|
|
|
|
|
|
if (vf_needs_input(vf) < 1)
|
|
|
|
return 0;
|
|
|
|
mpctx->sleeptime = 0; // retry until done
|
|
|
|
return video_decode_and_filter(mpctx);
|
|
|
|
}
|
|
|
|
|
2014-08-22 12:19:01 +00:00
|
|
|
/* Modify video timing to match the audio timeline. There are two main
|
|
|
|
* reasons this is needed. First, video and audio can start from different
|
|
|
|
* positions at beginning of file or after a seek (MPlayer starts both
|
|
|
|
* immediately even if they have different pts). Second, the file can have
|
|
|
|
* audio timestamps that are inconsistent with the duration of the audio
|
|
|
|
* packets, for example two consecutive timestamp values differing by
|
|
|
|
* one second but only a packet with enough samples for half a second
|
|
|
|
* of playback between them.
|
|
|
|
*/
|
|
|
|
static void adjust_sync(struct MPContext *mpctx, double v_pts, double frame_time)
|
2013-10-29 21:38:29 +00:00
|
|
|
{
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
2014-05-01 21:53:18 +00:00
|
|
|
|
2014-08-22 12:19:01 +00:00
|
|
|
if (mpctx->audio_status != STATUS_PLAYING)
|
|
|
|
return;
|
2014-05-01 23:28:52 +00:00
|
|
|
|
2015-01-29 11:10:07 +00:00
|
|
|
double a_pts = written_audio_pts(mpctx) + opts->audio_delay - mpctx->delay;
|
2014-08-22 12:19:01 +00:00
|
|
|
double av_delay = a_pts - v_pts;
|
|
|
|
|
|
|
|
double change = av_delay * 0.1;
|
|
|
|
double max_change = opts->default_max_pts_correction >= 0 ?
|
|
|
|
opts->default_max_pts_correction : frame_time * 0.1;
|
|
|
|
if (change < -max_change)
|
|
|
|
change = -max_change;
|
|
|
|
else if (change > max_change)
|
|
|
|
change = max_change;
|
|
|
|
mpctx->delay += change;
|
|
|
|
mpctx->total_avsync_change += change;
|
2015-10-27 19:56:58 +00:00
|
|
|
|
|
|
|
if (mpctx->display_sync_active)
|
|
|
|
mpctx->total_avsync_change = 0;
|
2013-10-29 21:38:29 +00:00
|
|
|
}
|
|
|
|
|
2015-07-01 17:22:40 +00:00
|
|
|
// Make the frame at position 0 "known" to the playback logic. This must happen
|
|
|
|
// only once for each frame, so this function has to be called carefully.
|
|
|
|
// Generally, if position 0 gets a new frame, this must be called.
|
|
|
|
static void handle_new_frame(struct MPContext *mpctx)
|
2015-03-25 12:33:34 +00:00
|
|
|
{
|
2015-07-01 17:22:40 +00:00
|
|
|
assert(mpctx->num_next_frames >= 1);
|
2015-03-25 12:33:34 +00:00
|
|
|
|
|
|
|
double frame_time = 0;
|
2015-07-01 17:22:40 +00:00
|
|
|
double pts = mpctx->next_frames[0]->pts;
|
2015-03-25 12:33:34 +00:00
|
|
|
if (mpctx->video_pts != MP_NOPTS_VALUE) {
|
|
|
|
frame_time = pts - mpctx->video_pts;
|
2015-05-20 12:24:55 +00:00
|
|
|
double tolerance = 15;
|
|
|
|
if (mpctx->demuxer->ts_resets_possible) {
|
|
|
|
// Fortunately no real framerate is likely to go below this. It
|
|
|
|
// still could be that the file is VFR, but the demuxer reports a
|
|
|
|
// higher rate, so account for the case of e.g. 60hz demuxer fps
|
|
|
|
// but 23hz actual fps.
|
|
|
|
double fps = 23.976;
|
|
|
|
if (mpctx->d_video->fps > 0 && mpctx->d_video->fps < fps)
|
|
|
|
fps = mpctx->d_video->fps;
|
|
|
|
tolerance = 3 * 1.0 / fps;
|
|
|
|
}
|
|
|
|
if (frame_time <= 0 || frame_time >= tolerance) {
|
|
|
|
// Assume a discontinuity.
|
2015-03-25 12:33:34 +00:00
|
|
|
MP_WARN(mpctx, "Invalid video timestamp: %f -> %f\n",
|
|
|
|
mpctx->video_pts, pts);
|
|
|
|
frame_time = 0;
|
2015-08-03 21:09:11 +00:00
|
|
|
if (mpctx->d_audio)
|
|
|
|
mpctx->audio_status = STATUS_SYNCING;
|
2015-03-25 12:33:34 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
mpctx->video_next_pts = pts;
|
|
|
|
mpctx->delay -= frame_time;
|
|
|
|
if (mpctx->video_status >= STATUS_PLAYING) {
|
2015-08-10 16:40:16 +00:00
|
|
|
mpctx->time_frame += frame_time / mpctx->video_speed;
|
2015-03-25 12:33:34 +00:00
|
|
|
adjust_sync(mpctx, pts, frame_time);
|
|
|
|
}
|
|
|
|
mpctx->dropped_frames = 0;
|
|
|
|
MP_TRACE(mpctx, "frametime=%5.3f\n", frame_time);
|
|
|
|
}
|
|
|
|
|
2015-07-01 17:24:28 +00:00
|
|
|
// Remove the first frame in mpctx->next_frames
|
|
|
|
static void shift_frames(struct MPContext *mpctx)
|
|
|
|
{
|
|
|
|
if (mpctx->num_next_frames < 1)
|
|
|
|
return;
|
|
|
|
talloc_free(mpctx->next_frames[0]);
|
|
|
|
for (int n = 0; n < mpctx->num_next_frames - 1; n++)
|
|
|
|
mpctx->next_frames[n] = mpctx->next_frames[n + 1];
|
|
|
|
mpctx->num_next_frames -= 1;
|
|
|
|
}
|
|
|
|
|
2015-07-01 17:22:40 +00:00
|
|
|
static int get_req_frames(struct MPContext *mpctx, bool eof)
|
|
|
|
{
|
|
|
|
// On EOF, drain all frames.
|
2015-11-13 21:42:42 +00:00
|
|
|
if (eof)
|
2015-07-01 17:22:40 +00:00
|
|
|
return 1;
|
|
|
|
|
2015-11-13 21:42:42 +00:00
|
|
|
// On the first frame, output a new frame as quickly as possible.
|
|
|
|
// But display-sync likes to have a correct frame duration always.
|
|
|
|
if (mpctx->video_pts == MP_NOPTS_VALUE)
|
|
|
|
return mpctx->opts->video_sync == VS_DEFAULT ? 1 : 2;
|
|
|
|
|
2015-07-20 19:12:46 +00:00
|
|
|
int req = vo_get_num_req_frames(mpctx->video_out);
|
2015-08-19 19:24:56 +00:00
|
|
|
return MPCLAMP(req, 2, MP_ARRAY_SIZE(mpctx->next_frames));
|
2015-07-01 17:22:40 +00:00
|
|
|
}
|
|
|
|
|
2015-03-25 12:33:34 +00:00
|
|
|
// Whether it's fine to call add_new_frame() now.
|
|
|
|
static bool needs_new_frame(struct MPContext *mpctx)
|
|
|
|
{
|
2015-07-01 17:22:40 +00:00
|
|
|
return mpctx->num_next_frames < get_req_frames(mpctx, false);
|
2015-03-25 12:33:34 +00:00
|
|
|
}
|
|
|
|
|
2015-07-01 17:22:40 +00:00
|
|
|
// Queue a frame to mpctx->next_frames[]. Call only if needs_new_frame() signals ok.
|
2015-03-25 12:33:34 +00:00
|
|
|
static void add_new_frame(struct MPContext *mpctx, struct mp_image *frame)
|
|
|
|
{
|
|
|
|
assert(needs_new_frame(mpctx));
|
|
|
|
assert(frame);
|
2015-07-01 17:22:40 +00:00
|
|
|
mpctx->next_frames[mpctx->num_next_frames++] = frame;
|
|
|
|
if (mpctx->num_next_frames == 1)
|
|
|
|
handle_new_frame(mpctx);
|
2015-03-25 12:33:34 +00:00
|
|
|
}
|
|
|
|
|
2014-09-18 17:20:22 +00:00
|
|
|
// Enough video filtered already to push one frame to the VO?
|
2015-03-25 12:33:34 +00:00
|
|
|
// Set eof to true if no new frames are to be expected.
|
|
|
|
static bool have_new_frame(struct MPContext *mpctx, bool eof)
|
2014-09-18 17:20:22 +00:00
|
|
|
{
|
2015-07-01 17:22:40 +00:00
|
|
|
return mpctx->num_next_frames >= get_req_frames(mpctx, eof);
|
2014-09-18 17:20:22 +00:00
|
|
|
}
|
|
|
|
|
2015-07-01 17:22:40 +00:00
|
|
|
// Fill mpctx->next_frames[] with a newly filtered or decoded image.
|
2014-07-18 13:11:21 +00:00
|
|
|
// returns VD_* code
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
static int video_output_image(struct MPContext *mpctx, double endpts)
|
2013-10-29 21:38:29 +00:00
|
|
|
{
|
2014-12-07 01:47:09 +00:00
|
|
|
bool hrseek = mpctx->hrseek_active && mpctx->video_status == STATUS_SYNCING;
|
|
|
|
|
2014-05-01 21:53:18 +00:00
|
|
|
if (mpctx->d_video->header->attached_picture) {
|
2014-08-22 12:20:30 +00:00
|
|
|
if (vo_has_frame(mpctx->video_out))
|
2014-07-18 13:11:21 +00:00
|
|
|
return VD_EOF;
|
2015-07-01 17:22:40 +00:00
|
|
|
if (mpctx->num_next_frames >= 1)
|
2014-07-18 13:11:21 +00:00
|
|
|
return VD_NEW_FRAME;
|
2014-08-22 12:20:30 +00:00
|
|
|
int r = video_decode_and_filter(mpctx);
|
2014-10-09 15:57:17 +00:00
|
|
|
video_filter(mpctx, true); // force EOF filtering (avoid decoding more)
|
2015-07-01 17:22:40 +00:00
|
|
|
mpctx->next_frames[0] = vf_read_output_frame(mpctx->d_video->vfilter);
|
|
|
|
if (mpctx->next_frames[0]) {
|
|
|
|
mpctx->next_frames[0]->pts = MP_NOPTS_VALUE;
|
|
|
|
mpctx->num_next_frames = 1;
|
|
|
|
}
|
2014-08-22 12:20:30 +00:00
|
|
|
return r <= 0 ? VD_EOF : VD_PROGRESS;
|
2014-08-13 19:55:46 +00:00
|
|
|
}
|
|
|
|
|
2015-03-25 12:33:34 +00:00
|
|
|
if (have_new_frame(mpctx, false))
|
2014-09-22 16:06:59 +00:00
|
|
|
return VD_NEW_FRAME;
|
|
|
|
|
2014-09-18 17:17:38 +00:00
|
|
|
// Get a new frame if we need one.
|
2014-09-22 16:06:59 +00:00
|
|
|
int r = VD_PROGRESS;
|
2015-03-25 12:33:34 +00:00
|
|
|
if (needs_new_frame(mpctx)) {
|
2014-09-22 16:06:59 +00:00
|
|
|
// Filter a new frame.
|
|
|
|
r = video_decode_and_filter(mpctx);
|
|
|
|
if (r < 0)
|
|
|
|
return r; // error
|
2014-09-18 17:17:38 +00:00
|
|
|
struct mp_image *img = vf_read_output_frame(mpctx->d_video->vfilter);
|
|
|
|
if (img) {
|
|
|
|
// Always add these; they make backstepping after seeking faster.
|
|
|
|
add_frame_pts(mpctx, img->pts);
|
|
|
|
|
2015-03-25 12:58:14 +00:00
|
|
|
if (endpts != MP_NOPTS_VALUE && img->pts >= endpts) {
|
2014-09-18 17:17:38 +00:00
|
|
|
r = VD_EOF;
|
2015-03-25 12:58:14 +00:00
|
|
|
} else if (mpctx->max_frames == 0) {
|
|
|
|
r = VD_EOF;
|
|
|
|
} else if (hrseek && mpctx->hrseek_lastframe) {
|
2014-12-07 01:47:09 +00:00
|
|
|
mp_image_setrefp(&mpctx->saved_frame, img);
|
2015-03-25 12:58:14 +00:00
|
|
|
} else if (hrseek && img->pts < mpctx->hrseek_pts - .005) {
|
|
|
|
/* just skip */
|
2014-09-18 17:17:38 +00:00
|
|
|
} else {
|
2015-03-25 12:33:34 +00:00
|
|
|
add_new_frame(mpctx, img);
|
2015-03-25 12:58:14 +00:00
|
|
|
img = NULL;
|
2014-09-18 17:17:38 +00:00
|
|
|
}
|
2015-03-25 12:58:14 +00:00
|
|
|
talloc_free(img);
|
2014-09-18 17:17:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-12-07 01:47:09 +00:00
|
|
|
// Last-frame seek
|
2015-03-26 10:57:48 +00:00
|
|
|
if (r <= 0 && hrseek && mpctx->hrseek_lastframe && mpctx->saved_frame) {
|
2015-03-25 12:33:34 +00:00
|
|
|
add_new_frame(mpctx, mpctx->saved_frame);
|
2014-12-07 01:47:09 +00:00
|
|
|
mpctx->saved_frame = NULL;
|
2015-03-25 12:33:34 +00:00
|
|
|
r = VD_PROGRESS;
|
2014-12-07 01:47:09 +00:00
|
|
|
}
|
|
|
|
|
2015-03-25 12:33:34 +00:00
|
|
|
return have_new_frame(mpctx, r <= 0) ? VD_NEW_FRAME : r;
|
2013-10-29 21:38:29 +00:00
|
|
|
}
|
2014-07-30 21:24:08 +00:00
|
|
|
|
2014-08-13 19:54:13 +00:00
|
|
|
/* Update avsync before a new video frame is displayed. Actually, this can be
|
|
|
|
* called arbitrarily often before the actual display.
|
|
|
|
* This adjusts the time of the next video frame */
|
|
|
|
static void update_avsync_before_frame(struct MPContext *mpctx)
|
|
|
|
{
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
|
|
|
struct vo *vo = mpctx->video_out;
|
|
|
|
|
|
|
|
if (!mpctx->sync_audio_to_video || mpctx->video_status < STATUS_READY) {
|
|
|
|
mpctx->time_frame = 0;
|
2015-08-10 16:43:25 +00:00
|
|
|
} else if (mpctx->display_sync_active || opts->video_sync == VS_NONE) {
|
|
|
|
// don't touch the timing
|
2014-08-13 19:54:13 +00:00
|
|
|
} else if (mpctx->audio_status == STATUS_PLAYING &&
|
|
|
|
mpctx->video_status == STATUS_PLAYING &&
|
|
|
|
!ao_untimed(mpctx->ao))
|
|
|
|
{
|
|
|
|
double buffered_audio = ao_get_delay(mpctx->ao);
|
2015-02-01 17:32:26 +00:00
|
|
|
|
2015-08-10 16:40:16 +00:00
|
|
|
double predicted = mpctx->delay / mpctx->video_speed +
|
2015-02-01 17:32:26 +00:00
|
|
|
mpctx->time_frame;
|
|
|
|
double difference = buffered_audio - predicted;
|
|
|
|
MP_STATS(mpctx, "value %f audio-diff", difference);
|
2014-08-13 19:54:13 +00:00
|
|
|
|
|
|
|
if (opts->autosync) {
|
|
|
|
/* Smooth reported playback position from AO by averaging
|
|
|
|
* it with the value expected based on previus value and
|
|
|
|
* time elapsed since then. May help smooth video timing
|
|
|
|
* with audio output that have inaccurate position reporting.
|
|
|
|
* This is badly implemented; the behavior of the smoothing
|
|
|
|
* now undesirably depends on how often this code runs
|
|
|
|
* (mainly depends on video frame rate). */
|
|
|
|
buffered_audio = predicted + difference / opts->autosync;
|
|
|
|
}
|
|
|
|
|
2015-08-10 16:40:16 +00:00
|
|
|
mpctx->time_frame = buffered_audio - mpctx->delay / mpctx->video_speed;
|
2014-08-13 19:54:13 +00:00
|
|
|
} else {
|
|
|
|
/* If we're more than 200 ms behind the right playback
|
|
|
|
* position, don't try to speed up display of following
|
|
|
|
* frames to catch up; continue with default speed from
|
|
|
|
* the current frame instead.
|
|
|
|
* If untimed is set always output frames immediately
|
|
|
|
* without sleeping.
|
|
|
|
*/
|
|
|
|
if (mpctx->time_frame < -0.2 || opts->untimed || vo->driver->untimed)
|
|
|
|
mpctx->time_frame = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-10-28 22:50:54 +00:00
|
|
|
// Update the A/V sync difference when a new video frame is being shown.
|
|
|
|
static void update_av_diff(struct MPContext *mpctx, double offset)
|
2014-07-30 21:24:08 +00:00
|
|
|
{
|
2015-01-29 11:10:07 +00:00
|
|
|
struct MPOpts *opts = mpctx->opts;
|
|
|
|
|
2014-09-19 20:38:00 +00:00
|
|
|
mpctx->last_av_difference = 0;
|
2014-08-22 12:20:30 +00:00
|
|
|
|
2014-07-30 21:24:08 +00:00
|
|
|
if (mpctx->audio_status != STATUS_PLAYING ||
|
|
|
|
mpctx->video_status != STATUS_PLAYING)
|
|
|
|
return;
|
|
|
|
|
|
|
|
double a_pos = playing_audio_pts(mpctx);
|
2015-10-28 22:50:54 +00:00
|
|
|
if (a_pos != MP_NOPTS_VALUE && mpctx->video_pts != MP_NOPTS_VALUE) {
|
|
|
|
mpctx->last_av_difference = a_pos - mpctx->video_pts
|
|
|
|
+ opts->audio_delay + offset;
|
|
|
|
}
|
2014-07-30 21:24:08 +00:00
|
|
|
|
2015-10-28 22:50:54 +00:00
|
|
|
if (fabs(mpctx->last_av_difference) > 0.5 && !mpctx->drop_message_shown) {
|
2014-07-30 21:24:08 +00:00
|
|
|
MP_WARN(mpctx, "%s", av_desync_help_text);
|
|
|
|
mpctx->drop_message_shown = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-08-22 12:19:01 +00:00
|
|
|
static void init_vo(struct MPContext *mpctx)
|
|
|
|
{
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
|
|
|
struct dec_video *d_video = mpctx->d_video;
|
|
|
|
|
|
|
|
if (opts->gamma_gamma != 1000)
|
|
|
|
video_set_colors(d_video, "gamma", opts->gamma_gamma);
|
|
|
|
if (opts->gamma_brightness != 1000)
|
|
|
|
video_set_colors(d_video, "brightness", opts->gamma_brightness);
|
|
|
|
if (opts->gamma_contrast != 1000)
|
|
|
|
video_set_colors(d_video, "contrast", opts->gamma_contrast);
|
|
|
|
if (opts->gamma_saturation != 1000)
|
|
|
|
video_set_colors(d_video, "saturation", opts->gamma_saturation);
|
|
|
|
if (opts->gamma_hue != 1000)
|
|
|
|
video_set_colors(d_video, "hue", opts->gamma_hue);
|
2015-09-29 19:12:26 +00:00
|
|
|
video_set_colors(d_video, "output-levels", opts->video_output_levels);
|
2014-08-22 12:19:01 +00:00
|
|
|
|
|
|
|
mp_notify(mpctx, MPV_EVENT_VIDEO_RECONFIG, NULL);
|
|
|
|
}
|
|
|
|
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
double calc_average_frame_duration(struct MPContext *mpctx)
|
2015-08-10 16:38:57 +00:00
|
|
|
{
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
double total = 0;
|
|
|
|
int num = 0;
|
|
|
|
for (int n = 0; n < mpctx->num_past_frames; n++) {
|
|
|
|
double dur = mpctx->past_frames[0].approx_duration;
|
|
|
|
if (dur <= 0)
|
|
|
|
continue;
|
|
|
|
total += dur;
|
|
|
|
num += 1;
|
2015-08-10 16:38:57 +00:00
|
|
|
}
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
return num > 0 ? total / num : 0;
|
2015-08-10 16:38:57 +00:00
|
|
|
}
|
|
|
|
|
2015-11-13 21:47:14 +00:00
|
|
|
// Find a speed factor such that the display FPS is an integer multiple of the
|
|
|
|
// effective video FPS. If this is not possible, try to do it for multiples,
|
|
|
|
// which still leads to an improved end result.
|
|
|
|
// Both parameters are durations in seconds.
|
|
|
|
static double calc_best_speed(double vsync, double frame)
|
|
|
|
{
|
|
|
|
double ratio = frame / vsync;
|
|
|
|
double best_scale = -1;
|
|
|
|
double best_dev = INFINITY;
|
|
|
|
for (int factor = 1; factor <= 5; factor++) {
|
|
|
|
double scale = ratio * factor / rint(ratio * factor);
|
|
|
|
double dev = fabs(scale - 1);
|
|
|
|
if (dev < best_dev) {
|
|
|
|
best_scale = scale;
|
|
|
|
best_dev = dev;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return best_scale;
|
|
|
|
}
|
|
|
|
|
|
|
|
static double find_best_speed(struct MPContext *mpctx, double vsync)
|
|
|
|
{
|
|
|
|
double total = 0;
|
|
|
|
int num = 0;
|
|
|
|
for (int n = 0; n < mpctx->num_past_frames; n++) {
|
|
|
|
double dur = mpctx->past_frames[n].approx_duration;
|
|
|
|
if (dur <= 0)
|
|
|
|
continue;
|
|
|
|
total += calc_best_speed(vsync, dur / mpctx->opts->playback_speed);
|
|
|
|
num++;
|
|
|
|
}
|
|
|
|
return num > 0 ? total / num : 1;
|
|
|
|
}
|
|
|
|
|
2015-08-10 16:43:25 +00:00
|
|
|
static bool using_spdif_passthrough(struct MPContext *mpctx)
|
|
|
|
{
|
|
|
|
if (mpctx->d_audio && mpctx->d_audio->afilter)
|
2015-11-04 20:38:01 +00:00
|
|
|
return !af_fmt_is_pcm(mpctx->d_audio->afilter->input.format);
|
2015-08-10 16:43:25 +00:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2015-11-14 20:42:18 +00:00
|
|
|
// Compute the relative audio speed difference by taking A/V dsync into account.
|
|
|
|
static double compute_audio_drift(struct MPContext *mpctx, double vsync)
|
2015-11-13 21:51:39 +00:00
|
|
|
{
|
2015-11-14 20:42:18 +00:00
|
|
|
// Least-squares linear regression, using relative real time for x, and
|
|
|
|
// audio desync for y. Assume speed didn't change for the frames we're
|
2015-11-13 21:51:39 +00:00
|
|
|
// looking at for simplicity. This also should actually use the realtime
|
|
|
|
// (minus paused time) for x, but use vsync scheduling points instead.
|
|
|
|
if (mpctx->num_past_frames <= 10)
|
|
|
|
return NAN;
|
|
|
|
int num = mpctx->num_past_frames - 1;
|
|
|
|
double sum_x = 0, sum_y = 0, sum_xy = 0, sum_xx = 0;
|
|
|
|
double x = 0;
|
|
|
|
for (int n = 0; n < num; n++) {
|
|
|
|
struct frame_info *frame = &mpctx->past_frames[n + 1];
|
|
|
|
if (frame->num_vsyncs < 0)
|
|
|
|
return NAN;
|
2015-11-14 20:42:18 +00:00
|
|
|
double y = frame->av_diff;
|
2015-11-13 21:51:39 +00:00
|
|
|
sum_x += x;
|
|
|
|
sum_y += y;
|
|
|
|
sum_xy += x * y;
|
|
|
|
sum_xx += x * x;
|
|
|
|
x -= frame->num_vsyncs * vsync;
|
|
|
|
}
|
|
|
|
return (sum_x * sum_y - num * sum_xy) / (sum_x * sum_x - num * sum_xx);
|
|
|
|
}
|
|
|
|
|
2015-11-13 21:50:58 +00:00
|
|
|
static void adjust_audio_resample_speed(struct MPContext *mpctx, double vsync)
|
2015-11-04 18:37:15 +00:00
|
|
|
{
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
|
|
|
int mode = opts->video_sync;
|
2015-11-13 21:50:58 +00:00
|
|
|
|
|
|
|
if (mode != VS_DISP_RESAMPLE || mpctx->audio_status != STATUS_PLAYING) {
|
|
|
|
mpctx->speed_factor_a = mpctx->speed_factor_v;
|
|
|
|
return;
|
2015-11-04 18:37:15 +00:00
|
|
|
}
|
|
|
|
|
2015-11-13 21:50:58 +00:00
|
|
|
// Try to smooth out audio timing drifts. This can happen if either
|
|
|
|
// video isn't playing at expected speed, or audio is not playing at
|
|
|
|
// the requested speed. Both are unavoidable.
|
|
|
|
// The audio desync is made up of 2 parts: 1. drift due to rounding
|
|
|
|
// errors and imperfect information, and 2. an offset, due to
|
|
|
|
// unaligned audio/video start, or disruptive events halting audio
|
|
|
|
// or video for a small time.
|
|
|
|
// Instead of trying to be clever, just apply an awfully dumb drift
|
|
|
|
// compensation with a constant factor, which does what we want. In
|
|
|
|
// theory we could calculate the exact drift compensation needed,
|
|
|
|
// but it likely would be wrong anyway, and we'd run into the same
|
|
|
|
// issues again, except with more complex code.
|
|
|
|
// 1 means drifts to positive, -1 means drifts to negative
|
|
|
|
double max_drift = vsync / 2;
|
|
|
|
double av_diff = mpctx->last_av_difference;
|
|
|
|
int new = mpctx->display_sync_drift_dir;
|
|
|
|
if (av_diff * -mpctx->display_sync_drift_dir >= 0)
|
|
|
|
new = 0;
|
|
|
|
if (fabs(av_diff) > max_drift)
|
|
|
|
new = av_diff >= 0 ? 1 : -1;
|
|
|
|
|
|
|
|
bool change = mpctx->display_sync_drift_dir != new;
|
|
|
|
if (new || change) {
|
|
|
|
if (change)
|
|
|
|
MP_VERBOSE(mpctx, "Change display sync audio drift: %d\n", new);
|
|
|
|
mpctx->display_sync_drift_dir = new;
|
2015-11-04 18:37:15 +00:00
|
|
|
|
2015-11-13 21:50:58 +00:00
|
|
|
double max_correct = opts->sync_max_audio_change / 100;
|
|
|
|
double audio_factor = 1 + max_correct * -mpctx->display_sync_drift_dir;
|
2015-11-13 21:51:39 +00:00
|
|
|
|
|
|
|
if (new == 0) {
|
|
|
|
// If we're resetting, actually try to be clever and pick a speed
|
|
|
|
// which compensates the general drift we're getting.
|
2015-11-14 20:42:18 +00:00
|
|
|
double drift = compute_audio_drift(mpctx, vsync);
|
2015-11-13 21:51:39 +00:00
|
|
|
if (isnormal(drift)) {
|
2015-11-14 20:42:18 +00:00
|
|
|
// other = will be multiplied with audio_factor for final speed
|
|
|
|
double other = mpctx->opts->playback_speed * mpctx->speed_factor_v;
|
|
|
|
audio_factor = (mpctx->audio_speed - drift) / other;
|
2015-11-13 21:51:39 +00:00
|
|
|
MP_VERBOSE(mpctx, "Compensation factor: %f\n", audio_factor);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
audio_factor = MPCLAMP(audio_factor, 1 - max_correct, 1 + max_correct);
|
2015-11-13 21:50:58 +00:00
|
|
|
mpctx->speed_factor_a = audio_factor * mpctx->speed_factor_v;
|
|
|
|
}
|
2015-11-04 18:37:15 +00:00
|
|
|
}
|
|
|
|
|
2015-08-10 16:43:25 +00:00
|
|
|
// Manipulate frame timing for display sync, or do nothing for normal timing.
|
|
|
|
static void handle_display_sync_frame(struct MPContext *mpctx,
|
|
|
|
struct vo_frame *frame)
|
|
|
|
{
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
|
|
|
struct vo *vo = mpctx->video_out;
|
|
|
|
int mode = opts->video_sync;
|
|
|
|
|
|
|
|
if (!mpctx->display_sync_active) {
|
|
|
|
mpctx->display_sync_error = 0.0;
|
|
|
|
mpctx->display_sync_drift_dir = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
mpctx->display_sync_active = false;
|
|
|
|
|
|
|
|
if (!VS_IS_DISP(mode))
|
|
|
|
goto done;
|
|
|
|
bool resample = mode == VS_DISP_RESAMPLE || mode == VS_DISP_RESAMPLE_VDROP ||
|
|
|
|
mode == VS_DISP_RESAMPLE_NONE;
|
|
|
|
bool drop = mode == VS_DISP_VDROP || mode == VS_DISP_RESAMPLE ||
|
2015-10-27 19:56:46 +00:00
|
|
|
mode == VS_DISP_ADROP || mode == VS_DISP_RESAMPLE_VDROP;
|
2015-08-10 16:43:25 +00:00
|
|
|
drop &= (opts->frame_dropping & 1);
|
|
|
|
|
|
|
|
if (resample && using_spdif_passthrough(mpctx))
|
|
|
|
goto done;
|
|
|
|
|
|
|
|
double vsync = vo_get_vsync_interval(vo) / 1e6;
|
|
|
|
if (vsync <= 0)
|
|
|
|
goto done;
|
|
|
|
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
double adjusted_duration = mpctx->past_frames[0].approx_duration;
|
|
|
|
adjusted_duration /= opts->playback_speed;
|
|
|
|
if (adjusted_duration <= 0.001 || adjusted_duration > 0.5)
|
2015-08-10 16:43:25 +00:00
|
|
|
goto done;
|
|
|
|
|
2015-11-13 21:47:14 +00:00
|
|
|
mpctx->speed_factor_v = find_best_speed(mpctx, vsync);
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
// If it doesn't work, play at normal speed.
|
2015-11-13 21:47:14 +00:00
|
|
|
if (fabs(mpctx->speed_factor_v - 1.0) > opts->sync_max_video_change / 100)
|
2015-11-04 18:37:15 +00:00
|
|
|
mpctx->speed_factor_v = 1.0;
|
2015-08-10 16:43:25 +00:00
|
|
|
|
|
|
|
double av_diff = mpctx->last_av_difference;
|
|
|
|
if (fabs(av_diff) > 0.5)
|
|
|
|
goto done;
|
|
|
|
|
|
|
|
// At this point, we decided that we could use display sync for this frame.
|
|
|
|
// But if we switch too often between these modes, keep it disabled. In
|
|
|
|
// fact, we disable it if it just wants to switch between enable/disable
|
|
|
|
// more than once in the last N frames.
|
2015-11-13 21:49:50 +00:00
|
|
|
if (mpctx->num_past_frames > 1 && mpctx->past_frames[1].num_vsyncs < 0) {
|
|
|
|
for (int n = 1; n < mpctx->num_past_frames; n++) {
|
|
|
|
if (mpctx->past_frames[n].num_vsyncs >= 0)
|
|
|
|
goto done;
|
|
|
|
}
|
2015-08-10 16:43:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Determine for how many vsyncs a frame should be displayed. This can be
|
|
|
|
// e.g. 2 for 30hz on a 60hz display. It can also be 0 if the video
|
|
|
|
// framerate is higher than the display framerate.
|
|
|
|
// We use the speed-adjusted (i.e. real) frame duration for this.
|
2015-11-04 18:37:15 +00:00
|
|
|
double frame_duration = adjusted_duration / mpctx->speed_factor_v;
|
2015-08-10 16:43:25 +00:00
|
|
|
double ratio = (frame_duration + mpctx->display_sync_error) / vsync;
|
2015-11-11 18:52:35 +00:00
|
|
|
int num_vsyncs = MPMAX(lrint(ratio), 0);
|
2015-10-31 12:19:38 +00:00
|
|
|
double prev_error = mpctx->display_sync_error;
|
2015-08-10 16:43:25 +00:00
|
|
|
mpctx->display_sync_error += frame_duration - num_vsyncs * vsync;
|
|
|
|
frame->vsync_offset = mpctx->display_sync_error * 1e6;
|
|
|
|
|
2015-11-25 21:07:47 +00:00
|
|
|
MP_DBG(mpctx, "s=%f vsyncs=%d dur=%f ratio=%f err=%.20f (%f/%f)\n",
|
2015-11-04 18:37:15 +00:00
|
|
|
mpctx->speed_factor_v, num_vsyncs, adjusted_duration, ratio,
|
2015-11-25 21:07:47 +00:00
|
|
|
mpctx->display_sync_error, mpctx->display_sync_error / vsync,
|
|
|
|
mpctx->display_sync_error / frame_duration);
|
2015-08-10 16:43:25 +00:00
|
|
|
|
2015-11-04 18:37:15 +00:00
|
|
|
MP_STATS(mpctx, "value %f avdiff", av_diff);
|
|
|
|
|
|
|
|
// Intended number of additional display frames to drop (<0) or repeat (>0)
|
|
|
|
int drop_repeat = 0;
|
|
|
|
|
2015-11-13 21:53:38 +00:00
|
|
|
// If we are too far ahead/behind, attempt to drop/repeat frames.
|
2015-11-04 18:37:15 +00:00
|
|
|
// Tolerate some desync to avoid frame dropping due to jitter.
|
2015-11-13 21:53:38 +00:00
|
|
|
if (drop && fabs(av_diff) >= 0.020 && fabs(av_diff) / vsync >= 1)
|
2015-11-04 18:37:15 +00:00
|
|
|
drop_repeat = -av_diff / vsync; // round towards 0
|
|
|
|
|
2015-08-10 16:43:25 +00:00
|
|
|
// We can only drop all frames at most. We can repeat much more frames,
|
|
|
|
// but we still limit it to 10 times the original frames to avoid that
|
|
|
|
// corner cases or exceptional situations cause too much havoc.
|
|
|
|
drop_repeat = MPCLAMP(drop_repeat, -num_vsyncs, num_vsyncs * 10);
|
|
|
|
num_vsyncs += drop_repeat;
|
|
|
|
|
|
|
|
// Estimate the video position, so we can calculate a good A/V difference
|
2015-10-28 22:50:54 +00:00
|
|
|
// value below. This is used to estimate A/V drift.
|
2015-11-14 20:44:59 +00:00
|
|
|
double time_left = vo_get_delay(vo);
|
|
|
|
|
2015-08-10 16:43:25 +00:00
|
|
|
// We also know that the timing is (necessarily) off, because we have to
|
|
|
|
// align frame timings on the vsync boundaries. This is unavoidable, and
|
2015-10-31 12:19:38 +00:00
|
|
|
// for the sake of the A/V sync calculations we pretend it's perfect.
|
|
|
|
time_left += prev_error;
|
2015-10-28 22:50:37 +00:00
|
|
|
// Likewise, we know sync is off, but is going to be compensated.
|
2015-10-28 22:50:54 +00:00
|
|
|
time_left += drop_repeat * vsync;
|
|
|
|
|
2015-11-25 21:07:47 +00:00
|
|
|
if (drop_repeat) {
|
2015-10-30 13:05:41 +00:00
|
|
|
mpctx->mistimed_frames_total += 1;
|
2015-11-25 21:07:47 +00:00
|
|
|
MP_STATS(mpctx, "mistimed");
|
|
|
|
}
|
2015-10-30 13:05:41 +00:00
|
|
|
|
2015-10-27 19:56:58 +00:00
|
|
|
mpctx->total_avsync_change = 0;
|
2015-11-01 18:53:48 +00:00
|
|
|
update_av_diff(mpctx, time_left * opts->playback_speed);
|
2015-10-28 22:50:54 +00:00
|
|
|
|
2015-11-13 21:48:32 +00:00
|
|
|
mpctx->past_frames[0].num_vsyncs = num_vsyncs;
|
2015-11-13 21:51:39 +00:00
|
|
|
mpctx->past_frames[0].av_diff = mpctx->last_av_difference;
|
2015-11-13 21:48:32 +00:00
|
|
|
|
2015-11-13 21:50:58 +00:00
|
|
|
if (resample) {
|
|
|
|
adjust_audio_resample_speed(mpctx, vsync);
|
|
|
|
} else {
|
|
|
|
mpctx->speed_factor_a = 1.0;
|
|
|
|
}
|
2015-11-04 18:37:15 +00:00
|
|
|
|
2015-10-28 22:50:54 +00:00
|
|
|
// A bad guess, only needed when reverting to audio sync.
|
|
|
|
mpctx->time_frame = time_left;
|
2015-08-10 16:43:25 +00:00
|
|
|
|
|
|
|
frame->num_vsyncs = num_vsyncs;
|
|
|
|
frame->display_synced = true;
|
|
|
|
|
|
|
|
mpctx->display_sync_active = true;
|
2015-11-13 21:50:58 +00:00
|
|
|
update_playback_speed(mpctx);
|
2015-08-10 16:43:25 +00:00
|
|
|
|
2015-11-13 21:50:58 +00:00
|
|
|
MP_STATS(mpctx, "value %f aspeed", mpctx->speed_factor_a - 1);
|
|
|
|
MP_STATS(mpctx, "value %f vspeed", mpctx->speed_factor_v - 1);
|
2015-08-10 16:43:25 +00:00
|
|
|
|
2015-11-13 21:50:58 +00:00
|
|
|
done:
|
2015-08-10 16:43:25 +00:00
|
|
|
|
2015-11-13 21:49:50 +00:00
|
|
|
if (mpctx->num_past_frames > 1 &&
|
|
|
|
((mpctx->past_frames[1].num_vsyncs >= 0) != mpctx->display_sync_active))
|
|
|
|
{
|
2015-08-10 16:43:25 +00:00
|
|
|
MP_VERBOSE(mpctx, "Video sync mode %s.\n",
|
|
|
|
mpctx->display_sync_active ? "enabled" : "disabled");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-10-28 22:50:54 +00:00
|
|
|
static void schedule_frame(struct MPContext *mpctx, struct vo_frame *frame)
|
|
|
|
{
|
|
|
|
handle_display_sync_frame(mpctx, frame);
|
|
|
|
|
|
|
|
if (!mpctx->display_sync_active) {
|
2015-11-13 21:50:58 +00:00
|
|
|
mpctx->speed_factor_a = 1.0;
|
|
|
|
mpctx->speed_factor_v = 1.0;
|
|
|
|
update_playback_speed(mpctx);
|
|
|
|
|
2015-10-28 22:50:54 +00:00
|
|
|
update_av_diff(mpctx, mpctx->time_frame > 0 ?
|
|
|
|
mpctx->time_frame * mpctx->video_speed : 0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
// Determine the mpctx->past_frames[0] frame duration.
|
|
|
|
static void calculate_frame_duration(struct MPContext *mpctx)
|
2015-08-01 20:17:09 +00:00
|
|
|
{
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
assert(mpctx->num_past_frames >= 1 && mpctx->num_next_frames >= 1);
|
2015-08-01 20:17:09 +00:00
|
|
|
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
double demux_duration =
|
|
|
|
mpctx->d_video->fps > 0 ? 1.0 / mpctx->d_video->fps : -1;
|
|
|
|
double duration = -1;
|
|
|
|
|
|
|
|
if (mpctx->num_next_frames >= 2) {
|
|
|
|
double pts0 = mpctx->next_frames[0]->pts;
|
|
|
|
double pts1 = mpctx->next_frames[1]->pts;
|
|
|
|
if (pts0 != MP_NOPTS_VALUE && pts1 != MP_NOPTS_VALUE && pts1 >= pts0)
|
|
|
|
duration = pts1 - pts0;
|
|
|
|
} else {
|
|
|
|
// E.g. last frame on EOF.
|
|
|
|
duration = demux_duration;
|
2015-08-01 20:17:09 +00:00
|
|
|
}
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
|
|
|
|
// The following code tries to compensate for rounded Matroska timestamps
|
|
|
|
// by "unrounding" frame durations, or if not possible, approximating them.
|
|
|
|
// These formats usually round on 1ms. (Some muxers do this incorrectly,
|
|
|
|
// and might be off by 2ms or more, and compensate for it later by an
|
|
|
|
// equal rounding error into the opposite direction. Don't try to deal
|
|
|
|
// with them; too much potential damage to timing.)
|
|
|
|
double tolerance = 0.0011;
|
|
|
|
|
|
|
|
double total = 0;
|
|
|
|
int num_dur = 0;
|
|
|
|
for (int n = 1; n < mpctx->num_past_frames; n++) {
|
|
|
|
// Eliminate likely outliers using a really dumb heuristic.
|
|
|
|
double dur = mpctx->past_frames[n].duration;
|
|
|
|
if (dur <= 0 || fabs(dur - duration) >= tolerance)
|
|
|
|
break;
|
|
|
|
total += dur;
|
|
|
|
num_dur += 1;
|
|
|
|
}
|
2015-11-13 21:46:55 +00:00
|
|
|
double approx_duration = num_dur > 0 ? total / num_dur : duration;
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
|
|
|
|
// Try if the demuxer frame rate fits - if so, just take it.
|
|
|
|
if (demux_duration > 0) {
|
|
|
|
// Note that even if each timestamp is within rounding tolerance, it
|
|
|
|
// could literally not add up (e.g. if demuxer FPS is rounded itself).
|
|
|
|
if (fabs(duration - demux_duration) < tolerance &&
|
|
|
|
fabs(total - demux_duration * num_dur) < tolerance)
|
|
|
|
{
|
|
|
|
approx_duration = demux_duration;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
mpctx->past_frames[0].duration = duration;
|
|
|
|
mpctx->past_frames[0].approx_duration = approx_duration;
|
2015-08-01 20:17:09 +00:00
|
|
|
}
|
|
|
|
|
2014-07-30 21:24:08 +00:00
|
|
|
void write_video(struct MPContext *mpctx, double endpts)
|
|
|
|
{
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
|
|
|
struct vo *vo = mpctx->video_out;
|
|
|
|
|
|
|
|
if (!mpctx->d_video)
|
|
|
|
return;
|
|
|
|
|
2014-08-13 19:51:26 +00:00
|
|
|
// Actual playback starts when both audio and video are ready.
|
|
|
|
if (mpctx->video_status == STATUS_READY)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (mpctx->paused && mpctx->video_status >= STATUS_READY)
|
|
|
|
return;
|
|
|
|
|
2014-08-22 12:20:30 +00:00
|
|
|
int r = video_output_image(mpctx, endpts);
|
|
|
|
MP_TRACE(mpctx, "video_output_image: %d\n", r);
|
2014-07-30 21:24:08 +00:00
|
|
|
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
if (r < 0)
|
|
|
|
goto error;
|
2014-07-30 21:24:08 +00:00
|
|
|
|
2014-08-22 12:18:40 +00:00
|
|
|
if (r == VD_WAIT) // Demuxer will wake us up for more packets to decode.
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
return;
|
2014-07-30 21:24:08 +00:00
|
|
|
|
2014-08-22 12:18:40 +00:00
|
|
|
if (r == VD_EOF) {
|
2015-10-09 13:53:02 +00:00
|
|
|
int prev_state = mpctx->video_status;
|
2014-08-22 12:18:40 +00:00
|
|
|
mpctx->video_status =
|
|
|
|
vo_still_displaying(vo) ? STATUS_DRAINING : STATUS_EOF;
|
2014-07-30 21:24:08 +00:00
|
|
|
mpctx->delay = 0;
|
|
|
|
mpctx->last_av_difference = 0;
|
2015-04-14 12:36:15 +00:00
|
|
|
MP_DBG(mpctx, "video EOF (status=%d)\n", mpctx->video_status);
|
2015-10-09 13:53:02 +00:00
|
|
|
if (prev_state != mpctx->video_status)
|
|
|
|
mpctx->sleeptime = 0;
|
2014-07-31 19:57:05 +00:00
|
|
|
return;
|
2014-07-30 21:24:08 +00:00
|
|
|
}
|
|
|
|
|
2014-08-22 12:18:40 +00:00
|
|
|
if (mpctx->video_status > STATUS_PLAYING)
|
|
|
|
mpctx->video_status = STATUS_PLAYING;
|
|
|
|
|
|
|
|
if (r != VD_NEW_FRAME) {
|
|
|
|
mpctx->sleeptime = 0; // Decode more in next iteration.
|
2014-07-30 21:24:08 +00:00
|
|
|
return;
|
2014-08-22 12:18:40 +00:00
|
|
|
}
|
2014-07-30 21:24:08 +00:00
|
|
|
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
// Filter output is different from VO input?
|
2015-07-01 17:22:40 +00:00
|
|
|
struct mp_image_params p = mpctx->next_frames[0]->params;
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
if (!vo->params || !mp_image_params_equal(&p, vo->params)) {
|
|
|
|
// Changing config deletes the current frame; wait until it's finished.
|
2015-01-16 12:45:43 +00:00
|
|
|
if (vo_still_displaying(vo))
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
const struct vo_driver *info = mpctx->video_out->driver;
|
2014-11-02 16:34:02 +00:00
|
|
|
char extra[20] = {0};
|
|
|
|
if (p.w != p.d_w || p.h != p.d_h)
|
|
|
|
snprintf(extra, sizeof(extra), " => %dx%d", p.d_w, p.d_h);
|
|
|
|
MP_INFO(mpctx, "VO: [%s] %dx%d%s %s\n",
|
|
|
|
info->name, p.w, p.h, extra, vo_format_name(p.imgfmt));
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
MP_VERBOSE(mpctx, "VO: Description: %s\n", info->description);
|
|
|
|
|
2015-10-03 16:20:16 +00:00
|
|
|
int vo_r = vo_reconfig(vo, &p);
|
2014-10-28 15:19:07 +00:00
|
|
|
if (vo_r < 0) {
|
|
|
|
mpctx->error_playing = MPV_ERROR_VO_INIT_FAILED;
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
goto error;
|
2014-10-28 15:19:07 +00:00
|
|
|
}
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
init_vo(mpctx);
|
|
|
|
}
|
|
|
|
|
2015-01-30 20:18:30 +00:00
|
|
|
mpctx->time_frame -= get_relative_time(mpctx);
|
|
|
|
update_avsync_before_frame(mpctx);
|
|
|
|
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 21:02:08 +00:00
|
|
|
double time_frame = MPMAX(mpctx->time_frame, -1);
|
|
|
|
int64_t pts = mp_time_us() + (int64_t)(time_frame * 1e6);
|
2014-07-30 21:24:08 +00:00
|
|
|
|
2015-01-03 02:01:58 +00:00
|
|
|
// wait until VO wakes us up to get more frames
|
2015-08-10 16:43:25 +00:00
|
|
|
// (NB: in theory, the 1st frame after display sync mode change uses the
|
|
|
|
// wrong waiting mode)
|
|
|
|
if (!vo_is_ready_for_frame(vo, mpctx->display_sync_active ? -1 : pts)) {
|
2015-01-03 02:01:58 +00:00
|
|
|
if (video_feed_async_filter(mpctx) < 0)
|
|
|
|
goto error;
|
|
|
|
return;
|
|
|
|
}
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 21:02:08 +00:00
|
|
|
|
2015-07-01 17:22:40 +00:00
|
|
|
assert(mpctx->num_next_frames >= 1);
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
|
|
|
|
if (mpctx->num_past_frames >= MAX_NUM_VO_PTS)
|
|
|
|
mpctx->num_past_frames--;
|
|
|
|
MP_TARRAY_INSERT_AT(mpctx, mpctx->past_frames, mpctx->num_past_frames, 0,
|
|
|
|
(struct frame_info){0});
|
2015-11-13 21:48:32 +00:00
|
|
|
mpctx->past_frames[0] = (struct frame_info){
|
|
|
|
.pts = mpctx->next_frames[0]->pts,
|
|
|
|
.num_vsyncs = -1,
|
|
|
|
};
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
calculate_frame_duration(mpctx);
|
|
|
|
|
2015-07-28 21:54:39 +00:00
|
|
|
struct vo_frame dummy = {
|
|
|
|
.pts = pts,
|
|
|
|
.duration = -1,
|
2015-08-25 19:48:11 +00:00
|
|
|
.still = mpctx->step_frames > 0,
|
2015-07-28 21:54:39 +00:00
|
|
|
.num_frames = mpctx->num_next_frames,
|
2015-08-10 16:43:25 +00:00
|
|
|
.num_vsyncs = 1,
|
2015-07-28 21:54:39 +00:00
|
|
|
};
|
|
|
|
for (int n = 0; n < dummy.num_frames; n++)
|
|
|
|
dummy.frames[n] = mpctx->next_frames[n];
|
|
|
|
struct vo_frame *frame = vo_frame_ref(&dummy);
|
|
|
|
|
2015-11-13 21:48:32 +00:00
|
|
|
double diff = mpctx->past_frames[0].approx_duration;
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
if (opts->untimed || vo->driver->untimed)
|
|
|
|
diff = -1; // disable frame dropping and aspects of frame timing
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
if (diff >= 0) {
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 21:02:08 +00:00
|
|
|
// expected A/V sync correction is ignored
|
2015-08-10 16:40:16 +00:00
|
|
|
diff /= mpctx->video_speed;
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 21:02:08 +00:00
|
|
|
if (mpctx->time_frame < 0)
|
|
|
|
diff += mpctx->time_frame;
|
2015-07-28 21:54:39 +00:00
|
|
|
frame->duration = MPCLAMP(diff, 0, 10) * 1e6;
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 21:02:08 +00:00
|
|
|
}
|
2014-07-30 21:24:08 +00:00
|
|
|
|
2015-07-01 17:22:40 +00:00
|
|
|
mpctx->video_pts = mpctx->next_frames[0]->pts;
|
2014-07-30 21:24:08 +00:00
|
|
|
mpctx->last_vo_pts = mpctx->video_pts;
|
|
|
|
mpctx->playback_pts = mpctx->video_pts;
|
|
|
|
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
shift_frames(mpctx);
|
|
|
|
|
2015-10-28 22:50:54 +00:00
|
|
|
schedule_frame(mpctx, frame);
|
2015-01-30 20:18:30 +00:00
|
|
|
|
2014-09-25 18:25:24 +00:00
|
|
|
mpctx->osd_force_update = true;
|
2014-07-30 21:24:08 +00:00
|
|
|
update_osd_msg(mpctx);
|
2014-09-25 18:25:24 +00:00
|
|
|
update_subtitles(mpctx);
|
2014-07-30 21:24:08 +00:00
|
|
|
|
2015-07-28 21:54:39 +00:00
|
|
|
vo_queue_frame(vo, frame);
|
2015-07-01 17:24:28 +00:00
|
|
|
|
2015-07-01 17:22:40 +00:00
|
|
|
// The frames were shifted down; "initialize" the new first entry.
|
|
|
|
if (mpctx->num_next_frames >= 1)
|
|
|
|
handle_new_frame(mpctx);
|
2015-03-25 12:33:34 +00:00
|
|
|
|
2014-07-30 21:24:08 +00:00
|
|
|
mpctx->shown_vframes++;
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 21:02:08 +00:00
|
|
|
if (mpctx->video_status < STATUS_PLAYING) {
|
2014-07-30 21:24:08 +00:00
|
|
|
mpctx->video_status = STATUS_READY;
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 21:02:08 +00:00
|
|
|
// After a seek, make sure to wait until the first frame is visible.
|
|
|
|
vo_wait_frame(vo);
|
2015-06-18 20:31:55 +00:00
|
|
|
MP_VERBOSE(mpctx, "first video frame after restart shown\n");
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 21:02:08 +00:00
|
|
|
}
|
2014-07-30 21:24:08 +00:00
|
|
|
screenshot_flip(mpctx);
|
|
|
|
|
|
|
|
mp_notify(mpctx, MPV_EVENT_TICK, NULL);
|
|
|
|
|
|
|
|
if (!mpctx->sync_audio_to_video)
|
|
|
|
mpctx->video_status = STATUS_EOF;
|
2014-08-03 18:25:03 +00:00
|
|
|
|
|
|
|
if (mpctx->video_status != STATUS_EOF) {
|
|
|
|
if (mpctx->step_frames > 0) {
|
|
|
|
mpctx->step_frames--;
|
|
|
|
if (!mpctx->step_frames && !opts->pause)
|
|
|
|
pause_player(mpctx);
|
|
|
|
}
|
2015-07-08 19:31:31 +00:00
|
|
|
if (mpctx->max_frames == 0 && !mpctx->stop_play)
|
2014-10-10 13:14:11 +00:00
|
|
|
mpctx->stop_play = AT_END_OF_FILE;
|
2014-08-03 18:25:03 +00:00
|
|
|
if (mpctx->max_frames > 0)
|
|
|
|
mpctx->max_frames--;
|
|
|
|
}
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
|
2014-08-22 12:20:30 +00:00
|
|
|
mpctx->sleeptime = 0;
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
error:
|
|
|
|
MP_FATAL(mpctx, "Could not initialize video chain.\n");
|
2014-10-03 17:57:49 +00:00
|
|
|
uninit_video_chain(mpctx);
|
2014-10-23 16:31:43 +00:00
|
|
|
error_on_track(mpctx, mpctx->current_track[STREAM_VIDEO][0]);
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
handle_force_window(mpctx, true);
|
|
|
|
mpctx->sleeptime = 0;
|
2014-07-30 21:24:08 +00:00
|
|
|
}
|