Broken picture after seeking

Hi All,

I've found a new seeking problem:

sometimes the picture is broken for 1-2 seconds after seeking, usually if the seeking is too fast (rapid position changes), and FrameDelay is not one.

I've tested it with the latest 4124eded commit.

Before 2a00fb6d , I don't see this problem. (from 2a00fb6d to 3262e3d0 , the seeking halts the decoding)

The testing video is the usual AV1/4k stream of this YT video https://youtu.be/U-6wqFE79Gc (downloaded to MP4, tested locally),

but this issue is happening at other files/streams too.

See the attached picture for reference.

Thnx

changed the description

Does it help if you set c->cached_error to 0 in dav1d_flush() (in lib.c)?

It's seems it's already done in 4124eded

I used that version at making the attached picture.

changed the description

What software do you use for testing (since dav1d has no mp4 support)? ffplay? Something else?

Doing a quick read of the code. I think the problem is 3262e3d0. We should clear cf (inside dav1d_decode_frame_exit()), which is only done if retval != 0, but 3262e3d0 changed that to 0. Probably best to call dav1d_decode_frame_exit() with -1 or similar, and after that clear f->task_thread.retval in dav1d_flush():

diff --git a/src/lib.c b/src/lib.c
index f851f2d5..255e79ea 100644
--- a/src/lib.c
+++ b/src/lib.c
@@ -581,12 +581,13 @@ void dav1d_flush(Dav1dContext *const c) {
         for (unsigned n = 0, next = c->frame_thread.next; n < c->n_fc; n++, next++) {
             if (next == c->n_fc) next = 0;
             Dav1dFrameContext *const f = &c->fc[next];
-            dav1d_decode_frame_exit(f, 0);
+            dav1d_decode_frame_exit(f, -1);
             f->n_tile_data = 0;
             Dav1dThreadPicture *out_delayed = &c->frame_thread.out_delayed[next];
             if (out_delayed->p.data[0]) {
                 dav1d_thread_picture_unref(out_delayed);
             }
+            f->task_thread.retval = 0;
         }
         c->frame_thread.next = 0;
     }

Can you test that?

The above solution corrects the reported bug. Thnx.

But I've found an other 'bug':

The speed of seeking (the speed of dav1d_flush() ?) is very slow using 'FrameDelay > 1',

comparing it with 'FrameDelay = 1' mode or with the previous v0.92 release.

(the seeking speed loss is significant)

This is also a relatively new bug, the seeking speed was still good at 0dc1d353

Please start a new issue for the seeking performance regression.

If seeking is slower, it sounds like some task threads are ignoring c->flush = 1. We can look into that.

mentioned in merge request !1392 (merged)

Agreed with placing this in a new bug report by the way, but from your comment, it's not clear if you bisected it to that commit. Could you clarify? And if not bisected, would it be possible to bisect? I'm going through the code ATM and don't see anything obvious yet, so any additional information would be welcome.

Could you also provide some information on what software you use for seeking? (I'm assuming it's not dav1dplay.)

closed with commit e3f4c700

closed with merge request !1392 (merged)

changed milestone to %1.0.0

added mismatch label

If you'd like to discuss in a more interactive way, IRC may be a useful way to find us. I'd really like to get to the bottom of this, so please don't let this slide. (We're not able to reproduce ATM...)

I don't see exactly what is the relation, but the 56fc43ae speeds up the seeking too. (probably it speeds up the decoding of the first frame(s) after seeking, so the seeking was not slow, just the output frames couldn't come out between the repeated dav1d_flush callings)

Now there's no (testable) difference between the 0dc1d353 and the latest 5fb9f3a4 version at the seeking speed.

And currently I don't see any decoder/seeking issues. Thnx