[vlc-devel] [PATCH] Patch to fix bug #1532, and improve http seek times.

[Laurent Aimar]

On Fri, Jun 13, 2008, Bill C. Riemers wrote:
> I guess I simply don't understand how CAN_FASTSEEK is supposed to be
> used.   But it is pretty clear from this discussion, that AVI's
> demux'ing is not an instance when FASTSEEK is needed.   Seek times on
> the order of 3x ping times is good enough for avi demux.   So I will
> correct the patch not to mark http has fastseek, and modify avi demux
> not to require fast seek.
 At start, FAST_SEEK was supposed to help demuxer choose their policy to
read the data, stating that seeking too much will destroy performance.

The avi demuxer will either:
 - seek for each sample when FAST_SEEK is true.
 - try to read data as they come when FAST_SEEK is not defined. It should
work on correctly interleaved data but yes it is not perfect. Seeking should
still be allowed (when requested by the user).
 - when both FAST_SEEK and SEEK are false, I think it uses the same code
than !FASt_SEEK without allowing the user to seek.

 The correct course might be to calculate the data the avi demuxer needs
to buffer to ensure reading all samples without never seeking beyond this
sliding buffer or at least to reduce it to a reasonable count per second
(and configure the stream layer to do it) in case FAST_SEEK is not defined.

 Btw, there is the same problem for .mp4 (except that the mp4 demuxer refuses
to open file if !FAST_SEEK)

-- 
fenrir