• Thanks: 4

Re: Audio sync issue with capture device and SVP 'Auto' threads

I don't know, with ffdshow development pretty much stopped, I don't know how these issues will ever get resolved properly. There should be absolutely no need for the user to ever have to compensate for any of these delays. Putting workarounds in of adjusting audio delay to compensate isn't really a proper solution in my opinion. I hope you agree.

I guess theres no way to get SVP working outside of avisynth / ffdshow, its completely dependent on avisynth at the moment?

Re: Audio sync issue with capture device and SVP 'Auto' threads

I'm not sure it's a ffdshow issue but a capture device and/or video player.
Someone has to sync audio and video branches in DS graph.

http://stackoverflow.com/questions/1904 … ronization

=======
From there:

Audio renderer controlling the DirectShow stream time;

  • Thanks: 4

Re: Audio sync issue with capture device and SVP 'Auto' threads

Oh I know, and the players / renderers even bundled with SVP do a great job of keeping them in sync (mpc, madVR, LAV, reclock etc) once the timestamps are correct. But if they are fed incorrect timestamps they have no hope, and we need to add workarounds of adjusting audio delay etc which isn't the right approach.

Is there nothing that can be done without avisynth / ffdshow developers to look into this?

  • MAG79
  • SVP developer
  • Offline

Re: Audio sync issue with capture device and SVP 'Auto' threads

mark007
Lets ask again oviano is video delay constant in time?
If delay is constant then it is not timestamps problem at all.
It is just wrong alignment audio and video at capture start. Think about it.

  • Thanks: 4
  • Thanks for the post: 1

Re: Audio sync issue with capture device and SVP 'Auto' threads

OK I used ffdshows OSD feature to output details about timestamps, frame numbers, and asked it to write to file the details about the first 100 frames.

Using the same script to interpolate by eg 60/24, the output should be the same each time. If I keep the buffers / threads the same, the timestamps remain the same. If I change them the timestamps change.

To me this is a 100% indication that there is some logic problem somewhere. The timestamps shouldn't change at all, they should always be the exact same no matter how many threads or buffers are used. Otherwise its a bug.

  • MAG79
  • SVP developer
  • Offline

Re: Audio sync issue with capture device and SVP 'Auto' threads

mark007
Looks like you are right.

  • Thanks: 4

Re: Audio sync issue with capture device and SVP 'Auto' threads

Do you think this is ffshow avisynth SVP or some combination of all.  Its probably a missing +1 or -1 somewhere  smile  I wish I could help more but all I can do is report my findings.

  • MAG79
  • SVP developer
  • Offline
  • Thanks: 1101
  • Thanks for the post: 1

Re: Audio sync issue with capture device and SVP 'Auto' threads

We need to apply scientific method: divide and rule smile
Just check if timestamps changed on buffer size or threads number separately changes.

  • Thanks: 4

Re: Audio sync issue with capture device and SVP 'Auto' threads

Looks like only buffer effects the timestamps. Whats the next step in narrowing down the source of the issue  smile

  • MAG79
  • SVP developer
  • Offline

Re: Audio sync issue with capture device and SVP 'Auto' threads

If you mean frame buffer ahead in ffdShow properties window (avisynth tab) then video delay is ffdShow issue.
We can ask ffdShow developers to fix it.

  • Thanks: 4

Re: Audio sync issue with capture device and SVP 'Auto' threads

Cheers that sounds great. Would you have any contacts that you feel might be interested to fix it.   smile

  • MAG79
  • SVP developer
  • Offline

Re: Audio sync issue with capture device and SVP 'Auto' threads

mark007
I look to svn history details about ffdShow tryout project.
The main developer is clsid. Avisynth tab was changed last time by h_yamagata (2 years ago).

  • Thanks: 4

Re: Audio sync issue with capture device and SVP 'Auto' threads

Oh wow OK. Is this something I can bring to them or as a dev do you want to bring to them  smile

  • Thanks: 5

Re: Audio sync issue with capture device and SVP 'Auto' threads

MAG79 wrote:

mark007
Lets ask again oviano is video delay constant in time?
If delay is constant then it is not timestamps problem at all.
It is just wrong alignment audio and video at capture start. Think about it.

I find the video delay depends on the number of buffers, which in turn depends on number of SVP threads setting.

I think this backs up what you have found mark007? I see you've also posted on the doom forum thread - nice one maybe someone will be able to help.

  • Thanks: 4

Re: Audio sync issue with capture device and SVP 'Auto' threads

Yeah I asked in the ffdshow thread, hopefully clsid might get back, hopefully its something they can spot and fix easily

  • Thanks: 4

Re: Audio sync issue with capture device and SVP 'Auto' threads

Looks like clsid doesn't know the ffdshow aviaynth code. Can SVP ever work outside ffeshow or not need ffdshows buffers? With buffers off video is perfectly smooth for me but desync is really bad

  • MAG79
  • SVP developer
  • Offline

Re: Audio sync issue with capture device and SVP 'Auto' threads

I found interesting description of avisynth frame buffer work in ffdShow from its developer Leak: #12 Improved AviSynth Buffering (may 2007)
Thread has 6 pages of discussion.

mark007
I can't find your discussion with clsid. Found only this: ffdshow avisynth Buffer back/ahead (april 2013)

  • Thanks: 5
  • Thanks for the post: 1

Re: Audio sync issue with capture device and SVP 'Auto' threads

It's here:

http://forum.doom9.org/showthread.php?p … ost1668162