fighting it out with MeGUI and HD DVD

[saint-francis]

I have been trying to encode a HD DVD with MeGUI and x264 and every time x264 crashes. I can load my .evo into the avisynth script creator (albeit very slowly) by following this (http://forum.doom9.org/showthread.php?p=1035422#post1035422) guide. It takes a veritable eon to load into the avisynth script creator. Likewise it takes it's sweet time when I hit enqueue. I have encoded HDTV caps with MeGUI and I don't encounter such a lag. Bu the source in those situations wasn't VC-1 so who knows if the lag I'm experiencing is abnormal. Also when running the encode my system tray will display many instances of Haali media splitter. Some times as many as 8 instances. I have ripped the disk multiple times and remade the graph all to no avail. I was overclocking fairly seriously so I went back to the default clock to no avail. Even though I had encoded for days on end with the previous overclock. I even reinstalled the OS (which is XP for the record). I am simply modifying the HQ Insane profile to be crf 18. After a certain amount of time x264 crashes with only one exception. Once I tried to encode the movie without adding the number of frames I obtained from EVOdemux and it encoded all the way through but the resulting file was ridiculously jumpy. It would skip back and forth between frames frequently. I have now tried to encode the same file seven, yes 7, times without success.

Here's a copy of one of the MeGUI logs. (thanks Berriman for adding the x264 command line back into the log)

Looking for job processor for job...

Processor found!



------------------------------------------------------


Starting job job1 at 12:02:42 PM

Starting preprocessing of job...

Preprocessing finished!

successfully started encoding

Processing ended at 7:22:30 PM

----------------------

Log for job job1

Job commandline: "C:\Program Files\megui\tools\x264\x264.exe" --crf 18.0 --keyint 240 --min-keyint 24 --ref 16 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-1 --subme 7 --trellis 2 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-maxrate 25000 --me umh --threads auto --thread-input --sar 1:1 --progress --no-dct-decimate --no-psnr --no-ssim --output "D:\FullDisc\DVD_VOLUME\HVDVD_TS\12 Monkeys.mp4" "D:\FullDisc\DVD_VOLUME\HVDVD_TS\12 Monkeys.avs"
avis [info]: 1280x688 @ 23.98 fps (186534 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSSE3
x264 [warning]: VBV maxrate specified, but no bufsize.
mp4 [info]: initial delay 250 (scale 2997)

----------------------

End of log for job1
-------------------------------------------------------




Here's a copy of an AVISynth script I have used.

setMTmode (2,0)
DirectShowSource("D:\FullDisc\DVD_VOLUME\HVDVD_TS\12 monkeys.GRF",framecount=186534, audio=false)
AssumeFPS(23.976)
crop( 4, 20, -2, -22)

LanczosResize(1280,688) # Lanczos (Sharp)
Undot() # Minimal Noise

I know many people are able to encode HD DVD material so any input would be much appreciated.

[check]

what happens when you encode the file directly with x264?

[saint-francis]

what happens when you encode the file directly with x264?

You mean from the command prompt? Same thing. But I'm getting the commands for x264 from MeGUI so it's still involved there. I'm not x264 savvy enough to intelligently make my own scripts.

[foxyshadis]

Another test then, what happens if you encode to xvid instead? Same crash would mean it's in the VC-1 decoding, not x264.

[saint-francis]

Another test then, what happens if you encode to xvid instead? Same crash would mean it's in the VC-1 decoding, not x264.

I'll get right on it and report in the morning.

Thanks.

[saint-francis]

The encoding with xvid worked in as much as it completed both jobs of the two passes. It failed in that the resulting video was completely unwatchable. It seemed to be playing frames from different scenes at the same time. It was also 50% larger than I had specified it to be. And when it was encoding my PC went completely haywire. Nothing else worked properly. I couldn't even really browse the internet as my browser wouldn't load pages.

[check]

Was the latter issue because you didn't set the process priority to IDLE?

[saint-francis]

Was the latter issue because you didn't set the process priority to IDLE?

You mean how my pc was acting strangely? Xvid was not using 100% of my processor the entire time. But my version of MeGUI doesn't have and IDLE option. Only HIGH, LOW and NORMAL.

[Adub]

Low is pretty much idle.

[saint-francis]

I had it set to NORMAL (as usual). I have encoded video for 20 hours with it set this way with x264 at 99% CPU usage at least a dozen times and never had these problems. I only used the PC for about 10 - 20 minutes before going to bed at any rate. So I don't think that my using the PC while encoding created the barbecued encode.

[check]

No, it didn't. Simply pointing out that if you set the priority to Lowest, Windows will only allocate x264 unused processor cycles, which will mean your system will remain as responsive as ever.

[saint-francis]

OK. So is the general consensus now that my issue is with decoding and not with either MeGUI or x264? Should this thread be moved to the decrypting or container forum?

[check]

The issue sounds to be the input script. What happens if you open the avs in a media player?

[saint-francis]

It was MT!
The script plays just fine without it. With it the movie is all choppy. That also explains why I had scores of instances of Haali media splitter running. I removed MT from the script and am trying it again. There is only one instance of Haali media splitter in the system tray now. rofl
I guess I have to be a little more choosy about how I use MT in the future.

Thanks check and foxyshadis.

:thanks: