VirtualDub framerate conversion inaccurate

[FredThompson]

OK, here's what I started with:

PAL AVI (old Ligos codec, yuck)
NTSC DV from a camcorder

The goal was to stitch parts of these together.

OK, I loaded the PAL AVI into VirtualDub then saved it as DV. Then I loaded that file, did a frame rate covnersion to 29.970 and saved it. (Saving at each step so backtracking is possible.)

So, the converted-to-29.970fps video is loaded and I tried to append the camcorder NTSC DV AVI.

No go. VirtualDub reports different frame rates: 29.96973 and 29.97003.

Well, crud.

How to fix this? The difference is 3/10,000 of a second.

That means the streams would be off by 1 second every 3,333 1/3 seconds which is 1 second every 111.222333444... minutes (cool sequence, huh?)

That's not too much to be concerned about for most applications.

Still, it's an editing problem because VirtualDub won't stitch the files.

My guess is the quick fix is somewhere in the file headers. There must be something that defines the framerate and those values are slightly different between these two files.

Does anyone know how to force VirtualDub to be more accurate or, perhaps, a utility to edit the frame rate with this very fine level of precision?

I looked at the sync-locked version of VirtualDub at http://www-user.rhrk.uni-kl.de/~dittrich/sync/ but it appears to be just a sync fix for analog captures.

In this particular case, there is no audio so that's not an issue.

VirtualDub's resync was consistently giving a rate of 29.96973 no matter what the source was.

So, I'm stumped. What should the rate actually be and what is the most efficient way to fix it?

[manono]

Hi-

I believe it's a common problem (I've run into it before anyway). One solution that should work is to change the frame rate of BOTH (to, say, 30fps), join them, and then when done, change the frame rate back to 29.97fps.

[FredThompson]

Yes, but that's a LOT of processing to change what should be just a header byte and it would have to be done to every DV segment.

I just tried converting the PAL to 29.97003 fps and it still came out 29.96973.

Something must be screwed up inside VirtualDub.

[FredThompson]

(Gad, I hate the dynamic nature of this type of board. Hit one wrong key and the edit session is lost!!!)

OK, I've figured out a way to fix PAL-converted-to-NTSC-with-VirtualDub.

http://members.aol.com/wjm4kenpo/wjm107.htm

This page shows the frame rate is stored in the headers bytes of an AVI file at offsets 128-135 (80h-87h)

128 TimeScale 4bytes Long
132 IntegerRate 4bytes Long

Frame Rate (samples/sec) = IntegerRate / TimeScale

http://www.codeproject.com/tips/frhed.asp

Using this free hex editor, I found the following values:

Original NTSC: E9 03 00 00 30 75 00 00
PAL---->NTSC: E9 03 00 00 2F 75 00 00
------------------------------->**

There's the problem.

I've looked at a bunch of other AVI files from various sources and it is not uncommon to see different frame rate values. There really isn't a way to know by looking at the files what the proper NTSC set of values is for these two bytes. I guess proper for the user is their most common format from the equipment they use, huh?

I went looking for simple utils to allow directly editing these values.

http://www.am-soft.ru/avifrate.html

AVIFrate reports the original NTSC has a scale of 1001 and a rate of 29999.

Ok, so open the PAL file with AVIFrate and enter those two values. Guess what? It won't work. AVIFrate forces the rate to 29998.

Grrr...back to frhed to manually edit.

[FredThompson]

Originally posted by FredThompson
(Gad, I hate the dynamic nature of this type of board. Hit one wrong key and the edit session is lost!!!)

OK, I've figured out a way to fix PAL-converted-to-NTSC-with-VirtualDub.

http://members.aol.com/wjm4kenpo/wjm107.htm

This page shows the frame rate is stored in the headers bytes of an AVI file at offsets 128-135 (80h-87h)

128 TimeScale 4bytes Long
132 IntegerRate 4bytes Long

Frame Rate (samples/sec) = IntegerRate / TimeScale

http://www.codeproject.com/tips/frhed.asp

Using this free hex editor, I found the following values:

Original NTSC: E9 03 00 00 30 75 00 00
PAL---->NTSC: E9 03 00 00 2F 75 00 00

There's the problem, byte 132 (84h).

I've looked at a bunch of other AVI files from various sources and it is not uncommon to see different frame rate values. There really isn't a way to know by looking at the files what the proper NTSC set of values is for these two bytes. I guess proper for the user is their most common format from the equipment they use, huh?

I went looking for simple utils to allow directly editing these values.

http://www.am-soft.ru/avifrate.html

AVIFrate reports the original NTSC has a scale of 1001 and a rate of 29999.

Ok, so open the PAL file with AVIFrate and enter those two values. Guess what? It won't work. AVIFrate forces the rate to 29998.

Grrr...back to frhed to manually edit.

[FredThompson]

I just used AviSynth's ConvertFPS routine with an argument of 29.97003. The generated file is recognized as 29.97003 by VirtualDub but it won't stitch because those 8 bytes are different. When they are changed to match the values in the NTSC original, VirtualDub will append as usual.

For now, there appear to be two "solutions":

1) load each clip into VirtualDub and write it back out with a converted frame rate.

2) Edit those 8 header bytes manually.

[stickboy]

If you're going to use Avisynth, why not have Avisynth join both files (and call AssumeFPS (or ConvertFPS) as necessary)?

[FredThompson]

In this case, there is only 1 PAL file and it makes far more sense to convert it only. This is 1 of a large number of source files that get reused.

It turns out even the idea of editing the framerate bytes is causding a problem. The PAL source was encoded with an old Indeo version and something just isn't correct. I'll try saving it with HuffYUV then AviSynth to DV then header byte editing.

This is a royal pain in the butt. It's odd that VirtualDub wants the exact same header bytes when there are multiple ways to get the same frame rate.

[stickboy]

I think it makes more sense to stop torturing yourself over this, stop wasting your time, and just stitch everything together with Avisynth. It's simple enough:AVISource("PAL.avi").AssumeFPS(29.97) + AVISource("NTSC.avi").AssumeFPS(29.97)I think that this should be a fast operation, since AssumeFPS doesn't create or delete frames.

Or, have you tried:AVISource("PAL.avi").AssumeFPS(29.97003) + AVISource("NTSC.avi")?

[FredThompson]

The framerate needs to be adjusted by generating extra frames. If that is not done, the PAL portion will appear to play too fast.

This is stock footage and needs to be used for a number of different things at different times. That's why the best solution is to set the framerate properly.

I believe the framerate incompatibility is coming from AviSynth's filter but maybe it's from the DV codec (MainConcept 2.04.)

An extracted (with Video Vegas 3) NTSC DV segment has these values at bytes 80h-87h:

E9 03 00 00 30 75 00 00

AviSynth's ConvertFPS(29.97003) fed the PAL Indeo source and saved as DV (via VirtualDub) yields these values:

00 00 08 00 00 9F C2 EF

Both sets yield a framerate of 29.97003 but, as you can see, they are different values and VirtualDub will not append them.

The vast majority of my stock is NTSC DV because that's the camcorder's format. Therefore, the best solution is to do the conversion then manually edit the header bytes so they match the stock DV values.

When I do that, everything seems to work properly, both appending and seeking through the file. There is an image quality hit but that's allowable for this particular footage.

I have noticed a few problems with VirtualDub filters on the converted video. For example, the improved 2D cleaner will crash every time at the same place.

[stickboy]

Originally posted by FredThompson
[B]The framerate needs to be adjusted by generating extra frames. If that is not done, the PAL portion will appear to play too fast.Duh, right. Okay.

Sorry I'm being so dense, but I still don't understand why you can't do all the joining in Avisynth. Any performance hit would be pretty minimal, I think.

Does AVISource("PALclip.avi").ConvertFPS(29.97003) \
+ AVISource("otherfootage.avi")not work?

If not, what about: AVISource("PALclip.avi").ConvertFPS(29.97003) \
+ AVISource("otherfootage.avi").AssumeFPS(29.97003)?

[FredThompson]

The option (after figuring out the header byte issue) was edit 8 bytes and be done with it or write filters every time that clip was to be used.

Pretty simple choice.

Also, what if the odd header values created a problemw with some other application or hardware?

It's weird, actually. I wish VirtualDub would recognize the values are equivalent and just work but maybe it's best to have the bytes exactly the same.