[vlc-devel] Re: Byte-accurate seeking in VLC

Utku Altunkaya utkualtunkaya at gmail.com
Fri Nov 10 18:01:22 CET 2006


Clément Stenac wrote:
> Basically, the stream facility can only be used by demuxers, so, no, you
> cannot use it from the access.

:(

> In your case, when you perform the seek, as you update info.i_pos, the
> demuxer being unaware of the corruption, notices that the pointer is not
> where it should be and orders a seek (through stream_Seek).

Hmmm, just as I had suspected...

> The correct solution is that your access module should hide the fact
> that it performed a seek to skip corrupt data. This is the correct thing
> to do because it is precisely the goal of your access. If your file is
> 300 MB, for example, the "useful size" is here 275 MB.
> So, you should seek corrupt data, but not update info.i_pos, and offset
> all further reads and seek requests by the amount of data skipped (if
> the read/seek is after the corruption). Basically, if there are several
> skips, your module should keep a list of "holes", and perform
> computation of real file access, based on what has been requested.

This is exactly what I had been doing up till now, but I was hoping to change my 
approach and started looking for a way to make VLC handle the seeks itself. Here 
is the reason:

Your suggested method works very well for files containing MPEG video, MP3 
audio, or other "streaming-friendly" filetypes. My access module tells VLC that 
the file is 275MB instead of 300MB, and VLC plays the file perfectly: The media 
duration is calculated correctly for the virtual file without the holes, I can 
seek within the file using the time slider, and the only glitch is a few 
momentary corrupt frames at the junction points where the holes were removed, 
which is of course expected and is not a problem at all.

However, when I use the same method for AVI files, although I tell VLC that the 
file is 275MB, VLC (the AVI codec) "knows", from the AVI header, that the file 
is actually 300MB and still tries to access the 300MB region for reading the 
index, and it of course fails since there is no such file position from my 
module's point of view. Thus, I lose the ability to seek correctly and the time 
slider doesn't work as expected. I could try and develop some elaborate scheme 
where my module recognizes index reads and allows access to the actual end of 
the file, or I would have to re-index the AVI file without the holes and thus 
provide accurate seeking again, but I feel that this is not an elegant solution 
and it is too much work for a simple access plugin.

I was hoping to establish some bookmark-like functionality pointing to the hole 
boundaries, and play through the file jumping from bookmark to bookmark to avoid 
the holes as soon as one is reached. Since I won't have to lie to VLC about the 
filesize, everything will work naturally: all important file structures 
(headers, tags, indexes) will be where they belong and will be properly read, 
and the time slider will work correctly if the user wants to seek within the 
incomplete file. Right now I'm very close to accomplishing what I want, but the 
"seek in 1% increments" restriction is holding me back, because that way 
megabytes of valid data is sometimes just skipped over and never played back.

If only I could, from my access module, instruct the demux module to seek to a 
specific location... That would be perfect. Or maybe I should devise some way of 
using time-based seeks, since they have better resolution.

I'll be glad if you can offer any solution to my dilemma.

Utku

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html



More information about the vlc-devel mailing list