Interlaced h264

[mrwhitethc]

I'm looking for a good way to get all my wrestling DVD's stored on my server for easy access. The problem I face is that I have over 100 discs all with about 3 hours of content each. So something like TempGaussMC would just take forever. I've experimented with double frame rate and motion adaptive same frame rate and nothing looks as good as feeding my PS3 interlaced content. I tend to have problems with the ropes or the overlays/logos where edges will flicker or thin lines will become broken. I deleted a lot of test files during trial and error and now realize I should have probably kept them as samples so I've got 2 clips that hopefully will be a good base to go on. I would at least like to get maybe 3 or 4 done a day and I'm hoping to get around 50% compression if that's realistic. These are the 4 scripts I've found while looking for something that will enhance interlaced content and also return it so if anyone can help make these any better or let me know if something I'm doing wrong that would be a great help. I really just need a good general script since I'm not going to have the time to go through these one by one I did try more elaborate scripts on my own but always seemed to cause more problems that fixed.

Plain Settings

LoadPlugin("DGDecode.dll")
DGDecode_mpeg2source("Overlay.d2v")
SeparateFields()
crop(6,0,-6,0)
Spline64Resize(640,height)
Undot()
MSharpen(10,50)
Convolution3d (preset="movieLQ")
#SelectEvery(4,0,3)
Weave()


Bob Settings

LoadPlugin("DGDecode.dll")
DGDecode_mpeg2source("Overlay.d2v")
Bob(height=480).Crop(6,0,-6,0).Spline64Resize(640,height)
Undot()
MSharpen(10,50)
Convolution3d (preset="movieLQ")
AssumeTFF().SeparateFields().SelectEvery(4,0,3).Weave()


Scharfis Brain

function tmcbob(clip a)
{ ord = getparity(a) ? 1 : 0
f=a.tomsmocomp(-1,5,0)
e=a.doubleweave().selectodd().tomsmocomp(-1,5,0)
interleave(f,e).assumeframebased
}

LoadPlugin("DGDecode.dll")
DGDecode_mpeg2source("Overlay.d2v")

assumetff()
tmcbob()

i=converttoYV12()
mdata=i.DePanEstimate(zoommax=1,improve=false,pixaspect=1.094)
i.DePanInterleave(data=mdata,pixaspect=1.094)

#temporalsoften(1,10,13)
fluxsmoothT(7)
# or any other denoiser you like.
Crop(6,0,-6,0).Spline64Resize(640,Height)
selectevery(3,1)
undot()

#converttoyuy2()
separatefields().selectevery(4,1,2).weave()


tdeint eedi2

LoadPlugin("DGDecode.dll")
DGDecode_mpeg2source("Overlay.d2v")
edeintted = last.AssumeTFF().SeparateFields().EEDI2(field=-2)
TDeint(mode=1,order=1,edeint=edeintted)
Undot()
MSharpen(10,50)
Convolution3d (preset="movieLQ")
Crop(6,0,-6,0).Spline64Resize(640,height)
AssumeTFF().SeparateFields().SelectEvery(4,0,3).Weave()


tdeint nnedi2

LoadPlugin("DGDecode.dll")
DGDecode_mpeg2source("Overlay.d2v")
interp = nnedi2(field=-2)
TDeint(mode=1,order=1,edeint=interp)
Undot()
MSharpen(10,50)
Convolution3d (preset="movieLQ")
Crop(6,0,-6,0).Spline64Resize(640,height)
AssumeTFF().SeparateFields().SelectEvery(4,0,3).Weave()


Also here's what I feed x264:

program --profile high --level 3.1 --crf 19.5 --thread-input --deblock -1:-1 --interlaced --vbv-bufsize 14000 \
--vbv-maxrate 17500 --me umh --partitions all --nal-hrd --output "output" "input"


And here's 2 sample caps:

http://www.megaupload.com/?d=WKZ08QP6
http://www.megaupload.com/?d=4ZTBE8NZ

Any help or comments appreciated

[Guest]

The clip is handled nicely and very fast by DGDecNV with the PureVideo deinterlacer enabled.

[Blue_MiSfit]

Yes, if you want fast and good results, DGDecNV is a great choice.

Else, you can code interlaced with x264. Keep full resolution, and use CRF encoding plus VBV for PS3 compatibility.

50% compression improvement over your DVD sources is EASILY achievable with x264, even when using the defaults, or probably even --preset faster.

Derek

[onesloth]

Else, you can code interlaced with x264. Keep full resolution, and use CRF encoding plus VBV for PS3 compatibility.
Yeah. If you like the way the stuff looks when the PS3 does the deinterlacing, why not just keep it interlaced?

[mrwhitethc]

Unfortunately I don't have a nvidia GPU which is a requirement, I would assume I would encode the files non-interlaced single rate if I went this route?

So maybe I'm making this more complex than it needs to be? From the tests i've run on larger segments the using scharfis_brain script it comes the closest to the 50% compression at probably around 65% so would it be better to start tweaking the avs script or the settings i'm passing to x264? Blue_MiSfit said the defaults are good so maybe again I'm adding to many options to x264?

Thanks for your help guys.

[LoRd_MuldeR]

If you used a deinterlacer, you must NOT pass "--interlaced" to x264. This is only needed if you keep it interlaced.

Also, another deinterlacing option to test that isn't as slow as TGMC would be YadifMod+NNEDI2, like this:


function YadifModNNEDI2Bob(clip src, int quality)
{
interpol = src.nnedi2(field=-2, qual=quality)
return src.YadifMod(mode=1, edeint=interpol)
}

function YadifModNNEDI2Deint(clip src, int quality)
{
interpol = src.nnedi2(field=-1, qual=quality)
return src.YadifMod(mode=0, edeint=interpol)
}

[Guest]

Unfortunately I don't have a nvidia GPU which is a requirement You can get a card for < $50 and install it as a secondary adapter. I only persist with this suggestion because you say you have 100 disks to convert.

[mrwhitethc]

LoRd_MuldeR, so far keeping the content interlaced seems to leave less problems concerning the overlays, the ropes, etc. I did try single and double rate output with a deinterlacer but so far found that they end up leaving different artifacts. After testing my playback device, PS3, and finding it supports interlaced h264 and looks to not have as many problems that's why i've been filtering it some and then re-encoding it as interlaced. I did test the yadif nnedi but don't remember what problem I encountered. I'll give it another shot, I found some of my previous encodes on my thumb drive, I'm going to try and scan through them to see if I can pick out some of the issues I was having for test clips.

Neuron2, I should be able to get a hold of an nvidia card next week to try out. I don't mind waiting to check it out as I would rather just do this once anyway. Also the last full disk I tested took north of 5 hours so I'm not going to do the whole batch until I've tested more.

Appreciate the info/help again guys.

[LoRd_MuldeR]

LoRd_MuldeR, so far keeping the content interlaced seems to leave less problems concerning the overlays, the ropes, etc. I did try single and double rate output with a deinterlacer but so far found that they end up leaving different artifacts.

Be aware that if you keep it interlaced, the playback device or the TV screen will have to do the deinterlacing. So the playback experience may vary greatly between different devices/screens, depending on how good their individual deinterlacer is. I usually prefer doing a proper "bob" (double rate) deinterlacing before encoding, so I know how the result will look. Also with NNEDI2/3-based software deinterlacers (e.g. TGMC or Yadifmod+NNEDI2) I get significant better results than everything I have seen from (consumer) hardware deinterlacers, so far...

[mrwhitethc]

I tried out the Bob and it eats up to much space, it'll probably end up close to if not more than the source. I also tried the deinterlace and maybe it's just the Ropes scene but it doesn't look as fluid to me as the interlaced footage I tried. I'm going to try a different and slightly longer clip. It is however the smallest of all the scripts so far, understandably.

[onesloth]

I also tried the deinterlace and maybe it's just the Ropes scene but it doesn't look as fluid to me as the interlaced footage I tried. I'm going to try a different and slightly longer clip
Single-rate deinterlacing is never going to have motion as smooth as bobbing (whether done at encode or playback) because you throw away half the temporal resolution.

This resolution loss may be acceptable for films but for sports, like wrestling, you'll most likely notice the loss because of all the fast motion.

[pandy]

Seems that Yadiff was forgotten - also LoRd_MuldeR pointed one important thing - progressive display need to deinterlace interlaced content - results are highly dependent from deinterlacer.

Yadiff is quite nice compromise in therms speed/quality, use 480p60 (59.94...), should be sufficient - IMHO

[Didée]

The least effort surely is to just encode it interlaced. If you're satisfied with the deinterlacing capabilities of [either the PS3] or [your TV set], then everything is fine. No need to jump through loops.

Though, any "sub-optimalities" of bob/deinterlacing will become much more obvious when your source is SD *and* you're going to watch on a Full-HD TV set.


Regarding TGMC, let me note again that ...


... it is not necessarily "the world's slowest Deint'er". It can be set up to run quite fast, with still pretty good results. (On my shiny new i7-860, I can use it to bob-deinterlace PAL-720x576 in realtime.) (That's without any E.D.I., and SetMTmode(2, 4/or/6). )

Compare also this post (http://forum.doom9.org/showthread.php?p=1374368#post1374368), and ... be sure to check out the sample. ;)


... when used for encoding, also consider that TGMC's bob-deinterlacing is (much!) more compressible than what the usual other bob-deinterlacers are producing.

Look at the comparison I did post here (http://forum.doom9.org/showthread.php?p=1378244#post1378244). Yadif/Mod requiring 50% more bitrate (at the same fixed encoder compression) is not exactly peanuts.
(And when you look at the sample in the post I linked above, it should be quite obvious where that bitrate difference comes from...)

[mrwhitethc]

OneSloth - I know, I'm just trying all my options. I did a few straight Yadif single and double rate encodes in the beginning. They never did seem to look right for one reason or another. I did try out Tdeint+NNEDI2 so I figured I would give Yadif+NNEDI2 a shot as well.

Pandy - I don't know what it is, could just be my particular setup but Yadif never looks great to me. I've used it for a lot of throw away stuff like taking some TV Shows that were mixed film+video on the road with me but I was always just using a 10" screen or less. For those Yadif was great because I could queue up stuff a night before and have it ready to go in the am.

Didee - Yeah I'm watching it on a full-HD set so I think the "sub-optimalities" are the problem I'm having.

I'm testing TempGaussMC_Beta2 with (1,1,0,0,0,0,edimode="--",SVthin=0.0,pelsearch=1) and it's running along at a decent 6.9fps, defaults run at 1.2fps. I'm guessing if the output is to big I could always add a selecteven() at the end of it or maybe re-interlace it but that would probably destroy what it does to begin with right?

Also if you could Didee can you post the settings you use for realtime output, or is it the same as what I'm using?

[txporter]

Didee is probably using the parameters that you have posted. I have seen them floating around in a few threads. You can get maybe another 10% fps improvement by adding Smode=1,SLmode=1,Sbb=0 to your script.

[mrwhitethc]

Thanks txporter, I also should have a geforce 9400 board late this week or early next week to test out DGDecNV as well.

[Didée]

What I had used was exactly (1,1,1,EdiMode="--"). And a few threads, perhaps a few more, under Avisynth64. See here (http://forum.doom9.org/showthread.php?p=1403077#post1403077).

The "Realtime" term is just an eyecatcher. That can work for just viewing the script, also for "easy" compression like Huffyuv. But, if you're going to encode to x264 at the same time, the whole picture changes quite a bit, of course.

It's just that TGMC often is seen as "too slow to ever use it" .... which is quite an exaggeration. Sure, it's a slow script. But it's not that slow. With today's hardware, processing with TGMC is possible in reasonable time.

[mrwhitethc]

Gotcha, Didee, while I wait for the Geforce to come in I noticed you were using Avisynth64, since I'm running Windows 7 64bit I think I'll play around a see how that goes about giving me some speed improvements. And I do agree, while TGMC is slow it's not the slowest thing ever, it just needs to be tuned to what the person is after.

Looking at my filesize tests so far, I definitely wouldn't be able to keep it bobbed unfortunately. Only if I did output to Huffyuv and then compressed it with x264 at a 3000kbps avg which is going to eat up to much time for me. However looking at the selecteven() or keeping it interlaced I'm seeing a good 40% to 45% reduction in filesize which is good enough for me. Still going to continue testing some more however.

[mrwhitethc]

I got my Geforce 4800 motherboard today, while working on that I figured I would test how the PS3 deinterlaces, bob, drop frame, etc. I made a separate framecount on the even and odd frames in different locations and also a third framecount on the both even and odd frames in the same location. What I was able to see was residual and then solid numbers alternate on every other frame from each frame on the different locations and just solid framecount from the same location overlay. So if my reading and understanding is correct that means I am getting 60fps and it looks like the ps3 is also doing some interpolation as it resizes to 1080 @ 60hz. Unfortunately there's no way to output a UPNP stream to anything other than the max unless I delete all the other resolutions supported. That's not really worth it to me as the 1080 output of the interlaced stream looks great, even better than the original DVD in some areas especially the logo flicker I was getting.

[mrwhitethc]

I was able to install DGDecNV and run a quick test and here's the results. Didn't have a chance yet to actually compress the file to see filesizes unfortunately.

Ropes_Normal.avs

DGDecode_mpeg2source("ropes.demuxed.d2v")
SeparateFields()
Crop(6,0,-6,0)
Spline64Resize(640,height)
#SelectEvery(4,0,3)
Weave()


Ropes_Gauss.avs

DGDecode_mpeg2source("ropes.demuxed.d2v")
TempGaussMC_beta2(1,1,1,EdiMode="--")
Crop(6,0,-6,0).Spline64Resize(640,height)
AssumeTFF().SeparateFields().SelectEvery(4,0,3).Weave()


Ropes_NV.avs

LoadPlugin("C:\Program Files\MeGUI\tools\dgdecnv\DGDecodeNV.dll")
dgsource("ropes.demuxed.dgi", deinterlace=2)
Crop(6,0,-6,0).Spline64Resize(640,height)
AssumeTFF().SeparateFields().SelectEvery(4,0,3).Weave()


Ropes_Comp.avs

a=import("ropes_gauss.avs")
b=import("ropes_nv.avs")
p=import("ropes_normal.avs")

comp1 = compare(a,p)
comp2 = compare(b,p)

stackhorizontal(comp1,comp2)

Trim(9,0)


Here's the results from VirtualDub
http://i45.tinypic.com/1113ukk.jpg

[Guest]

What's your interpretation of the results?

How about simple screenshots of the results?

[Didée]

Re screenshot: those two frames are not field-sync. From the rather poor PSNR score of the Nvidia frame, it seems that this one is async. Something must've gone wrong.
Double-check for synchronicity before drawing any conclusions. "Subtract(clip1,clip2)" is a good friend to ask.

And when that off-by-one bug is fixed, then ... the PSNR doesn't tell anything. The bobbers create additional information that the source doesn't have to begin with. While the very-low PSN on the screenshot does indicate an error, it won't help any further when the error is fixed. If both PSNRs would be in similar range, then it could even be possible that the lower PSNR is the better result, and the higher PSNR is the worse.

When starting directly from an interlaced source, this test simply has no significance. The result means pretty much nothing.
To make such kind of a PSNR-comparison, you need to start with progressive input, construct an interlaced source from that, apply the contestants, then compare with the initial progressive source.

[mrwhitethc]

Thanks Didee, wasn't sure if compare would be good for pure interlaced, finally get it some what.

Yeah neuron2 I'll post some screenshots up once I get more time at that machine and give an update as to how it looks in motion.

[mrwhitethc]

Odd playing around with virtualdub last night to look for some frames to grab it looks like I have to trim the first frame of the Nvidia output to sync up to the other video frames. I scanned the output and didn't see to much of a difference between the Nvidia output and the TempGaussMC output. Hopefully when I get home today I'll have more time to find some shots that show good differences between them.

[onesloth]

There's no need to deinterlace -> horizontal resize -> reinterlace if the horizontal resize is the only processing you are doing and you want interlaced output. Your source is interlaced, right? For interlaced output this is all you need:
DGDecode_mpeg2source("ropes.demuxed.d2v")
Crop(6,0,-6,0)
Spline64Resize(640,height)
Or is the issue that your source is BFF and you want TFF?

If you want to compare the deinterlacing of TGMC and DGDecNV you need to remove the AssumeTFF().SeparateFields().SelectEvery(4,0,3).Weave() from the respective scripts.

[mrwhitethc]

Here's some screenshots:

http://img293.imageshack.us/img293/8098/ropes0113.png

http://img4.imageshack.us/img4/8040/ropes0218.png

http://img535.imageshack.us/img535/1713/ropes0818.png

The order of the pictures are Normal Bob, Nvidia and TempGaussMC_beat2(1,1,1,EdiMode="--")

First image has stair stepping and a rainbow on the ref's outfit on the bob and the Nvidia, got some weird pixelation on the camera flash on the Nvidia in the 2nd image and the 3rd image the ropes in the middle merge except in TempGaussMC.

After reencoding these into h264 interlaced what I noticed on playback was the ropes sometimes had pits? Like it was missing a pixel here and there. Also the WWF logo shimmers sometimes and other times it's fine. TempGaussMC cleans up the best, leaving the smallest filesize and the best image, Nvidia cleans up some but it seems to remain faithful to the source more which means more problems. The original MPEG2 file has it's own share of problems, it doesn't have the pits in the ropes but it does have the rainbows, shimmering logo & dot crawl.

[mrwhitethc]

OneSloth, when encoding I am keeping it interlaced. I tried your suggestion and it does help when not filtering the output to keep it true to the source. Thanks.

[onesloth]

After reencoding these into h264 interlaced...
Since each of those tests are of deinterlacers, you shouldn't be encoding them with the interlaced mode of your h.264 encoder.

I'm only mentioning it because you might not be getting the right output and thus not making a fair comparison.

[mrwhitethc]

onesloth,

The problem is I would like to keep the size of the reencoded video down as right now almost every dvd is full at 7gb+. While I'm recompressing them to h264, I figured I might as well filter them to clean the video some. The problem then comes that in single-rate mode nothing looks smooth, in double-rate mode the filesize approaches that and sometimes exceeds the original. Both also start to introduce new problems like the missing pixels on the edges of the ropes. Yadif helps the ropes and the logo problem but then kills the little amount of details that are actually there making everything even more flat and plastic like.

The only solution I've found is to re-interlace the files, and since I've already verified that it is then deinterlaced on playback at 60fps I'm ok with that. Even re-interlaced you can tell a difference with the TempGaussMC filtered files, it keeps the logo from shimmering too bad, which is in the original DVD, it also prevents the pits on the ropes from happening and mostly eliminates some dot crawl I found. I've tried using other filters but it always seems to add problems somewhere else, weird interlacing artifacts, more shimmering, etc

These aren't the best sources, admittedly these DVD's should have been split into 2 8gb discs because there's just so much going on in each frame from camera shake to smoke, lots of camera flashes, fast motion, etc Considering it was all captured with video cameras instead of film makes it even worse. It may sound crazy but the fact is the only way to get it to look like the original and not cause problems is to do it this way. Maybe it's something in the h264 settings that I posted that i'm doing wrong but I can't keep the file size down and not cause problems by going any other way except TempGaussMC.

[onesloth]

My guess would be that most of the improvement you're seeing from TGMC is due to it's denoising. Certainly its your time to spend as you please, but it really seems like a waste to run TGMC, only to throw away most of the processing it does, in order to get TGMC's side effect benefits. A lot of filtering can be done without deinterlacing. For example, for MC'd denoising you can process the top and bottom fields as separate clips.

[mrwhitethc]

I would be happy to try that, do you have a script example? I'm transferring over all the DVD's first so I have time to try other options no problem. I had thought there was at one point someone asking for the cleanup part of TempGaussMC to be separated from the rest but never saw where that went. I'm guessing all the cleanup it does is what's making the footage that much better.

[onesloth]

Get fastdegrain, the use this script. If your source is TFF, change the assumeBFF() to assumeTFF(). I've used something like this before but I can't recall if there are any other points where an assume[B/T]FF() or assume[frame/field]based() is needed so let me know if it plays correctly.

DGDecode_mpeg2source("ropes.demuxed.d2v")
assumeBFF().separatefields()
src=last
field1=src.selecteven().fastdegrain()
field2=src.selectodd().fastdegrain()
interleave(field1,field2).weave()
Crop(6,0,-6,0)
Spline64Resize(640,height)

[Gavino]

If your source is TFF, change the assumeBFF() to assumeTFF().
Actually, assumeBFF (or assumeTFF) is unnecessary here, since there is nothing in the script that depends on the actual field order.

Since the interleave puts the fields back in the same order they were separated, it will work either way.

[2Bdecided]

mrwhitethc,

x264 will give you any bitrate or quality you want - just use the appropriate settings. There are plenty of presets you can try through MeGUI, for example. If double-rate deinterlacing makes the bitrate too high, then there are other ways of getting it down rather than re-interlacing. Just use different settings. It will lower the quality, but probably not in a visible way (I don't know what bitrate you're aiming for). x264 handles progressive video really well. (sorry if this is all already obvious to you).


It sounds like the gentle temporal smoothing of TGMC is improving your source. That's quite a difficult thing to do exactly as well as TGMC does it because it take account of both fields properly - though by the time you've re-interlaced, the benefit is subtle. Other filters shouldn't be giving you "problems somewhere else, weird interlacing artifacts, more shimmering, etc" - the disadvantage, if any, should be subtle.


YMMV, but I'd use TGMC for generating 60fps progressive and encode progressive, or use specific filters to kill dot crawl and shimmering and encode interlaced.

Cheers,
David.

[mrwhitethc]

hey 2bdecided,

These are the h264 settings i'm using:

program --profile high --level 3.1 --crf 19.5 --thread-input --deblock -1:-1 --interlaced --vbv-bufsize 14000 --vbv-maxrate 17500 --me umh --partitions all --nal-hrd --output "output" "input"

I know I can remove the --interlaced and the --nal-hrd if I'm doing progressive encodes. I would like to keep the bitrate somewhere around 3000-4000 since that will keep the filesize about half of what it is now.

Where the problems come in, and unfortunately i have tried a lot of different methods before asking, I probably should not have deleted the scripts and output to show where these were happening. I know right now the shimmering is in the original video already, where the WWF logo will bounce back and forth, it also has a bit of rainbowing in it along with the refs shirt. TGMC seems to kill it the most out of all the filters, this one isn't caused by the filters so much as it's left in.

When I tried to remove the dotcrawl on the logos, I did try checkmate and maybe one or 2 others, but there would be problems with the signs in the crowd showing interlaced artifcats, long black thin streaks. And I know I tried double-rate output with Tdeint and that caused the missing pixels on the edges of the ropes, yadif+nnedi2 was just as slow as TGMC it didn't fix as much as it did, however yadif is up there with TGMC at fixing the shimmering logo.

With so many DVD's to encode I really just need a basic script I can run to not cause more problems in the end. I think some of this stuff is the once you see it you can't unsee it stuff where maybe it was there when I tried other filters but didn't see it then. Also I do have time right now as I'm transferring all the DVD's to the hard drive first so I'm willing to try different approaches.

I do appreciate everyones input, I know this is suppose to be one of the toughest things to encode.

[2Bdecided]

I can't even begin to unpick your other settings (I cheat and use presets!), but if you want a lower bitrate, increase the crf value a little, e.g. 23 is the default. Sorry if this is stating the bleeding obvious.

Have you seen...
http://www.aquilinestudios.org/avsfilters/dotcrawl.html
...especially "Setting tthr2=0 generally prevents artifacting".

For progressive output, IMO, TGMC is a great choice (I wouldn't use anything else, if the time is available), and things like TDeint are quite obviously less good on challenging content. Plain double-rate Yadif did better than I expected with your scenes, and is fast. Some faults are far less noticable when watching in real time.

Cheers,
David.

[mrwhitethc]

2BDecided, you're right yadif is fast and it does fix issues like the simmering logo and the pits in the edges of the ropes it just kills to many details for me, there's so few to begin with it just makes it worse. I'll see if I can find the one segment I found doing some double-rate tests. It was during an interview, there was almost no detail left in anyones face, I think it was the combination of the bright lights, hot spots and oil they used back in the 80's.

[onesloth]

Actually, assumeBFF (or assumeTFF) is unnecessary here, since there is nothing in the script that depends on the actual field order.
Does AviSynth need to signal field order to the calling app?

[Gavino]

Does AviSynth need to signal field order to the calling app?
Not normally.
After all, there is no way to signal whether the clip is interlaced or not, so this information (if needed) must be given to the calling app by the user.

[mrwhitethc]

Haven't posted in awhile but I have been doing some tests and maybe I will keep it 60fps instead of deinterlacing. Reading more and more I finally took the plunge into 64bit Avisynth territory and WOW! Even on my lowly E6750 dual core I have new faith in TempGaussMC. Thanks to Didee for all those posts on what/how he did stuff. I can now run this avs script:


LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\DGDecode.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\MT.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\mt_masktools-26-x64.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\mvtools2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\RemoveGrain.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\Repair.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\VerticalCleaner.dll")
SetMTMode()
DGDecode_mpeg2source("overlay.d2v")
TempGaussMC_beta2(1,1,1,EdiMode="--")
Crop(6,0,-6,0)
Spline36Resize(640,height)


I drop it on this bat file I made:


"x264-64.exe" --level 3.1 --pass 1 --bitrate 3000 --stats "%1.stats" --deblock -1:-1 --b-pyramid none --vbv-bufsize 14000 --vbv-maxrate 14000 --me umh --partitions all --sar 10:11 --output NUL "%1"
"x264-64.exe" --level 3.1 --pass 2 --bitrate 3000 --stats "%1.stats" --deblock -1:-1 --b-pyramid none --vbv-bufsize 14000 --vbv-maxrate 14000 --me umh --partitions all --sar 10:11 --output "%1.264" "%1"


and I get this for speed:


Pass 1
x264-64.exe" --level 3.1 --pass 1 --bitrate 3000 --stats "64bit_overlay.avs.stats" --deblock -1:-1 --b-pyramid none
--vbv-bufsize 14000 --vbv-maxrate 14000 --me umh --partitions all --sar 10:11 --output NUL "64bit_overlay.avs"
avs [info]: 640x480p 10:11 @ 60000/1001 fps (cfr)
x264 [info]: using SAR=10/11
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile Main, level 3.1

encoded 4110 frames, 15.75 fps, 2948.75 kb/s

Pass 2
x264-64.exe" --level 3.1 --pass 2 --bitrate 3000 --stats "64bit_overlay.avs.stats" --deblock -1:-1 --b-pyramid none
--vbv-bufsize 14000 --vbv-maxrate 14000 --me umh --partitions all --sar 10:11 --output "64bit_overlay.avs.264"
"64bit_overlay.avs"
avs [info]: 640x480p 10:11 @ 60000/1001 fps (cfr)
x264 [info]: using SAR=10/11
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 3.1

encoded 4110 frames, 11.02 fps, 2971.24 kb/s


Considering the 32bit version was going somewhere in the neighborhood for 2fps when doing a 1pass -crf 20 encode, I can now do a 2 pass encode and hit the bitrate I need to keep these files down to size and still have decent speed. Hopefully these's nothing wrong in my scripts/code, I'm going to let it run a full disc today and see the results. Thanks again to everyone and btw TempGaussMC isn't as slow as everyone thinks people! =)

[mrwhitethc]

Woke up to find it was stuck on the first pass at 12.5% complete in x264, process was still humming along on 1 core at 100% usage. Hrm, guess I'll be reading up the Avisynth64 thread for a bit see if I can track something down.

[txporter]

Woke up to find it was stuck on the first pass at 12.5% complete in x264, process was still humming along on 1 core at 100% usage. Hrm, guess I'll be reading up the Avisynth64 thread for a bit see if I can track something down.

I would just remove your setmtmode() line. The default is 2. Neither mpeg2source nor tgmc run well with multi-threading. You probably don'd need multi-threading for cropping or resizing. Running either mpeg2source or tgmc at setmtmode(2) is likely what caused the lockup.