Excessive seeking playing AVI files with a start-time offset

[carath63]

I am doing some development on an input plug-in and have discovered some odd behavior when playing an AVI file with a --start-time offset. My plugin is logging requests to seek within the file, so this is how I noticed the issue.

If I play an AVI file from the beginning, (that is, without the --start-time option), I see the expected seek to the end of the file to read indexing information, then a seek back to the beginning, and then no more seeks unless I am rewinding or jumping ahead in the file.

If I add a --start-time offset to the command line, I see a continuous stream of seek requests, alternating between seeking backwards and forwards. For example, I'll see a seek to position 10000000, followed by a seek to 10100000, then a seek to 10010000, then 1011000. (These are not the actual offsets, but show the pattern I'm seeing). It's almost as if two different parts of the player are trying to get data from the AVI at different places.

Any idea where to start looking to find out why this is happening?

Chris Rath

[DJ]

I'm not quite sure if this is relevant, but I have noticed that VLC doesn't like time large time corrections when making files with other programs. You end up with a lip sync drift and rather poor seeking within the file.

I have also noticed this with some other players. The container or the format doesn't seem to play a large part in the problem. Of coarse the correct way to do this is trim the file so there is no offset and this does resolve the issue. It is very possible this effects the interleave of audio and video, which would also make some sense for the seeking problem.

Now most of the files that float around are rips and the majority of programs to do this can leave an offset if not used properly and this does elude many users. The offset is generally between .5 and .7 seconds which is not small and very noticeable. There is nothing you can do to bring this back into ADR spec even after spending many hours with it. In the same time you can edit the material and achieve perfect sync but this also eludes many users. Considering all these things I'm not sure there is a good solution other than education, but in most common cases the majority of this is copyrighted material. I don't know about your country, but this is illegal in mine. Even discussing the techniques, problems or resolves can meet with extreme opposition. So it seems education is out of the question in this matter.

[carath63]

After inserting a bunch of debugging messages and staring at the AVI demuxer code for a few hours I found the bug that is causing the seek thrashing behavior I noted in an earlier post.

The problem is in modules/demux/avi/avi.c in the Demux_Seekable() function. I have verified that the problem exists in the official 0.8.5 source and the svn trunk version of the source.

After the toread structures for each of the tracks has been initialized, there is a section of code that searches all tracks with data to be read and tries to find the one with the lowest position in the AVI file itself. The code keeps track of the track and the position in i_track and i_pos respectively. The current code checks to see if i_pos has not been set yet, or if it is greater than the read position for the current track as follows:

if ( i_pos == -1 || i_pos > toread[i_track].i_posf )

This is in fact incorrect. For track 0 it works because i_pos is -1. However, for all subsequent tracks, it is actually comparing the current lowest position (i_pos) with the position in the current track with the lowest position (toread[i_track].i_posf), rather than the current track.

The code should read:

if ( i_pos == -1 || i_pos > toread.i_posf )

I do not have an svn account for vlc, so I'm hoping whomever is responsible for modules/demux/avi/avi.c is reading this and can put the fix in.

Chris Rath