Avisynth Handling of strange fps (120fps) and Avi Dropped Frames

[bill_baroud]

Hi

The problem i encounter is quite unusual and complex to explain so i'll do my best,
although i have already reported something like that some times ago.


Material :
- avi file, 120fps (119.880) Xvid captured from japanese satellite (i suppose)
- vbr mp3 (-_-)

if you open file in vdub, images sequence is :

K DDD P DDD P DDD P DDD P ..... K

where
- K stand for K-Frame
- D for Dropped Frame (as Cyrius explained it to me)
- P for P-frame

image change only on P & K

i'm using Avisynth 2.07 and Vdub 1.5.1


Problem :
Avisynth seems to have hard time to deal with Dropped Frames
or with the unusual frame rate, it's output garbage.

I was suspected something from xvid but Vdub and DirectShowSource with ffdshow are fine
(that's why i posted here, feel free to move the post where it's belong).

avisynth :


virtual dub :


what's i'm actually doing, it's open the 120fps file in VirtualDub,
then frameserve it, open the .vdr in Avisynth, Decimate(4) it -to have 30fps output-,
and encode it in huffyuv in another vdub.

DShowSource with decimate gave me 30fps output,
but only 2 "real" images per second.

(just tested 2.51 and it's the same)




Here are my questions :

- First, is it a bug from Xvid decoding (i'm using Koepi Stable one)
or from Avisynth dropped frames handling ?
Or am i really dumb and i'm doing it completly wrong ?

- And second, can someone very advanced with capturing and
interlacing explain me, why there is some japanese guys (no offense to them !)
who encode with such a strange fps (it's not the first time i got files like that).

I somehow suspect Hybrid material (Ghost in the shell TV has a lot of CG scenes -like opening- )
and perhaps broken capture devices ?
But 120 fps is really cpu intensive to decode in real time with vobsub subtitle
(on my XP1600+)


Thanks you for reading me till here and perhaps enlight me on this case

cheers.

[mf]

Looking at the artifacts, it seems as if AVIsynth is feeding XviD the dropped frames as P-frames, where the P-frame is repeated 3 times causing it to repeat the difference on the previous frame 3 times.

In math, it would be like this:
K = 1
P = + 1
D = + 0

So vdub decodes this:
1
2
2
2
2
1

But AviSynth treats it as this:
K = 1
P = + 1
D = P

Causing it to decode this:
1
2
3
4
5
1

I hope this makes sense ^_^'

[bill_baroud]

thanks mf, so it's look like there is a problem in Avisynth :/



now i have to understand why they double fps 2 times.



Aristobule send me the culprit ^^; :

http://breizhbill.baroud.free.fr/avi60_07.zip



hope you like the japanese

[Aiorus]

I had the same problem, a Raw file for an Anime, I fixed it with AviUtil, doing 2/5 and 1/2 frames conversions. I hope that helps.

[Guest]

A point on Decimate(): If you are using Decimate() from the Decomb package, then to go from 120fps pattern to 30fps, you need:

Decimate(4).Decimate(3).Decimate(2)

Using just Decimate(4) will give you 90fps.

Decimate(2).Decimate(2) might also work.

[bill_baroud]

thx Neuron, i was doing Decimate(2).Decimate(2)

but if i remember well, Decimate(4) give me the same output ???


how could i know if i use your Decimate or the Internal one (with the plugins autoloading)

seems like the internal has priority

[Guest]

There isn't an internal one to my knowledge.

To see if mine is running, put show=true as a parameter to Decimate(). If you then see my copyright message on the output, then it is mine.

Decimate(4) will delete one frame out of every 4.

[ErMaC]

You do not need to use Decimate in this circumstance, in fact I think it might be a bad thing since you're decoding all the dropped frames. I dealt with this back in the first raws that exibited this drop frame thingy. Use SelectEvery(x,y,z) where X is the # of frames in a sequence, and y and z are the frames to take. For your example you would use:
SelectEvery(4,0)

[Guest]

Of course that is preferable. If the phase of the pattern changes it becomes a bit more complex.

[sh0dan]

Could you put up a few seconds of the material. Preferable with two or three keyframes present for us to test on?

[bill_baroud]

@shodan : no problem, i'll do that as soon as i can


i'll try to find a change in frame order (if there is one)



@ErMaC : thanks for the tips, it would be a little faster no ?

[lamer_de]

If the pattern stays,

ChangeFPS(29.97) [or whatever fps you need]

should work aswell. At least it did work for me when importing quicktime clips, which get added 100 frames between the actual frames everyime. But the SelectEvery command works fine aswell.

CU,
lamer_de

[APF_Gandalf]

here is a link (japanese but babelfish seems to work enough so you can understand it) that explains why they are doing this (stupid) 120fps conversion

http://www.kjps.net/user/r2-m2/clare/dtv/120fps.html

[bill_baroud]

here the sample :

http://breizhbill.baroud.free.fr/Gits2_sample.avi

it's about 7.8mb and cover the end of opening (full CG) and the begining of the ep (more classical animation)

the frame sequence seems to be the same for the whole file, and i just tested Motion Perfect for 29.97 > 23.976 and it worked amazingly !

i'm very impressed

[edit]
after a better look in Motion Perfect, the frame order change from
K DDD P (30fps) to K DDDD P (24fps) at 1:40 (i cutted from 1:20 to 1:40 T_T )

i'm reuploading a new sample : 3.98mb
[/edit]


@APF_Gandalf : thanks a lot !! now it make sense

5*23.976 = 4*29.97 = 119.88 ... it's somehow a solution for Hybrid/Mixed material



but in my case, it looks like the whole file was at 30 -_-

[ErMaC]

If you need me to translate the page I can explain what it says. Yay, Japanese Major actually coming in handy.

EDIT: Also the whole 120fps thing is stupid - you can do the same thing with 60fps by inserting alternating 1 and 2 drop frames so your sequence goes FDFDD for 24fps stuff and just insert every other frame as in FDFD for 30fps stuff. That's what the original raws which used the dropframe technique used (X episode 18 was the first one to appear if I recall) and it caused far less frame overhead than the 120fps crap.

[mf]

I don't really get the whole thing. It does make sense to take a common denominator (is that the word?), but it doesn't make sense when your original is 30fps anyway. If you're only inserting dropped frames I honestly can't imagine how this would be any different than not inserting them. It does work if you have two different fps clips and you want to merge them, but it doesn't look like that, and it'd involve some manual work. Anyone care to enlighten me ? I'm better at normal japanese than babelfish engrish and I don't understand much of both .

[ErMaC]

The usefulness of this tool is when you want to encode a show which has both 30fps and 24fps segments into a single file without encoding redundant frames in the 24fps segment (which would introduce jitter) or blending frames in the 30fps segment.

This can be achieved by taking the 24fps footage, adding dropped frames to make it 60 or 120, doing the same to the 30fps footage and then merging the files using VirtualDub's append segment function.

That's the shortest way to explain it.

[mf]

Originally posted by ErMaC
This can be achieved by taking the 24fps footage, adding dropped frames to make it 60 or 120, doing the same to the 30fps footage and then merging the files using VirtualDub's append segment function.

Right. So that comes down to this:

Originally posted by me ;p
It does work if you have two different fps clips and you want to merge them

Thanks for verifying.

[bill_baroud]

@ErMac : thanks for the offer, but i won't disturb you as it's seems to be clear that this 120fps is just crap ....

It does work if you have two different fps clips and you want to merge them

but it can be usefull when say, you have the opening at 30fps progressive and the rest of the ep at 30fps telecined (hum, i'm not quite sure of the terms ^^; )

in this case you have to ivtc the telecined part and desentrelace the other and then join it to have something smooth.

sure it can be achieved at 60fps like ErMac says, but it make some sense to me
(or there is a better way ?)


[edit] hm after a re-reading, i'm just saying the contrary of my first sentence ... oh well ^^; [/edit]

[sh0dan]

Think I found the bug (or rather a workaround for a bug in the codec). You clip now produces correct results. There is a new CVS binary up. Everyone using captures - please test!!

Thanks for providing such a good sample! Without the sample it would have been impossible to track down!