Short seeks are sub-optimal
This issue is filed as a long term goal. GStreamers seeks (flushing seeks) are quite inefficient when operating close by seeks. This is particularly visible in video processing use case, where you want to scrub to a specific location. So far, the only solution has been to use key frame only compression (or proxy). I believe this situation could be improved.
When I say short seeks, I'm thinking of intra gop (group of picture) seeks. Let's take a small GOP using MPEG notation, I is keyframe, P is a delta frame.
I P P P P
0 1 2 3 4
If my pipeline is at position 0, and I see to position 1, GStreamer will decode:
I P
0 1
Then if I see at postion 3:
I P P P
0 1 2 3
So instead of decoding forward to the target position, we decode the gop from the start again and again. One of the work around is is to use STEP request. I think the step operation is quite suitable for the task here, but application does not have the knowledge of were the gop start. So optimization by step remains sub-optimal for few cases as the application endup defining what's a short seek, while in ideal case, you if there is a IDR frame on your way to your target, you want to jump there immediately.
What I would like to research is if it would be possible to introduce a fast seek, or maybe if demuxers could make use of step s during seeks when they the appropriate information (I'm thinking of ISOMP4 with it's complete index).