credits and framerate issue

[_Shorty-dammit]

Using AutoGK v1.86 beta that recently came out, along with the v1.03 XviD that it shipped with.

I'm not sure if there is an issue, actually. I guess I'm just trying to get something clarified. The .credits file lists a frame number of where you would like it to switch quality modes for the credits of a movie. I notice the hidden options util has a calculation tool in it for finding a frame number near the time that the credits start, but this only lets you pick 29.97fps or 25fps, with 23.976fps not being a choice. So with the movie I encoded today I picked 1:42:00 as my start of credits, and this calculator gave me a frame number of 183453 with 29.97fps selected. But the agk log states that the movie contains much fewer frames than that:

[05/01/11 3:23:52 PM] Found 156148 frames

But I didn't notice that until after it had finished encoding. So, I found the beginning of the credits, and made a copy of the portion of the movie from that point until the end. And then I reencoded it a second time, with a credits-start frame number of 146735 this time instead since this was the actual frame number where the credits started. I would imagine the reason the frame value given by the calculator is higher than the length of the movie would be arising from 29.97fps/23.976fps differences. So, I figured perhaps the first run-through just ended up having the entire movie encoded without any consideration for the credits, since the value in the .credits file was higher than the entire length of the movie. So after keeping a copy of the credits from the first encode job I ran it again with what seemed to me to be the correct frame number for the credits start, and hopefully this time the credits would eat up a lot less of the total filesize.

After the second encode job finished, I once again opened it up in virtualdubmod and made a copy of the credits and saved that with a different name from the first copy of the credits. And I was expecting the second copy to be a fair bit smaller. To my surprise there was very little difference in the size of the credits and I don't see any difference when I view them both:

70,694,912 credits-set by hidden options.avi
70,725,632 credits-set by me.avi

So I'm a bit puzzled. I guess there are a few different things that could be going on here.

1. Seeing that the credits start frame (183453) was higher than the total length of the source (156148), perhaps it assumed the value was from 29.97fps and adjusted it to what it should be for 23.976fps. Seeing as how the source really is 29.97fps anyways it probably wouldn't be much of a stretch to assume the value was given based on 29.97fps.

2. It ignored the value altogether and just encoded the credits without giving them any special consideration, since the value given was higher than the total length.

3. Both runs had nothing special done for the credits at all.

If we assume #2 happened, then you would think that when I encoded it a second time using a credits start frame number of 146735 that it would affect the credits that time since it got a value that was under the total length. But then it would seem to me that the credits should've been quite a bit smaller than the first run. Unless of course #1 was true and the credits start frame did get adjusted and the credits did get the same consideration as the second job did.

So, I guess what I'm trying to find out is, did I just fluke out and happen to get two copies of the credits that were almost the same size? Or did in fact both runs get the proper credits treatment? Or did both runs have absolutely nothing special done for the credits?

[fewtch]

I believe the frame number is related to the VOB and not the decoded frames (i.e. what AutoGK detects).

It should work fine based on the time calculation in Hidden Options, if it didn't then dunno what to say. Maybe you forgot to save the options, or saved in the wrong folder (it should go in the source folder where the VOB's are, not output).

[_Shorty-dammit]

well, both snipped clips of the credits are the same size, so, maybe the second job has some of the movie at the same quality as the credits. But it doesn't appear so, it looks fine during the last minute or so that I checked and compared. Both credits clips are pretty much the same size, so I'd guess they're probably both in the 20% quality setting. You'd think I'd notice though if some of the movie from the second job were also in 20% quality, when the rest of the movie is in ~88% according to the log.

edit - and the log for both runs did contain the values I mentioned in the first post, so I would assume it picked it up fine.

[05/01/11 3:23:52 PM] Found 156148 frames
[05/01/11 3:23:52 PM] Picking up credits information.
[05/01/11 3:23:52 PM] Credits start frame: 146735
[05/01/11 3:23:52 PM] Credits quality percentage: 20

[len0x]

Confusion arises when you read "found XXX frames". It should actually say "Output will contain XXX frames" as that takes into account IVTC etc. Credit start frame is always INPUT frames (i.e. before IVTC is applied).

P.S. I have no idea why you manual method worked as I would say it shouldn't.

[_Shorty-dammit]

well, I did an experiment and I just confirmed what you've said. It indeed uses the frame count contained in the vob files before IVTC occurs. I turned on greyscale and used a frame value of what 1:41:00 would be if it were 23.976fps, and the greyscale change occured much earlier in the movie than that. Which indicates the vob framerate is used. I assume that with my manual method it actually started the 20% quality encoding at 1:21:36, rather than 1:42:00, and that the credits were about the same size as the calculated method simply because it was still using the 20% quality setting at the time the credits started in both cases. It's just that in the manual case the 20% started before the credits start time, and I'm just not looking closely enough to see that during the movie before the credits start time the quality has changed.

So long story short, I've just confirmed your info, it uses vob framerate before any IVTC occurs. So the calculator in the hidden options util is indeed correct. Thanks for your help guys.