Seek within queue if seeking to an already queued keyframe

[clsid2]

Currently the queues are emptied when seeking. That is wasteful and inefficient particularly for online streams. Could this be improved?

Suppose we are seeking to timestamp X.
For each A/V pin, check if X falls within range of queued frames.
For active video pin (if any), check if X corresponds to a keyframe.

If those conditions are met, then there should be no need to reset the demuxer, right? Just remove all frames from queue up to X and flush pins.

[Nevcairiel]

The queue is only a few seconds long, that seems like a special case with little use to me

[clsid2]

If the queue could be used more effectively, then users would have a good reason to increase default queue sizes in the settings. Short seeks (5-20s) are fairly common and this would certainly help with latency in such case.

[kasper93]

What you're asking for is essentially a demuxer cache, which I imagine would require a fairly significant architectural change in LAV Filters.

Shameless plug, but use mpv for online streaming, it already has a very capable cache implementation that handles this sort of use case quite well. In a biz, this functionality is often referred to as "time-shifting" for live streams.

/me runs away

[bibsp]

@Nevcairiel clsid2/mpc-hc#3917
This is the use case. And I requested because all popular players on earth have fast seeking capability.

Add atleast 1 minute forward cache. Or if you think 1 minute forward cache is too much then give option to customize either in minutes or in MB.
Because for 1080p stream 1 min cache will barely take 50-100MB on RAM.

[Nevcairiel]

LAV Splitter was never designed as a web streaming source, as doing that well requires quite some different decisions, support for network protocols is only offered because its easy and practically free.

But I don't currently plan to spend a significant amount of effort on streaming improvements.

[kasper93]

LAV Splitter was never designed as a web streaming source, as doing that well requires quite some different decisions, support for network protocols is only offered because its easy and practically free.

But I don't currently plan to spend a significant amount of effort on streaming improvements.

This could be implemented by a 3rd-party DS filter that sits in between LAV Splitter and LAV Decoder(s), with the sole purpose of caching the data, and providing fast seek, time shifting functionality and so on. It doesn't necessary need to be implemented in LAV Splitter, as the caching is mostly outside of the scope of it, which is focused on demuxing job.

[clsid2]

It might also help with local files without seek index, such as TS.

Isn't all the network stuff abstracted away in the FFmpeg demuxer? I mean is the underlying protocol or format even relevant. Isn't it just a simple matter of skipping ahead in the existing queues when possible? At least for basic forward seeks. I am not asking for full caching to also support backwards seeks, etc.