From 408b4e487739b65207be3f43686c5de2826195bf Mon Sep 17 00:00:00 2001 From: Vanilagy <1696106+Vanilagy@users.noreply.github.com> Date: Wed, 19 Nov 2025 11:29:23 +0100 Subject: [PATCH] WIP --- src/cursors.ts | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/cursors.ts b/src/cursors.ts index 14376ec..bedb406 100644 --- a/src/cursors.ts +++ b/src/cursors.ts @@ -193,10 +193,27 @@ export class PacketCursor { } } +/* for (const timestamp of timestamps) { const thumbnail = await cursor.seekTo(timestamp); console.log(thumbnail); } +*/ + +// Problem: Decoding further than is needed. This is not a problem for playback-like operations where it is desired to +// maintain a buffer of pre-decoded frames. It breaks down when using the cursor for quick, pinpointed seek operations. +// It would be cool if the cursor could still be used for pinpointed seeks. This provides a unified API for both +// sequential as well as random access patterns. +// Idea: By default, queue only the packets that are needed to reach a packet. Then, when encode size reaches zero and +// the thing has not been yielded yet, give it another group of packets. +// But that doesn't properly fill the decoder queue when just iterating using next(). +// Idea: Calling next() "unlocks" the decoder, keeping a healthy queue into the future until seek is called? I don't +// know, feels weird. What I like better is something like, queue until the target packet first, then when the +// decode queue drops to zero and there are no new requests, queue more packets. This means that in moments of silence, +// the next samples will be queued. I think this might be better than going off of next(). This is because I can think +// of use cases that don't need next() but still perform playback-like operations using ONLY seeks. +// Or: make it configurable? Like some sort of queueLength or maxQueueLength? Then it's controllable but also adds +// another layer the user has to "know" to do. export class VideoSampleCursor2 { track: InputVideoTrack;