Frames shifted / scratchy audio

[QuaddiMM]

I load uncompressed video in a script with no other filters and play the script with MPC. Every few frames the audio scratches and some frames appear shifted (appearantly read from shifted offset ~+/- 5000 Bytes as garbage appears on top or bottom of frame).

For testing purposes I save 'colorbars' video with VD to uncompressed "bars.avi" (~1.15 GB truncated to 1000 frames, direct stream copy).
"bars.avi" plays fine on its own in MPC and WMP 6.4, but when I load it with AviSynth (OpenDMLSource), the above error appears with both applications (MPC and WMP 6.4).

Also rendering via GraphEdit gives the error, but strangely, VD 1.7.8 does not (yes, no error playing the script with VD).

The problem does only appear with videos that have sound, and are opened with OpenDMLSource. When I use 'KillAudio' or 'audio=false' on the source, no error occurs (but also no sound).

Also, it seems to be multithreading related, as the problem disappears (after few seconds) when I set the playback-app to only use one core in task manager (have quadcore).

And finally, using 'AVIFileSource' instead of 'OpenDMLSource' solves the problem, but is no solution as it only works for small files.

Some specs:
- Using AviSynth 2.58 RC1, but also had the problem with 2.56 and 2.57
- WinXP Home SP2 32 Bit
- Intel Q6600 with 4 GB RAM

I can run further tests / post more info as needed. Also I'm able to debug AviSynth (but don't understand much of the source code).

[GodofaGap]

Have you tried simply using AVISource?

[QuaddiMM]

AVISource gave me the error in the very first place, but I read somewhere it gets redirected to either AVIFileSource or OpenDMLSource internally, so I didn't think it was worth to mention.

[QuaddiMM]

Here is an example:

http://img170.imageshack.us/img170/1254/shiftedframeng6.png (http://imageshack.us)

As you can see, the sides (grey/blue) are in the middle, and there is garbage at the bottom.
Taking some of the bottom pixels and saving them to a bitmap actually yields a sequence of bytes, which I was able to locate in the original avi.

Directly preceding the bytes is "01wb", 0x1904, and thereafter the frame is read. From Microsofts AVI RIFF File Reference (Link (http://msdn.microsoft.com/en-us/library/ms779636.aspx)) you can see that 'wb' means audio data. But the data is actually interpreted as uncompressed video frame.

The real frame starts 0x1904 Bytes later with "00db".
So I conclude, that the source filter mixes up audio/video data for some strange reason.
Also, as it doesn't happen with only one cpu core (instead of 4) enabled, there might be some race condition when updating internal file-pointers.

Do you have any idea what might cause this? I also really wonder if this didn't happen to anyone else?

[IanB]

Test this pleaseOpenDMLSource("blah.avi", False)
AudioDub(OpenDMLSource("blah.avi", True))

[QuaddiMM]

Test this pleaseOpenDMLSource("blah.avi", False)
AudioDub(OpenDMLSource("blah.avi", True))

That works fine, thanks.
do you think it's an error in avisynth or on my side?

[IanB]

OpenDMLSource() Opens the source file once, adds a splitter (not thread safe), then finally adds A&V decoders. AVIFIleSource() opens the file for each stream so the audio and video paths are separate.

Your app is reading the video and audio in different threads and this causes a race in the splitter between doing the Seek and the Read, i.e. Thread 1 does Seek, Thread 2 does Seek, Thread 1 does Read (Oops seek was overridden, wrong position) ...

Try this version here (http://avisynth2.sourceforge.net/AviSynth_080601.zip). It add some thread locking to the CAVIFileSynth class. Please report how it effect the problem.

[QuaddiMM]

With the new version, the problem seems to be fixed.
The discussed error is not present anymore, and as of now, I can't see any bad sideeffects.

It might also be of interest, that due to the error some MPEG-encoded avi became distorted during playback (blurry and sleaks). With your version, that is solved.
Maybe it would cause less tolerant codecs to crash?

Hoping the fix gets integrated into the next release.

I really appreciate your help. Thanks a lot!