What does this .d2v parse tell me?

[fatcharlie]

Wow, that is noticeable!! So what did you use to encode those videos?

[poisondeathray]

I used xvid just for demonstration purposes, but you will get better results using x264

Since your end format goal is .mp4 files played on a network, I would use x264 as well

[fatcharlie]

So I started an encode yesterday morning on a 43 minute episode of Survivor.....still going 22 hours later. I think I may need to actually read the documentation and trade a little bit of speed for quality. I do have one other question. I'm going to end up cropping the video a bit, 8 pixels on the left, 4 on the right. Do I need to resize the video back to 720x480 after that? And if so, what resizer should I use, considering I'm using QTGMC to clean up the video?

[poisondeathray]

So I started an encode yesterday morning on a 43 minute episode of Survivor.....still going 22 hours later.

SD content? what are your system specs ? any other filters? 2-pass encode? What script? This seems slow unless you used crazy settings.

I do have one other question. I'm going to end up cropping the video a bit, 8 pixels on the left, 4 on the right. Do I need to resize the video back to 720x480 after that? And if so, what resizer should I use, considering I'm using QTGMC to clean up the video?

Only if you're going to NTSC DVD . If you're just playing .mp4 on a PC, then it doesn't matter, but it's best to stick with mod16 resolutions (evenly divisible by 16), and 2nd best mod8 . You can use any resizer. Some are sharper but can cause more ringing artifacts, some are softer. Lanzcos and Spline36 are fairly sharp, bicubic is more neutral, bilinear is more smooth. There are several other options, but you wont notice the difference on small resizes

Pay attention to aspect ratios. 720x480 isn't a square pixel resolution. If you had a 4:3 AR DVD for example, it would display as 640x480 (or something similar). You can set display aspect ratio into container or encode into stream. Do a search, aspect ratios are a frequently discussed topic. If you're still lost, then ask

[fatcharlie]

I am encoding to SD, as far as I know. My system specs, not really sure; it's a Compaq with an AMD processor, 64 bit Windows 7, nothing real top-notch, probably 2GB of RAM

Actually I didn't really change anything, I just used all the standard setting in MeGUI for .H264. I added the AVS script, set the encoder to .H264, loaded my audio file, set the encoder to Nero AAC, then hit the AutoEncode button. To be honest, within MeGUI, there isn't a whole lot I can do with .H264 as far as customizing.

Maybe it's the format of my script. I just used your example but added those lines to the end of my video line:

video=MPEG2Source(filename.d2v).AssumeTFF().QTGMC( preset="slow", border=true, sharpness=0.5).SelectEven()

Here is a pic of my .H264 configuration page within MeGUI (latest version, auto updated)

[poisondeathray]

Actually the question was with respect to SD was in regards to decoding. HD content is almost exponentially slower to deinterlace using QTGMC (maybe this was HDTV cap of survivor?) . If it's DVD rip, then it's SD

Those specs don't tell me anything. If you have an older single core CPU, then it might take that long. If you have a fairly recent quadcore you should be getting a lot faster

You can try using a faster preset for QTGMC, e.g. preset="faster" or "very fast". It will still be better than Tomsmocomp, but some shimmer may start to creep in. Note "very fast" is still glacially slow compared to tomsmocomp or yadif. Have a look at the documentation for more details. You'll have to decide where you want to make trade offs. You can use AvsPmod to preview single frames in different script versions in different tabs and swap with the number keys, although you may want to do some small test encodes, because motion is important to assess for deinterlacers

When doing 2pass encodes with heavy filters, many people use lossless intermediates (e.g. huffyuv, ut video codec). This way the slow filters are endured only once instead of twice. The overall time is can actually be faster

If you don't need a set file size, you can use CRF encoding (or quality based encoding). This is faster (1 pass) and it allocates the appropriate bitrate for the quality you set.

[fatcharlie]

It's only a single core CPU, so not really that fast compared to multiple core CPUs.

I have heard of those codecs, and I will try those. Thanks.

[fatcharlie]

So do I save as an avi in VDub using Huffyuv or UT Video, then use MeGUI to convert the avi to mp4?

[poisondeathray]

If you're doing a 2pass encode with megui then it might make sense to go that route. If you're doing CRF encode, it might not be beneficial

Then you could feed the avs script into vdub and encode to a lossless intermediate. Make sure you use "video=>fast recompress" in vdub (this will bypass RGB conversion, but in newer versions it might not be necessary, I would do it anyways)

[fatcharlie]

I guess the reason I asked that question is because I installed HUFFYUV, and when I opened up MeGUI I didn't see any way to tell it to use HUFFYUV. I'm assuming that when I tell MeGUI to encode to .H264 MeGUI is using something it installed on its own. Or am I wrong? I swear with each step I progress I feel more and more stupid.

[poisondeathray]

nope , you're correct

megui only has x264, xvid, and snow for encoding options

vdub can access any vfw codecs you have installed on your system (this includes lagarith, huffyuv, ut video codec etc..)

[fatcharlie]

Is it possible that if my lossless encoded .avi playback is choppy that when I convert it to .mp4 it will be smooth?

I tried to install huffyuv on my pc at home last night and it wouldn't install (Windows 7, 64-bit). I kept getting a message saying I couldn't copy to the destination folder. So after an hour of research and failed attempts with both 32-bit and 64-bit huffyuv, I decided to go with Lagarith. It took almost four hours to encode an 11 minute video, and the resulting avi, opened with MPC, would play for a few seconds then freeze for a second, then play for a few seconds, then freeze, etc. This morning I installed UT Video and I'm letting that encode while I'm at work. I'm expecting the same sort of playback, as that is my luck.

I may decide to try this whole process on my Windows XP laptop, just to see if I can get different or consistent results. But even that I really have no confidence with because here at work, on XP, I couldn't get QTGMC to install properly. VDub crashes at frame 0 with: Avisynth read error: CAVIStreamSynth: Unknown system exception - 0x000001e at 0x3a83e4a.

I really don't understand why I'm having more trouble than anyone else. I'm so frustrated I'm about ready to give up on ever being able to convert a DVD to .mp4. I do appreciate your help and patience poisondeathray, I really do. I would just feel a lot better if I could get the entire process to work on one PC. Right now only certain parts work on certain PCs. I suppose it all works on my PC at home, just the results are less than satisfying (the choppy video, encoded with Lagarith). Maybe I need to take a few days off from this.

[poisondeathray]

Is it possible that if my lossless encoded .avi playback is choppy that when I convert it to .mp4 it will be smooth?

yes it is, especially with older computer

lossless format aren't mean for real time playback; they are meant for archiving or transfers between programs. They have high data rates (you might run into HDD I/O bottlenecks) and compression/decompression requires additional CPU resources over uncompressed

I tried to install huffyuv on my pc at home last night and it wouldn't install (Windows 7, 64-bit). I kept getting a message saying I couldn't copy to the destination folder. So after an hour of research and failed attempts with both 32-bit and 64-bit huffyuv, I decided to go with Lagarith. It took almost four hours to encode an 11 minute video, and the resulting avi, opened with MPC, would play for a few seconds then freeze for a second, then play for a few seconds, then freeze, etc. This morning I installed UT Video and I'm letting that encode while I'm at work. I'm expecting the same sort of playback, as that is my luck.

Yes, you need 64-bit huffyuv if you're using 64-bit vdub and OS. UT video codec has 32-bit and 64-bit versions.

I may decide to try this whole process on my Windows XP laptop, just to see if I can get different or consistent results. But even that I really have no confidence with because here at work, on XP, I couldn't get QTGMC to install properly. VDub crashes at frame 0 with: Avisynth read error: CAVIStreamSynth: Unknown system exception - 0x000001e at 0x3a83e4a.

not sure about that error message. I would clean out the avisynth plugins folder, and put back in only specific dll's that you need or load them explicitly in the script

I really don't understand why I'm having more trouble than anyone else. I'm so frustrated I'm about ready to give up on ever being able to convert a DVD to .mp4. I do appreciate your help and patience poisondeathray, I really do. I would just feel a lot better if I could get the entire process to work on one PC. Right now only certain parts work on certain PCs. I suppose it all works on my PC at home, just the results are less than satisfying (the choppy video, encoded with Lagarith). Maybe I need to take a few days off from this.

Don't fret over the "choppy" video with lagarith during playback, it's normal. If you step through each frame, you should notice every frame is unique (no dropped or inserted frames).

MPEG2Source() should give you consistent results. Using a different non frame accurate source filter like DirectShowSource() with any temporal filtering like QTGMC will likely give you inconsistent results - I've seen this happen a lot.

[fatcharlie]

Thanks for the reply pdr. It was very reassuring.

About 64bit huffy, Everything I'm using is 32bit on my 64bit PC. I decided to go that way because DGIndex and MeGUI are only 32bit as far as I can tell. Should I be using 64bit everything if I can? I figured it best to stick to one bit-system.

For UT Video codec I used ULY2. Is there a recommended codec out of the four I should use?

[poisondeathray]

32-bit chain is more stable right now with avisynth. There are methods of piping 32bit input to x264_64 , and using avisynth 64, but they aren't as stable

you should be using UT 420 (ULY0) which is 4:2:0

[fatcharlie]

Any changes to the configuration of UT 420?

[poisondeathray]

Not if you have a single core

If you had an i7 with HT, you would enter 8 for the cores and frame divide count. If you had a dual core, you would enter 2, etc... I usually use "predict left" - faster encoding & decoding, but larger filesizes.

[fatcharlie]

Alright, cool. Thanks.

[Nelson37]

Charlie, fear not. As your learning progresses, you learn that there are more things to learn. Your willingness to continue the process is the most important part.

For instance, the problem you had with the laggy playback using Huffy is something I ran into many years ago, and I did not see, at that time, any info that this was normal. Caused me to abandon Huffy for quite some time as I assumed, as you did, that something was wrong.

There is ALWAYS another way. There is OFTEN a better way. There is ALMOST ALWAYS different opinions as to exactly which way is better. Learning the process and acquiring the tools will get you to the point where you can choose the best way for YOU.

In a couple years, you will be explaining this to some poor, confused newbie. Welcome to the club!

[fatcharlie]

Thanks Nelson. I do hope to keep and learning, and someday help out others. I think that day is a little ways off yet though, lol

[fatcharlie]

It worked!!!!! I encoded my lossless avi to .mp4 and muxed the audio file with it, checked it out this morning, and bam, smooth playback and no interlace lines. I can't thank you enoug for your halp and patience with me on this pdr, I really can't. Now, to see how well this works on my Survivor episodes.

[poisondeathray]

glad it worked out

Nelson's right - Having more options and choices is always better. I stayed away from video processing & avisynth stuff for a long time , it was just so intimidating. I used to use those garbage simple 1 click softwares . But once you see the incredibly better results you can get when you have control over the process - that pretty much convinced me to start learning about it

I'm still learning stuff everyday - there's just so much out there. It's a huge topic.

[fatcharlie]

New questions:

Is there any benefit to converting my audio file to another format? DGIndex saves it as an .ac3 file. So far I have been just leaving it alone.

Is there a preferred bit rate to encode the audio file to when remuxing in MeGUI? I know that my Tim and Eric audio files are 448Kbps, and my Survivor audio files are 192Kbps.

[poisondeathray]

Up to you. There are no guidelines for this sort of thing. Only you can decide what losses are acceptible (you know , the more available options thing). Of course keeping the original audio will give you original quality . Re-encoding it will cause some quality loss . I would venture to guess that you could re-encode Tim & Eric audio to lower bitrates using AAC and not notice much deterioration - I doubt the audio quality was that great (I'm only judging by the video quality)

[fatcharlie]

Thanks.