Frames shifted / scratchy audio

QuaddiMM · 3rd June 2008, 21:47

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 · 3rd June 2008, 22:01

Have you tried simply using AVISource?

QuaddiMM · 3rd June 2008, 22:18

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 · 4th June 2008, 16:53

Here is an example:

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) 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 · 6th June 2008, 06:54

Test this please

Code:

OpenDMLSource("blah.avi", False)
AudioDub(OpenDMLSource("blah.avi", True))

QuaddiMM · 8th June 2008, 16:13

Quote:

Originally Posted by IanB

Test this please

Code:

OpenDMLSource("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 · 9th June 2008, 00:17

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. It add some thread locking to the CAVIFileSynth class. Please report how it effect the problem.

QuaddiMM · 9th June 2008, 17:27

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!

3rd June 2008, 21:47	#1 \| Link
QuaddiMM Registered User Join Date: May 2008 Posts: 10	Frames shifted / scratchy audio 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).

6th June 2008, 06:54	#5 \| Link
IanB Avisynth Developer Join Date: Jan 2003 Location: Melbourne, Australia Posts: 3,167	Test this please Code: OpenDMLSource("blah.avi", False) AudioDub(OpenDMLSource("blah.avi", True))

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

3rd June 2008, 22:01	#2 \| Link
GodofaGap Registered User Join Date: Feb 2006 Posts: 823	Have you tried simply using AVISource?

3rd June 2008, 22:18	#3 \| Link
QuaddiMM Registered User Join Date: May 2008 Posts: 10	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.

4th June 2008, 16:53	#4 \| Link
QuaddiMM Registered User Join Date: May 2008 Posts: 10	Here is an example: 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) 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?

9th June 2008, 00:17	#7 \| Link
IanB Avisynth Developer Join Date: Jan 2003 Location: Melbourne, Australia Posts: 3,167	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. It add some thread locking to the CAVIFileSynth class. Please report how it effect the problem.

9th June 2008, 17:27	#8 \| Link
QuaddiMM Registered User Join Date: May 2008 Posts: 10	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!