Unable to re-use 1st pass if 2nd crashes

[tomos]

i encode over a network (not ideal but its done for space issues).

now its just my luck that something happens during the 2nd pass of an encode. i.e earlier today, i was 30 mins away from finishing the 2nd pass of an encode that took nearly 20hrs when the pc that had the source video on was reset accidentally.

i couldnt resume the encode afterwards from the 2nd pass. it instantly gave an err about corrupt files so i had to start from the 1st pass again.

what i dont get is why wasnt it able to resume considering that the stats file from the 1st pass is ok?

divx for some reason has no probs resuming the encode on the 2nd pass.

[ChronoCross]

you can't just "resume" an encode. the second pass would have to be restarted. AVC is way more complex than ASP so that is another feature.

[tomos]

oh no, i dont mean encode partway through the 2nd pass.

i mean i cant restart the 2nd pass without errors as if the info from the 1st is corrupted. i have to start the entire encode again.

i use vdub and when i check, pass 2 shows as aborted. when i try to restart this, it always fails.

i always thought that the reason for files like stats.1, stats.2 etc was that info from each pass is stored independantly of the other but it appears that the 1st stats file gets corrupted.

[ChronoCross]

IDK how the lame VFW interface works but it sounds as if it's "updating" the stats file. so when the second pass fails.....it corrupts the stats file.

[Sharktooth]

x264 VFW always update the stats file coz it doesnt run a 2nd pass but an Nth pass.
Use x264 CLI with a GUI if you want to run a 2nd pass without updating the stats.
However x264 is not supposed to crash...

[tomos]

ah ok, guess the xvid/divx ones dont update the log i guess. i just assumed that anything that it 'learned' for lack of a better term during the 2nd pass would go into stats.2 or whatever and leave the 1st alone

makes sense if it craps out halfway through updating the stats file.

oddly, it doesnt happen in every instance. i've done a few checks and if say:

i end task vdub during the 2nd pass, that seems to let me restart the encode again but if it loses access to the network drive during the encode, then it craps out and wont budge at all. absolutely refuses to restart the 2nd pass.

weird. thankfully, this prob doesnt happen that often. just been one of those days where *everything* went wrong.

ta for the info tho guys :)

oh, p.s, there's no option is there for the encoder to NOT update the 1st stats file and only create a 2nd is there? that would fix this prob for me then :)

[ChronoCross]

the real solution is to not to use vfw. I have a feeling that your problem might be related to virtualdub directly. It seems that since it doesn't occur in every instance the encoding fails except when transferring of the network.

[tomos]

not sure its a vdub issue, wouldnt it affect other codecs as well?

done this a few more times and it seems to be a weird networking thing. maybe some caching prob?

i've done this 5 times now and each time i disconnect the PC from the network during the 2nd pass, its corrupt and has to be restarted from stratch.

only once did i have to do this if i just end tasked vdub. the other 4 times gave an error and just carried on anyway.

ChronoCross, i have to use VFW tbh. its simply easier as other containers simply havent been around long enough for them to really be a replacement for avi, also that it doesnt really offer anything as an incentive to move over (well, apart from letting me fix my screwed up AR when i forget to set the right one in x264 before encoding. doh!)

example, i have a matroska vid containing mpeg2 vid and dts (and some other) audio. if i want to edit this, and remove some other audio tracks its a real pain.

hopefully it wont take years for tools to evolve tho, then people like me can migrate from avi too :)

anyways, dont want to turn this into another one of *those* threads. last time i read a vfw v other containers thread it gave me a headache and i think someone got banned! ;)

thanks for the advice tho chronocross

[foxyshadis]

you can't just "resume" an encode. the second pass would have to be restarted. AVC is way more complex than ASP so that is another feature.
Sure you can, as long as you use the same encoding mode (I found out to my chagrin that 2pass and crf do not mix) and command-line, though changing the bitrate and certain options is legal. Just use --seek to restart at the last IDR (or I, often). Cutting and rejoining the stream isn't the simplest thing (via mp4box or mkvmerge), but 5 minutes of effort beats 20 hours of re-encoding.

This won't help tomos, but maybe in the future it will.

[ChronoCross]

I thought seek had to be used independant of a sudden drop in encoding? cause it would be almost impossible to contnue an encode if it stopped suddenly unless you know where it stopped.

[foxyshadis]

Well, that's where h264_parse comes in handy, if coding to raw. Usually a cut-off mkv still plays and extracts fine, mp4 I have no idea. And you don't need to get it exactly right - cutting 2-5 megs back will definitely scrape at least a couple GOPs off the end, then you just find the # of frames left in the new main file and start there.

[GodofaGap]

oh, p.s, there's no option is there for the encoder to NOT update the 1st stats file and only create a 2nd is there? that would fix this prob for me then :)
Sure there is, it's right on the first screen when you open the VFW config window. A check box with "update statsfile"...

At least, this should be sufficient if you only want to do 2 passes. You can only specify 1 stats file name. (This is the same with the CLI BTW).

[gameplaya15143]

I've had x264 vfw do the same thing to me quite a few times. I never do more than 2 passes, so I have 'update stats' unchecked, but if it kills itself on the second pass, it does indeed corrupt the stats file. One possible solution (i'm not convinced it actually works yet, but seems to) is to make the stats file readonly after the first pass, then start the second pass. Then the second pass should be able to be run as many times as you want. It's too bad this doesn't really do much good when you use batch mode and sleep through the encoding process. :rolleyes:

[Sharktooth]

Why dont you try one of the GUIs for x264 CLI?
I even include MeGUI in my x264 builds...
same for bobor's builds (x264.nl)...