AVI Framerates, Directshowsource and sync...

[Jeff D]

Any advice on how to find an avi's actual framerate?

A coworker captured some stuff that vdub is reporting back as 30.000 fps. When I play the avi by itself in media player it's in sync. When I have a script of:
DirectShowSource (file)

the video is playing faster than it should.
telling DDS to use 30fps gives the same results. I've tried fps=15 and that works better, but still not exactly correct.

The source fourCC is CRAM, audio at 22.050 Khz and mono. But, that's about all I know.

Is there any tool that will give me the real framerate that I can feed to DDS so that the clips stay in sync?

Thanks!

[unskinnyboy]

First off, what VirtualDub says is correct. You can also use tools like GSpot, Avinaptic, MediaInfo etc. to cross check this.

Secondly, you shouldn't use DirectShowSource() for AVIs. Use AVISource().

[Jeff D]

Thanks.

AVISouce previously wasn't working nicely with this file. I just tried again and now it's complaining about not being able to open the stream in any supported format. not sure why that's happening now. But the previous passes the problem was video which would black out or show other garbage.


EDIT: Upon reverting back to Avisynth 2.5.7 the AVISource script again plays. Incorrectly but plays.

[foxyshadis]

This issue just came up, look in this thread (https://forum.doom9.org/showthread.php?t=137904) for fixes.

[IanB]

Gee for .AVI files generally loading them into VirtualDub and clicking File->Info is a very good place to start. For other A/V container formats there are equally suitable tools to retrieve similar information.

VDub shows most of the important information you need to know to analyse such a problem. Things like nominated frame rate, number of frames, nominal duration of both the audio and video tracks, etc...

Armed with this information you can then write an Avisynth script to repair and adjust the parameters to values that suit your current use. All of the values are available as properties of each clip, so you can code quite complicated mathemagical formulae to do whatever your heart desires.

Some useful formula to start you thinking :-

* Video_Duration=FrameCount()*FrameRate()

* Audio_Duration=AudioRate()*AudioLength()

The thread Foxyshadis points to, show examples of forcing Audio Length to match Video Length and vice versa.

Of course if you extract the relevant information and post it we might even be able to offer an appropriate script.

Note! Script integers are signed 32 bit so AudioLength() can return incorrect results for long audio streams (i.e greater than 2^31 samples). AudioLengthF() returns the sample count as an IEEE 32bit float, this allows access to the correct magnitude result but at reduced precision.

[Jeff D]

Thanks guys. Ian I tried your resampling technique from the other thread and that didn't work. One important thing is the I can't get the video to play correctly with AVISource, video only works correctly with DirectShowSource and then the audio is out of sync.

What I did as a work around was to resave the source files in vdub as uncompressed avi files and then AVISource worked fine.

It's working, but I'm not too sure what it was about the original source that was causing avisynth (or avisource, directshowsource) to have problems...

If you want to look at this unexciting clip I can post it somewhere.

[IanB]

@Jeff D,

Or you could just tell use the parameters that VDub reports in it's info screen.

[Jeff D]

http://www.movingstuff.com/avi_vdub.bmp

Anything look strange there? I thought there were some issues with frame sizes that large, but I've also read there weren't problems.

[Blue_MiSfit]

Well there's something wrong with whoever decided to capture 1024x768 using Microsoft Video 1...... :rolleyes:

But other than that it looks ordinary enough to me. I'm surprised AVISource doesn't handle it correctly.

~MiSfit

[Jeff D]

Well there's something wrong with whoever decided to capture 1024x768 using Microsoft Video 1...... :rolleyes:


your comment made me laugh.

I'm right there with yah. I have no idea why that size was picked, but they had a reason....

[setarip_old]

@Jeff D

It's not so much the size that was chosen, it's the ANCIENT video codec that was chosen...

[foxyshadis]

It's probably the default of whatever screen recorder software was used.

[Wilbert]

When you use either AviSource or DirectShowSource, it seems to me that your are playing your script. If this is true, you should encode it first and play your encoding to see whether its correct.

Upon playback, you might get into problems (depending on the player), because of this sample rate: 22.050 Khz. Try to resample it:

AviSource(...)
SSRC(44100)

[Jeff D]

Wilbert that's one of the things I played with. THe odd thing is that the video was faster than the audio. At 22K or even mono I'd think the audio would be faster, but that's not what was happening. Again this was DirectShowSource having the sync problem. AVISource had the display problems.

At least I found a way to work around the problem, just hope no one else hits this. =)