An automated Vegas 24p workflow..

[Steve Szudzik]

Yes, that is correct.

--Steve

[Ajit Bikram]

Hi Steve,
I made your script work for me finally! Well the problem was not with my setup but I was doing something stupid while viewing the footage. Now the footage does look progressive. Thanks for all the help guys!
Well still there seems to be some issue with the audio. When I open the avs file in virtualDub it seems a little off. ( It says a framerate of 24.12 would match the audio perfectly instead of 23.976). Is that what you are getting?
And Farnsworth modified his script to include a delayaudio for 222 ms. Do I need to keep that while using your script? (which also includes another delayaudio command.)

[Ajit Bikram]

Hi steve,
can I suggest the following modifications to your script if doable?

1) Using VirtualDub instead of VirtualDubMod. As the latter one is no more developed it seems. The issue seems a minor one as the avs files from the script does work with VirtualDub if done manually but it gives an error if used via automated script instead of VirtualDubMod.

2) Instead of defining the codec's within the program if the program could list all the available codecs in a particular computer where its installed.

3) Once the script run is finished to generate the .avi file it would give an option to delet all the .mpa, .d2v and .avs files, so the output would be just the avi file.


I hope I am not asking for a lot!
Thanks

Ajit B.

[Steve Szudzik]

#1 VirtualDub would be just fine, it depends on which line of the script is producing the error though. I can play with that and see if I can make it compatable.

#2 would be great, I totally agree. I would love to pop up the same dialogs that VirtualDub does for picking which compression you want. That seems to dive into using the Video for Windows API though. I'd like to get that, but will probably take me some time since I'm not very familiar with that API.

#3. Yup, was thinking about that as well. That request is very simple to perform. I might get that one done today.

As far as the audio delay is concerned, if you check the box on my app, what I'll do is check the .AVS template produced by DGIndex (in the working directory) and pull the ms delay it's specifying for the audio delay. I'll convert that and update the AVS with a call for DelayAudio with the appropriate value. Like Mike has mentioned in some of the other threads, each clip needs a different offset. .222 was just the one that happened to work for Farnsworth for his particular clip.

You can also tell my app not to try to do the DelayAudio and then you can put your own value into your Template.AVS file, which will just get passed along through DGIndex..

--Steve

[Ajit Bikram]

Good morning Steve!

Well the error that comes up as a popup window while using VirtualDub says "Error during script execution at line 1, column 30: Member 'RemoveInputStreams' not found
VirtualDub.RemoveInputStreams<!>(); "

and as I told if you open the avs file manually in virtualDub later there seems no error. I hope this will help you to figure that out!

2) For the API call is it possible to look through the VirtualDub source-code? That might make the things easier for you! (May be a stupid idea! as I am not familiar with programming in windows!)


Well can you tell me the source of this audio delay. I mean how its getting created? Then perhaps things would be clearer to me.

Thanks

Ajit B.

[Steve Szudzik]

Yes, I have the error here as well. The reason you can open the AVS file (and I can as well) is that the REmoveInputStreams call is actually in the VirtualDub script file that I create (32Pulldown.syl) in the working directory. That's the file I pass to VirtualDub. If that line is not present, then even VirtualDub is happy. I'm not sure that's a good thing though...

I've found two other web pages referring to that error. Unfortunately one is in Spanish and the other appears to be in Russian. Google was able to translate the Spanish one, but there was no resolution that I saw there. I'll keep digging into it and see if I can figure that one out.

Yes, I downloaded the VDub source and had already done what you were suggesting. It's C code, which I'm a bit rusty at but I was able to get the gist of what they were doing. I just need to figure out how to convert that into C# code, two very different beasties for sure. I've seen some other C# code using VFW, but none around this particular set of calls though. Once I figure that out, we'll be golden.

Honestly, I'm not 100% sure what DGIndex is doing to figure out the delay. Mike might have an idea (he was the one that pointed me to getting the delay from the DGIndex generated AVS file).

Oh, I've got the request you made for cleanup done. I'll be posting that in a little while. Just trying to see if I can also get the VDub issue addressed as well.

--Steve

[Ajit Bikram]

Great Steve! At least some of things are progressing!
About the audio I think this delay is generated by DGIndex itself. So I am thinking if there are some alternative freeware to use which could do the same job.
May be MEPGstreamclip or something like that. What do you think?

[Steve Szudzik]

I've posted my updated binary to address the "post cleanup" actions. It's a checkbox next to the Delay Audio option. I also remove the "Video Files" tab and put it all together on one page.

Yes, DGIndex is determining that delay value. I have seen a few other threads talking about using MPEGStreamClip, but have not looked into them too much, so couldn't say how that would fit into the workflow.

--Steve

[Ajit Bikram]

Steve,
It seems we can avoid DGIndex by just open the m2t file directly!! Though the audio is still not perfectly in sync but its much better. (VDub with Farnsworth method and correcting audio sync with your script tells to put video to 24.15 instead of 23.976 to time them exactly.. while this method I am using is saying 23.955).

Well the way to open the m2t file directly the command is

DirectShowSource("xxx.m2t")

My avs script at the moment is

DirectShowSource("capture01-0064.m2t")
AssumeTFF()
telecide(guide=1, post=2, vthresh=30)
decimate()


and this works!!

Edit:
I am using the decomb filter from neuron2.net instead of the TIVTC plugin. They are almost same.

And thanks for your update! I am going to download it now.

[Mike Dulay]

Ajit,

MPEG Streamclip was the first method I tried. It did a deinterlace rather than a proper 3:2 pulldown removal. On occasion you get odd blips and blocks in the re-encoded video.

What OS are you on and which codecs do you have installed? Before using Farnsworth's method I had also tried the DirectShowSource method but VirtualDub/Dubmod would keep crashing when I dragged the AVS into it. I'm not sure if this is a Vista problem or my choice of codec packages (my main came with CCCP and SUPER(C)).

That variable frame rate you're getting is strange. Mine has always come up 23.976 whether using Farnsworth's or my version of the avs. Maybe its DGIndex, could you post a sample of your generated files if it persists?

Steve,

DGIndex examines the MPEG transport stream (think of TCP/IP packets and OOS reassembly) to generate the audio delay. It's a function of how the HDV codec laid down the video and audio from the camcorder. Since the start/pause and cadence isn't always the same per clip each one has a different delay. M2T files are close kin to TS files and M2V files you find in HDTV transmissions and DVDs. DGIndex source code is open, the routine for reading the stream should be in there, but would it be worth it to reinvent the wheel? Maybe if we were doing it directly from HDVSplit or our own capture program ... hmmm ...

[Steve Szudzik]

I too have been getting a consistant 23.976 fps in all of my test clips.

I did get the DirectShowSource to work, I'm also using Vista as well. Been using it for over a year at work and couldn't stand not having it at home! I don't think that Vista would be the problem for you Mike, but you never can tell.

I had thought about capturing myself, but I just don't have that kind of time to write the app! Guess that's why the Cineform folks get the $$$ ;).

--Steve

[Ajit Bikram]

Originally Posted by Mike Dulay

Ajit,

MPEG Streamclip was the first method I tried. It did a deinterlace rather than a proper 3:2 pulldown removal. On occasion you get odd blips and blocks in the re-encoded video.

What OS are you on and which codecs do you have installed? Before using Farnsworth's method I had also tried the DirectShowSource method but VirtualDub/Dubmod would keep crashing when I dragged the AVS into it. I'm not sure if this is a Vista problem or my choice of codec packages (my main came with CCCP and SUPER(C)).

That variable frame rate you're getting is strange. Mine has always come up 23.976 whether using Farnsworth's or my version of the avs. Maybe its DGIndex, could you post a sample of your generated files if it persists?

Steve,

DGIndex examines the MPEG transport stream (think of TCP/IP packets and OOS reassembly) to generate the audio delay. It's a function of how the HDV codec laid down the video and audio from the camcorder. Since the start/pause and cadence isn't always the same per clip each one has a different delay. M2T files are close kin to TS files and M2V files you find in HDTV transmissions and DVDs. DGIndex source code is open, the routine for reading the stream should be in there, but would it be worth it to reinvent the wheel? Maybe if we were doing it directly from HDVSplit or our own capture program ... hmmm ...

Well Mike now I kind of understood where this audio delay is getting generated. I had the idea that DGIndex is "creating" this audio delay so was thinking of replacing it with someother program that might put audio in better sync.

And abut the frame rate I think my explanation was not clear enough. I do get 23.976 fps. Those strange frame rates are the one required to match the audio and video durations exactly (as reported by VirtualDub from Video->frame rate) and neither Farnsworth script or Steve's exe can put the audio in exact sync in any of my clips. (I hope I am clear this time!)
But I think I should not worry about this small duration issues.

Oh and my os is win XP2 sp2. I have Lagarith, MSU and huffyuv codecs installed apart from some Intel ones that I think came with something! (I didnot install them).
I did install vista after building this desktop. But it needed toomuch resource to run itself and many a softwares I use werenot supported so I rolled back!

[Mike Dulay]

Ajit,

Since you're not demuxing the audio track its still trying to play itself at the original length. DGIndex is the most efficient way I know to get the delay.

http://avisynth.org/VariableFrameRateVideo

There is an avisynth script that interpolates the delay which isn't as efficient:

http://avisynth.org/FindAudioSyncScript

[Ajit Bikram]

I thought when I am using steve's exe (instead of my script) with the "Calculate required Delayaudio" box checked in it should demux it and give me same duration of video/audio. But thats what is not happening ( evident from those strange framerate requirement to match timing).
Or did I miss something?

[Mike Dulay]

Ajit,
When DGIndex runs it demuxes the audio track into an mpa (MPEG Audio file). The filename contains the delay value and that is what we (Steve's exe and my original PERL) read and recode into the Delayaudio() line of the avs script.