Log in

View Full Version : 1st pass stopping after 65536 frames


mmortal03
18th October 2004, 22:59
I am using 0.32.0 beta. I am trying to encode some HDTV content into Xvid. I have already demuxed the stream into mpv and ac3 files and created the d2v and avs files, and set all the settings in GK. Here is my log of queue, from the 1st pass. It is stopping significantly early, and should have lasted at least 2 hours. It is only encoding the first 65536 frames. I recreated my d2v and avs files, and went back through the process completely, and I received the same results:

4:20:42 PM: Started Xvid - First Pass: E:\FLatTN.avs
5:35:17 PM: Finished Xvid - First Pass: Duration: 1 hour, 14 minutes, 35 seconds.
5:35:17 PM: Trying to open Log-file.
5:35:17 PM: Success: Log-file open.
5:35:17 PM: Encoded: 65536 Frames.
5:35:17 PM: Speed: 14.644 Frames per Second.
5:35:17 PM: WARNING: Number of counted frames differs from settings!
5:35:17 PM: WARNING: Settings: 141746
5:35:17 PM: WARNING: Counted: 65536
5:35:17 PM: WARNING: Difference: 76210
5:35:17 PM: Correcting Bitrate...
5:35:17 PM: Original Bitrate = 7547 k(=1000)Bits/s
5:35:17 PM: Error: Correction impossible.
5:35:17 PM: Now encoding at 7547 k(=1000)Bits/s
5:35:17 PM: New target size = 4357119 Kb


Any ideas?

jggimi
19th October 2004, 01:42
Hello, and welcome to the forum.

Open the .avs script in VirtualDubMod, and see if it has 141746 frames (File....File Information), and then see if you can scroll all the way through the content to frame #141745.

If not, post your .avs script, we may be able to see something inside it. In addition, you may want to post the first several lines from the .d2v project file.

mmortal03
19th October 2004, 04:28
It showed 141746 in File Information, and I could scroll all the way through to 141745. Sorry that I don't have any more info to give you.
:(

d2v:

DGIndexProjectFile06
1
15 E:\bits0001.mpv

Stream_Type=0
iDCT_Algorithm=5 (1:MMX 2:SSEMMX 3:FPU 4:REF 5:SSE2MMX)
YUVRGB_Scale=1 (0:TVScale 1:PCScale)
Luminance_Filter=0,0 (Gamma, Offset)
Clipping=0,0,0,0 (ClipLeft, ClipRight, ClipTop, ClipBottom)
Aspect_Ratio=16:9
Picture_Size=1920x1088
Field_Operation=0 (0:None 1:ForcedFILM 2:RawFrames)
Frame_Rate=29970
Location=0,0,0,4FC78D

jggimi
19th October 2004, 12:30
Hmmm... I don't see anything obvious in the .d2v, and the fact that you got all the frames in VdubMod means that something must have happened to end the first pass early.

If you have failures but they occur in the same frame each time, then I don't suspect its your PC hardware. If in one instance is 65536 frames, and in another its 72125 frames, then I would indeed suspect your hardware.

Here are two more things you might try:

You might try "playing" through the frames in the 65536 area in VdubMod to see if VdubMod fails and then closes. If so, a corrupt VOB might be responsible.

If you're running an NT-based OS such as 2000 or XP, you might scan through your Event Log on the date you encoded near 5:35:17 -- the time VdubMod ended -- to see if there was an application or system problem reported.

Good luck!

mmortal03
23rd October 2004, 04:35
I have been able to reproduce the problem 3 or 4 times, so I doubt it is a hardware issue or an external application malfunctioning.

Sorry, it has been a few days, and thanks for your help so far. I can finally sit down and try out what you suggested, to play the source through VirtualDubMod at that point, and see what happens. I will post what I find in an half an hour or so.

mmortal03
23rd October 2004, 05:00
yeah, well, what do you know? the avs file crashes VirtualDubMod right around that point. The program literally just closes by itself, with no error message or anything, while in the middle of playing the source file back at that point.

I played back the mpv stream from the tp file, and it plays through that point in Media Player Classic, but you do see corruption at that point, just for a second or so. So, I then used HDTVtoMPEG2 to crop out the portion of video in question, and played it back in my HD tuner player, and there is a "skip" of sorts there in the broadcast, must have been an error in the signal at that point.

I guess I could use HDTVtoMPEG2 to cut out the error portion in question, and then try encoding THAT, but are there any other options?