diff options
author | Dudemanguy <random342@airmail.cc> | 2023-11-07 19:03:02 -0600 |
---|---|---|
committer | Dudemanguy <random342@airmail.cc> | 2023-11-11 20:44:01 +0000 |
commit | 332619042f00689b9609a35a16756beadd617fcf (patch) | |
tree | aff85f77b3d2cab837e21f9318f67ed91db3cfe7 /video | |
parent | 9199afc405d4f53315407133c3d727b025a663e0 (diff) | |
download | mpv-332619042f00689b9609a35a16756beadd617fcf.tar.bz2 mpv-332619042f00689b9609a35a16756beadd617fcf.tar.xz |
vo_gpu_next: improve PTS clamping
Originally suggested by @haasn. Instead of awkwardly using a pts from
the previous render loop, we can just peek into pl_queue and use the pts
of the first frame instead. This eliminates a lot of weird artifacts
that can happen on discontinuities like seeking. Fixes #12355.
Diffstat (limited to 'video')
-rw-r--r-- | video/out/vo_gpu_next.c | 11 |
1 files changed, 8 insertions, 3 deletions
diff --git a/video/out/vo_gpu_next.c b/video/out/vo_gpu_next.c index 76647ca499..6878dc1615 100644 --- a/video/out/vo_gpu_next.c +++ b/video/out/vo_gpu_next.c @@ -966,9 +966,14 @@ static void draw_frame(struct vo *vo, struct vo_frame *frame) ); // mpv likes to generate sporadically jumping PTS shortly after - // initialization, but pl_queue does not like these. Hard-clamp as - // a simple work-around. - qparams.pts = p->last_pts = MPMAX(qparams.pts, p->last_pts); + // initialization, but pl_queue does not like these. Hard-clamp to + // the first frame in the queue as a simple workaround. + struct pl_source_frame first; + if (pl_queue_peek(p->queue, 0, &first)) { + if (qparams.pts < first.pts) + MP_VERBOSE(vo, "Clamping first frame PTS from %f to %f\n", qparams.pts, first.pts); + qparams.pts = p->last_pts = MPMAX(qparams.pts, first.pts); + } switch (pl_queue_update(p->queue, &mix, &qparams)) { case PL_QUEUE_ERR: |