x264 Multipass... works? [Archive]

View Full Version : x264 Multipass... works?

Ditto666

4th November 2010, 01:42

I've used two versions of the x264 codecand in neither could I get multipass to work (currently using the x264vfw 7.29.09 build). I mainly encode from DVD sources and use DGIndex and AVISynth. For either of the Multipass 1st pass options, it goes through it once, finishes, and I'm just left with a tiny file with all the video info but no actual video stream. For "Nth pass", it simply always just gives an error message. I was never sure how much greater the quality is with multipass but I always wanted to try it, maybe to compare or whatever. Might anyone know the problem? It works with other h264 codecs in like programs and stuff so why doesn't x264 let me? Might it be a problem on my end - somethinbg I'm doing? Thanks guys :)

PhrostByte

4th November 2010, 03:45

What error does it give? Have you tried using the command line program instead of vfw?

Blue_MiSfit

4th November 2010, 05:38

1) Your build is ancient, but it should still work

2) I'd suggest trying CLI, or a GUI that uses CLI (like Ripbot264, StaxRip, or MeGUI).

2 pass mode does definitely work perfectly fine, lots of people use it every day. If it didn't work, everyone would be screaming :)

Derek

Ditto666

4th November 2010, 10:19

What error does it give? Have you tried using the command line program instead of vfw?

I wouldn't know how, probably because I use it through VirtualDubMod. I remember though the command line version I had a while back just blinked and then closed. Maybe that was the wrong thing but just to throw it out there...

The error it gives is:
x264vfw [error]: ratecontrol_init: can't open stats file

1) Your build is ancient, but it should still work

2) I'd suggest trying CLI, or a GUI that uses CLI (like Ripbot264, StaxRip, or MeGUI).

2 pass mode does definitely work perfectly fine, lots of people use it every day. If it didn't work, everyone would be screaming :)

Derek

Lol, yeah, I would assume that it would cause a fuss and that's really what was confusing me. I wasn't doing anything complicated or different so I dunno... I select and use the codec through VirtualDubMod. Could it be the problem? I just thought once the process starts, it's really the codec that's in control and VirtualDubMod is just what puts all the data together, in simple terms...

PS- I had trouble finding a version of the x264 codec which I can install and use in VirtualDubMod (or just in general) and what I have now is what I found really... What's the latest that I can do such with? Thanks again :)

AlekseiV

4th November 2010, 10:31

Ditto666

4th November 2010, 11:31

http://komisar.gin.by/
http://sourceforge.net/projects/x264vfw/files/
Both provide the latest version of x264 as a VFW codec. VFW is a bad idea for x264, though. Encode to lossless (Lagarith, Ut Video, etc.) then encode with x264 using something like MeGUI.

Also, why are you using VirtualDubMod? It hasn't been updated in years.

I like it :) Works 100% fine.
What's the difference though? How would using MeGUI produce a better result? If it's just to use the codec, if all the settings, bitrate and all, are fully the same, it's h264 either way. It's not that I don't trust you; I'm just curious and I like to know what's going on, otherwise, it's just blindly following someone else without any control of what you want.

Sharktooth

4th November 2010, 16:44

:search:

qyot27

4th November 2010, 17:19

I like it :) Works 100% fine.
What's the difference though? How would using MeGUI produce a better result? If it's just to use the codec, if all the settings, bitrate and all, are fully the same, it's h264 either way. It's not that I don't trust you; I'm just curious and I like to know what's going on, otherwise, it's just blindly following someone else without any control of what you want.
VirtualDub (and its derivatives, like VDubMod) encode using the Video for Windows framework, often shortened to VfW. When it comes to compression formats like MPEG-4 ASP (Xvid) or H.264, VfW is inadequate because it fundamentally lacks support for certain features, like B-frames (B-frames in AVI is a hack; it wasn't as noticeable for Xvid because you were limited to 2 or 3 at the most, but IIRC DivX compatibility sets the maximum limit at 1; H.264 supports up to 16, and b-pyramid, which will and does cause problems for it if you crank it up that high). VfW is synonymous with the AVI container, if you use it with those formats, the formats are intrinsically broken to whatever degree you use features it doesn't like - and disabling those features to let AVI not freak out on you cripples your ability to fully make use of the format's capabilities. And in VDubMod's case, its MKV output uses Matroska's VfW mode, so that doesn't solve the problem either.

That's why using it is a bad idea. The actual x264 executable outputs to containers which store its features correctly, like MP4, MKV (in native mode, which properly supports things like B-frames), etc.

And the CLI version is not meant to be opened by a double-click, which is why it blinked and disappeared. You have to open the Command Prompt* and execute commands through there for it to work (or use a batch script, which can be run with a double-click - you still need to know what the commands you want to use are before-hand, though). But if you're not comfortable with command-line work, then the better option is to use a GUI program that simply acts as a frontend for the CLI and doesn't touch VfW at all. The others have already suggested some.

*on Vista/Win7, you can do this by holding down Shift while right-clicking in the whitespace of the directory you're in and choosing 'Open Command Window Here'. On XP that functionality has to be added by an MS Powertoy or third-party shell extension. On any of those systems the more traditional approach of Start->Run->cmd, and then using 'cd' to make your way to the right folder is supported too.

Ditto666

5th November 2010, 00:39

:search:
Wow...
VirtualDub (and its derivatives, like VDubMod) encode using the Video for Windows framework, often shortened to VfW. When it comes to compression formats like MPEG-4 ASP (Xvid) or H.264, VfW is inadequate because it fundamentally lacks support for certain features, like B-frames (B-frames in AVI is a hack; it wasn't as noticeable for Xvid because you were limited to 2 or 3 at the most, but IIRC DivX compatibility sets the maximum limit at 1; H.264 supports up to 16, and b-pyramid, which will and does cause problems for it if you crank it up that high). VfW is synonymous with the AVI container, if you use it with those formats, the formats are intrinsically broken to whatever degree you use features it doesn't like - and disabling those features to let AVI not freak out on you cripples your ability to fully make use of the format's capabilities. And in VDubMod's case, its MKV output uses Matroska's VfW mode, so that doesn't solve the problem either.

That's why using it is a bad idea. The actual x264 executable outputs to containers which store its features correctly, like MP4, MKV (in native mode, which properly supports things like B-frames), etc.

And the CLI version is not meant to be opened by a double-click, which is why it blinked and disappeared. You have to open the Command Prompt* and execute commands through there for it to work (or use a batch script, which can be run with a double-click - you still need to know what the commands you want to use are before-hand, though). But if you're not comfortable with command-line work, then the better option is to use a GUI program that simply acts as a frontend for the CLI and doesn't touch VfW at all. The others have already suggested some.

*on Vista/Win7, you can do this by holding down Shift while right-clicking in the whitespace of the directory you're in and choosing 'Open Command Window Here'. On XP that functionality has to be added by an MS Powertoy or third-party shell extension. On any of those systems the more traditional approach of Start->Run->cmd, and then using 'cd' to make your way to the right folder is supported too.
Thanks very much for all the info. Learned some things :)

A few things in follow-up though: I thought every format already had a predetermined way of dealing with frames, as the nature of it. I guess not.

MeGUI comes up here every time I'm on this forum - almost every thread I make. It often turns into a heated assault of how anyone that doesn't see it's the best thing ever is dumb; a person doesn't have to do things exactly like another to receive help on a specific issue, nevermind the issue being unrelated, making it not the business of the particular other. I personally tried MeGUI once - didn't like it. It might be time to give it another shot though, I'll admit...

From VirtualDubMod, I save the h264 stream in an AVI container and afterward, I mux everything together, that with the encoded/demuxed audio (which usually gets stripped from when I pass the VOB through DGIndex) and subtitles when they exist/necessary, using MKVMerge. I never knew exactly what was going on fully in this process but whatever was wrong, like the few things you were describing, I always thought MKVMerge fixed those issues as it focuses on the roots of whatever is added. I'm probably wrong though.

Essentially, this is my full process currently:
DVD->DVD Decrypter/DVDFab->DGIndex (Whichever portion(s) I need)
AVISynth (MPEG2Source->.d2v->Plugins->script)->VirtualDubMod (from which I sometimes visually or numerically, time or frame number, choose the portions I need to encode; from which I also sometimes use to visually determine the amount of pixels I need to crop instead of trial and error from the result)->x264 codec (Single pass only, where the issue is and always was)
MKVMerge (.AVI, audio stream(s), subtitle(s))

If I can keep this same process, only replacing VirtualDubMod and MKVMerge if it becomes obsolete, I'd be MORE THAN happy to switch, as long as I can use all the functions I do in VirtualDubMod. MKVMerge has some marking and tagging functionality I need as well.

Any suggestions? Lol. A direct fix for this multipass issue would also make me very happy unless even with my full process described, the problems using VirtualDubMod still apply.

Thanks to anyone that spent the time even reading through this! I really do appreciate any responses. It's just as long as they're not along the lines of, "Screw the way you do things; just conform to everyone else" or, "Search the internet instead of asking for help on a forum on a matter that requires understanding and opinion from the other end."

Blue_MiSfit

5th November 2010, 03:25

qyot27

5th November 2010, 03:33

A few things in follow-up though: I thought every format already had a predetermined way of dealing with frames, as the nature of it. I guess not.
They do, but those specifications also usually assume the usage of a particular container, or at least expect the container to respect the schemata of the format. H.264 nor MPEG-4 ASP/Xvid were ever meant to be stored in AVI, as AVI hasn't changed much since around 1992, I think (save a couple updates over maximum size and some header-related stuff, but not anything frame-relevant). Both MPEG-4 ASP and H.264 are newer than that by several years, and contain advancements that AVI was never intended to support. It's like trying to use a Laserdisc on a turntable.

Going strictly by the MPEG-4 specifications, those formats are supposed to be stored in MP4. Matroska is properly compatible with them too, as long as you use native mode (the default for H.264; available as an override for Xvid), and MPEG-2 TS is used for H.264 in various areas as well, such as Blu-ray.

From VirtualDubMod, I save the h264 stream in an AVI container and afterward, I mux everything together, that with the encoded/demuxed audio (which usually gets stripped from when I pass the VOB through DGIndex) and subtitles when they exist/necessary, using MKVMerge. I never knew exactly what was going on fully in this process but whatever was wrong, like the few things you were describing, I always thought MKVMerge fixed those issues as it focuses on the roots of whatever is added. I'm probably wrong though.
I've lost track, to be honest, but I remember that MKVMerge did have something of an ability to 'correct' such streams, as far as H.264 was concerned. For Xvid you've got to go in and explicitly tell it to use native mode if you want it stored the way it should be, spec-wise.

If I can keep this same process, only replacing VirtualDubMod and MKVMerge if it becomes obsolete, I'd be MORE THAN happy to switch, as long as I can use all the functions I do in VirtualDubMod. MKVMerge has some marking and tagging functionality I need as well.

Any suggestions? Lol. A direct fix for this multipass issue would also make me very happy unless even with my full process described, the problems using VirtualDubMod still apply.
From what you described of the process, it depends on how much you cut out of those videos. During the VDub phase, you can jot down the frame #s you need in a regular text file and then use AviSynth's Trim() command to output the right segments straight from AviSynth. If you usually stitch the pieces back together afterward then there are more advanced ways to call Trim so that you get just the parts you want and throw out the rest, right in the script. Then you can pass that to the whichever x264 frontend is being used, and finally pass the result to MKVMerge like normal.

Ditto666

5th November 2010, 08:05

The only sore spot in your workflow is that you're using x264 through vfw (virtualdub), which can be a pain in the butt. Here's what I suggest to modernize things:

1) Use AvsP to write your script and preview it. Hint: Open an AVS file with this tool, and push F5 :). You can use AvsP to adjust trim points like you would with VirtualDub. Seek to the start and push the Home key. Then seek to the end and push the End key. It will add the necessary trim statement to your script

2) A nice GUI is Lord_Mulder's x264 gui. You feed it an AVS file, and it has a very well designed interface for configuring x264's settings. It can also perform automatic 2 pass encoding.

I'd suggest outputting the video stream to an MP4 file and then combining this with your audio stream(s) in MKVMergeGUI as you currently do, producing a final MKV.

Please excuse anyone you feel has dismissed you. These questions have been answered many times, but they're always phrased differently, making searching for those who aren't "in the know" very difficult, I agree!!

Derek
BEAUTIFUL! Thank you!

Seriously, that sounds amazing. It seems absolutely perfect for me.

I pretty much always encode with x264 so that's not an issue I think, but how flexible is it in regards with the input? As long as it works with AVISynth it should be good? Not to discredit others, but you're one of the few people that gave a response without any hint of superiority or being snarky... I'm not sure why it's so often like that here and really, that's not based off only a few times. But anyway, sorry to have even mentioned that, not important, lol.
They do, but those specifications also usually assume the usage of a particular container, or at least expect the container to respect the schemata of the format. H.264 nor MPEG-4 ASP/Xvid were ever meant to be stored in AVI, as AVI hasn't changed much since around 1992, I think (save a couple updates over maximum size and some header-related stuff, but not anything frame-relevant). Both MPEG-4 ASP and H.264 are newer than that by several years, and contain advancements that AVI was never intended to support. It's like trying to use a Laserdisc on a turntable.

Going strictly by the MPEG-4 specifications, those formats are supposed to be stored in MP4. Matroska is properly compatible with them too, as long as you use native mode (the default for H.264; available as an override for Xvid), and MPEG-2 TS is used for H.264 in various areas as well, such as Blu-ray.

I've lost track, to be honest, but I remember that MKVMerge did have something of an ability to 'correct' such streams, as far as H.264 was concerned. For Xvid you've got to go in and explicitly tell it to use native mode if you want it stored the way it should be, spec-wise.

From what you described of the process, it depends on how much you cut out of those videos. During the VDub phase, you can jot down the frame #s you need in a regular text file and then use AviSynth's Trim() command to output the right segments straight from AviSynth. If you usually stitch the pieces back together afterward then there are more advanced ways to call Trim so that you get just the parts you want and throw out the rest, right in the script. Then you can pass that to the whichever x264 frontend is being used, and finally pass the result to MKVMerge like normal.
With VDubMod, I normally don't do anything for the end result and encode the whole thing. Selecting the piece I need is normally just for quick testing purposes. Sorry I didn't make that clear.

Thanks; informative as usual :)

kemuri-_9

5th November 2010, 13:39

I pretty much always encode with x264 so that's not an issue I think, but how flexible is it in regards with the input? As long as it works with AVISynth it should be good?

most of the distributed builds of the x264 cli for windows support ffmpeg, ffms2, and avisynth as forms of input.

qyot27

5th November 2010, 19:18

Ditto666

5th November 2010, 19:33

AviSynth input has been available in x264 for as long as I can remember, and I started using the CLI version in 2007. I honestly wouldn't be surprised if it's had AviSynth support since x264 debuted or started getting popular, back in 2004 or 2005.

That's cool. AVISynth is great! :) With the combination of it and h264, I am consistently able to make any encode of SD material to look better than the original in every way.

J_Darnley

5th November 2010, 20:59

AviSynth input has been available in x264 for as long as I can remember, and I started using the CLI version in 2007. I honestly wouldn't be surprised if it's had AviSynth support since x264 debuted or started getting popular, back in 2004 or 2005.

That's easy to check...

It was added in revision 161 which was made on 2005-03-10

qyot27

6th November 2010, 00:36

That's easy to check...

It was added in revision 161 which was made on 2005-03-10
Thanks, I was just too lazy to try and track down the old SVN repo. The only reference I could find through git was a commit in 2006 concerning the long-defunct GTK interface.

rev161, wow. I can't remember how close that was to when I started working with x264, but I remember it was in the upper hundreds or somewhere in the 200 range. And unfortunately, that early usage was by way of the x264vfw or ffdshow-VFW encoder. Thankfully I ditched that and went with MeGUI after only about 3-6 months or so, IIRC.

Dark Shikari

6th November 2010, 00:37

Thanks, I was just too lazy to try and track down the old SVN repo.The git repo has all old SVN commits ;)

qyot27

6th November 2010, 01:26

The git repo has all old SVN commits ;)
So it does...but the search function is case-sensitive. That's why I didn't find it.

Ditto666

6th November 2010, 10:23

Thanks, I was just too lazy to try and track down the old SVN repo. The only reference I could find through git was a commit in 2006 concerning the long-defunct GTK interface.

rev161, wow. I can't remember how close that was to when I started working with x264, but I remember it was in the upper hundreds or somewhere in the 200 range. And unfortunately, that early usage was by way of the x264vfw or ffdshow-VFW encoder. Thankfully I ditched that and went with MeGUI after only about 3-6 months or so, IIRC.

You seem to know what's up in regards to the following so that's why I'm sorta re-asking you specifically for this personal desire for information - I still don't quite fully get what the problem with VFW is. I actually thought that saving it in the AVI container would be the more proper way but after a few explanations, I guess I know why that isn't the case. VirtualDubMod also has the option to save as MKV so with that out of the way, what's left? There's really only two elements, visual and playback. Visually I'm assuming it's the same both ways so what does this method hinder/limit exactly? You taught me a few things but now I'm asking to expand on this specific issue fully, lol. :thanks:

nurbs

6th November 2010, 11:01

Groucho2004

6th November 2010, 11:36

@Ditto666:

I just can't understand why you use VDubMod. It has not been updated in 5 years and you have to use the awkward vfw264 interface.

You already know how to use DGIndex and how to create scripts so why don't you use the x264 CLI? It's frequently updated and all you have to do is write a batch file that could also do the multiplexing with mkvmerge.

Blue_MiSfit

6th November 2010, 13:53

VirtualDubMod can't write native MKV files. It writes them in VfW compatibility mode. Putting H.264 into a MKV that way might cause problems with hardware players. Can't say for sure because virtually nobody creates files that way.

As I understand it, this is one of the biggest issues. VitualDubMod is also quite dead. It's been FOUR YEARS since its latest release! If you must use VirtualDub, please use a proper mainline version that is up to date from http://virtualdub.sourceforge.net/

Thankfully, some builds (MasterNobody's) of x264vfw have the ability to bypass the VFW output entirely and use their own methods to write MP4, MKV, whatever. Your AVI out of VirtualDub(Mod) or any other VFW app will just be a placeholder. Get the latest installer from http://sourceforge.net/projects/x264vfw/files/

The whole "VFW IS BAD" vs "VFW IS FINE" debate endlessly rages, and I sort of gave up on keeping track of the argument.

For me, I prefer working with native CLI encoders, as they're easier to automate en masse (my job!), and things can be done with precision (numbers instead of sliders etc).

On the other hand, there are certain situations where VFW is the easiest thing possible, or sometimes the only way I've got (like my Digital Rapids box capturing 1080i / 1080p video from HD-SDI directly into x264).

So, I use both every day!

A tool for every task, so to speak!! :devil:

Derek

qyot27

6th November 2010, 20:02

Actually, the last release of VDubMod was in mid-late 2007 or 2008, but it was a forked release (1.5.10.3) that then stalled again. Not that that changes the situation much at all, since it was still based on the 1.5 branch.

I'll admit that there is still one thing about VDubMod that I feel is superior to the main branch - the Streams area to control the audio and/or subtitles and chapters instead of the main VDub's regular Audio menu. The Streams stuff could use some updating, of course, but the layout and functionality of it is much more intuitive than what the main branch offers. If someone could take the main branch and fork the Streams menu and the script editor (not that I use it, I compose all my scripts in Notepad; but I know that's a big complaint from some) onto it then problem solved.

You seem to know what's up in regards to the following so that's why I'm sorta re-asking you specifically for this personal desire for information - I still don't quite fully get what the problem with VFW is. I actually thought that saving it in the AVI container would be the more proper way but after a few explanations, I guess I know why that isn't the case. VirtualDubMod also has the option to save as MKV so with that out of the way, what's left? There's really only two elements, visual and playback. Visually I'm assuming it's the same both ways so what does this method hinder/limit exactly? You taught me a few things but now I'm asking to expand on this specific issue fully, lol.
VFW = AVI, for all intents and purposes. AVI's problems are VFW's problems, and vice-versa. When Matroska uses VFW mode, that means it's using AVI-style frame ordering and such. For stuff that VFW doesn't have a problem with (like HuffYUV or Lagarith or MJPEG), MKV's VFW mode is a non-issue. But for H.264, VFW mode exhibits the same problems as an AVI would.

When it comes to formats like H.264, the problem resides in a restriction that VFW has in regard to how frames are treated. That restriction is called 'one frame in, one frame out'. The problem is that MPEG-based video formats commonly have three major frame types: I-frames, P-frames, and B-frames. I-frames and P-frames are pretty much a-okay with the 'one frame in/out' restriction, but B-frames run afoul of it in a big way, and require non-standard hacks to be placed in AVI or anything that works via VFW.

The more consecutive B-frames in a stream, the worse the in/out problem gets. The hacks originated with the DivX and Xvid teams trying to fit MPEG-4 ASP into AVI, and in the case of that format it can go generally unnoticed because ASP has a maximum B-frame limit of 2 or something like that (MeGUI goes up to 4?), but to ensure compatibility with DivX devices, that's usually restricted to a maximum of 1. H.264 is usually used with more B-frames than that, depending on content (with a maximum limit of 16 B-frames). H.264 also has a feature called B-pyramid, which uses the B-frames as references for other frames, which causes further complications.

The hacks used in DivX and Xvid can't be used easily for H.264 because of that maximum limit and B-pyramid. In terms of playback, if you've got a ton of B-frames in an H.264 AVI, your audio will desync...unless the decoders have gotten better, but I was under the impression (from the mass of threads about this subject 5 years ago) that trying to 'fix' those hacks to work with the full breadth of H.264's features wasn't worth the time or effort that'd be needed. That was why the community abandoned the idea and strongly suggested/made it near-impossible to avoid switching to encoding H.264 in compliance to the spec and placing it in MP4 or MKV in native mode. The only way to completely avoid that situation is to disable B-frames entirely, which will hurt your compressibility and hike the filesize for the same relative quality.

Blue_MiSfit

6th November 2010, 20:20

@qyot27:

I compose all my scripts in Notepad; but I know that's a big complaint from some

Ever tried AvsP? It changed my life... open an AVS file in it, and push F5 ;)

ASP has a maximum B-frame limit of 2,

It certainly does not. I did MANY Xvid encodes back in the day with 3 or more. IIRC it goes up to a max of 16 just like H.264, but don't quote me on that ;)

I think most of what you said about VFW and H.264 is quite correct. Somebody should really make a nice sticky somewhere that has ALL THE ARGUMENTS summed up cleanly, because there are a great many of them ;)

Remember though, if you MUST get H.264 out of an app that only supports VFW, you can very easily use x264vfw from MasterNobody as I mentioned in my previous post. This will let you totally bypass VFW output and all of these nasty hacks, and write MP4, MKV, 264 (ES), whatever else x264 can natively mux to on the CLI :devil:

It's like having your cake... and eating it too!!!!! :D

Derek

qyot27

6th November 2010, 22:56

Ever tried AvsP? It changed my life... open an AVS file in it, and push F5 ;)
Not really (meaning: I can't remember if I ever did), as my usage of AviSynth usually doesn't require me to do a ton of filtering, and with how ancient my computer is, it'd probably take AvsP just as long to refresh the script as using VDub or WMP6.4 or MPC to preview changes would.

And just force of habit.

It certainly does not. I did MANY Xvid encodes back in the day with 3 or more. IIRC it goes up to a max of 16 just like H.264, but don't quote me on that ;)
Yeah, I'd said '2 or 3' in an earlier post, then posted that, and then realized MeGUI's Xvid opts can go up to 4, and then found that Xvid's profiles apparently allow up to 5 (http://www.xvid.org/Interoperability.17.0.html). There was so much 'it'll make your hardware/software decoder implode' pressure years ago that I never tried to experiment with it. I'll have to go do that now...

Ditto666

7th November 2010, 07:50

VirtualDubMod can't write native MKV files. It writes them in VfW compatibility mode. Putting H.264 into a MKV that way might cause problems with hardware players. Can't say for sure because virtually nobody creates files that way.
Thanks!
@Ditto666:

I just can't understand why you use VDubMod. It has not been updated in 5 years and you have to use the awkward vfw264 interface.

You already know how to use DGIndex and how to create scripts so why don't you use the x264 CLI? It's frequently updated and all you have to do is write a batch file that could also do the multiplexing with mkvmerge.
Sorry if I didn't make this clear, but yeah, my intention now is definitely to switch to the method that Blue_MiSfit described. I still just wanted to understand how things work and what issues there were.

I learned using VirtualDubMod a few years ago and that's all I knew. I didn't even know about all this VFW stuff. I didn't understand (still don't fully get) what goes on between the input and the output, basically the functions of the codec, so like an idiot at first when I switched computers, I was sitting there trying to figure out how to feed the CLI version of x264 into VirtualDubMod, and then I found the VFW version. I just thought it was the same thing - just the version that gets installed and VDubMod recognizes.

In regards to the batch file and multiplexing... Lol, what? Those terms are familiar, seem basic even, but keep in mind that my knowledge is pretty much limited to that process of mine and maybe just any additional interest I might've had in understanding specifically what things are and their properties.
As I understand it, this is one of the biggest issues. VitualDubMod is also quite dead. It's been FOUR YEARS since its latest release! If you must use VirtualDub, please use a proper mainline version that is up to date from http://virtualdub.sourceforge.net/

Thankfully, some builds (MasterNobody's) of x264vfw have the ability to bypass the VFW output entirely and use their own methods to write MP4, MKV, whatever. Your AVI out of VirtualDub(Mod) or any other VFW app will just be a placeholder. Get the latest installer from http://sourceforge.net/projects/x264vfw/files/

The whole "VFW IS BAD" vs "VFW IS FINE" debate endlessly rages, and I sort of gave up on keeping track of the argument.

For me, I prefer working with native CLI encoders, as they're easier to automate en masse (my job!), and things can be done with precision (numbers instead of sliders etc).

On the other hand, there are certain situations where VFW is the easiest thing possible, or sometimes the only way I've got (like my Digital Rapids box capturing 1080i / 1080p video from HD-SDI directly into x264).

So, I use both every day!

A tool for every task, so to speak!! :devil:

Derek
Thank you for the insight!

I meant what I said the first time though and I will be trying out the new suggested method next chance I get. Interesting to here about the VFW bypass but the more correct method actually seems possible to turn out more efficient.
Actually, the last release of VDubMod was in mid-late 2007 or 2008, but it was a forked release (1.5.10.3) that then stalled again. Not that that changes the situation much at all, since it was still based on the 1.5 branch.

I'll admit that there is still one thing about VDubMod that I feel is superior to the main branch - the Streams area to control the audio and/or subtitles and chapters instead of the main VDub's regular Audio menu. The Streams stuff could use some updating, of course, but the layout and functionality of it is much more intuitive than what the main branch offers. If someone could take the main branch and fork the Streams menu and the script editor (not that I use it, I compose all my scripts in Notepad; but I know that's a big complaint from some) onto it then problem solved.

VFW = AVI, for all intents and purposes. AVI's problems are VFW's problems, and vice-versa. When Matroska uses VFW mode, that means it's using AVI-style frame ordering and such. For stuff that VFW doesn't have a problem with (like HuffYUV or Lagarith or MJPEG), MKV's VFW mode is a non-issue. But for H.264, VFW mode exhibits the same problems as an AVI would.

When it comes to formats like H.264, the problem resides in a restriction that VFW has in regard to how frames are treated. That restriction is called 'one frame in, one frame out'. The problem is that MPEG-based video formats commonly have three major frame types: I-frames, P-frames, and B-frames. I-frames and P-frames are pretty much a-okay with the 'one frame in/out' restriction, but B-frames run afoul of it in a big way, and require non-standard hacks to be placed in AVI or anything that works via VFW.

The more consecutive B-frames in a stream, the worse the in/out problem gets. The hacks originated with the DivX and Xvid teams trying to fit MPEG-4 ASP into AVI, and in the case of that format it can go generally unnoticed because ASP has a maximum B-frame limit of 2 or something like that (MeGUI goes up to 4?), but to ensure compatibility with DivX devices, that's usually restricted to a maximum of 1. H.264 is usually used with more B-frames than that, depending on content (with a maximum limit of 16 B-frames). H.264 also has a feature called B-pyramid, which uses the B-frames as references for other frames, which causes further complications.

The hacks used in DivX and Xvid can't be used easily for H.264 because of that maximum limit and B-pyramid. In terms of playback, if you've got a ton of B-frames in an H.264 AVI, your audio will desync...unless the decoders have gotten better, but I was under the impression (from the mass of threads about this subject 5 years ago) that trying to 'fix' those hacks to work with the full breadth of H.264's features wasn't worth the time or effort that'd be needed. That was why the community abandoned the idea and strongly suggested/made it near-impossible to avoid switching to encoding H.264 in compliance to the spec and placing it in MP4 or MKV in native mode. The only way to completely avoid that situation is to disable B-frames entirely, which will hurt your compressibility and hike the filesize for the same relative quality.

There was a nice and short page, straight to the point, from which I learned what I, P, and B frames were about a year ago. I understood but the understanding I'm sure was just of the elementary functionality - all this time not having to think about it at all, or rather, not coming across this. I almost completely forgot what I knew. Maybe I was being stubborn because I couldn't find the page, but looking it up, I didn't find a very good description from which I understood. At this point, what I'm not even 100% sure of is that an I-frame works by looking at the previous frame, seeing what's similar, and using that same data for the next instead of processing/adding new. B-frames are the same except they work looking at the previous and the following (though I'm thinking and I can't figure out how it can look at data that hasn't even come up yet, in regards to the frame that follows I mean). Maybe I'm mixing up two different things, I dunno... A lot to say to not be sure where I'm going with this but I'm actually not, lol.

Anyway, no, it actually makes sense everything you explained regardless. Before, as you probably realized, I just thought the issue was only in regards to the AVI output but it works on that basis regardless. I keep saying thanks, but I'm not sure how to say it each time so that it actually sounds like I mean it, lol. But yeah, thanks :)

Ditto666

7th November 2010, 10:53

@Blue_MiSfit

So I tried AvsP and of course, I really do like it, but as a problem I've noticed with all these kind of previews so far - it's not the same as how it looks when actually played back, and not only because it shows the effect of the script before processed by whatever codec... It's just not accurate in general, my guess being because it's being displayed as an image without the effect of applied quality adding video settings, like often done by the graphics card. How it helps though is that you can still get an approximate idea and test the amount of change between intervals, but nothing more.

The biggest difference/problem I'd have to say is sharpness. When I actually play the result back (using MPC with FFDShow), it's an incredible amount sharper and more like what I'd expect the applied filters to do. In the preview, the effects are subtle at best. In general, the image seems to be less detailed even in the sense of overall contrast, aside from all other applied meanings. So I dunno.. I was sorta hoping for an accurate representation or some options for customization. One thing it does well though is scaling, at least...

7th November 2010, 11:49

Ditto666

7th November 2010, 12:16

What happens to the video playback if you turn that stuff off from the graphics card driver (and ffdshow, if you use custom settings there)? You should aim for an AviSynth script that makes the video look like you want it to look without further processing during playback, except maybe debanding.

Well, I would thing that it'd also has to do with the decoder. Each decoder from my experience changed up the looks a little. Even the PS3 for instance does so, though I actually love how it processes video, perfect IMO, even its filters.

But anyway, I mean, I knew that if turned off the effects of the graphics card, it would look worse, or rather, more like in the preview, if not EVEN worse, but that defeats the purpose of the whole idea pretty much. The computer display is not meant to be accurate for such source material and it isn't. If the video is played on an HDTV or from a projector, with everything setup properly, obviously picture settings included, it would look nothing like the preview in AvsP or whatever. Again, it defeats the entire purpose. Separate video display settings are there for a reason and I spent the time to adjust everything to look right. Most professional programs work with the graphics card as they should so yes, it would make sense not to apply additional settings afterward and comparing but in this case, I really think that's how it has to be. When it comes to picture settings, the default for picture settings is rarely right unless professionally bought for those purposes or just very simply, always look like crap. So, basically I never knew how to deal with this issue, getting the graphics card to process that data as video. I was just hoping that I wouldn't have to go through the tiresome process of purposely fully encoding segments to then compare video and/or save then compare individual frames afterward to figure out what's right/wrong and what I need to do.

creamyhorror

7th November 2010, 12:18

So I tried AvsP and of course, I really do like it, but as a problem I've noticed with all these kind of previews so far - it's not the same as how it looks when actually played back, and not only because it shows the effect of the script before processed by whatever codec... It's just not accurate in general, my guess being because it's being displayed as an image without the effect of applied quality adding video settings, like often done by the graphics card.
Sure it's accurate, since you can't (and shouldn't) expect it to include the effect of any postprocessing filters that you personally apply in your video playback. It's accurate relative to playback on a normally configured media player (MPC-HC or otherwise), not one with customized settings.

The biggest difference/problem I'd have to say is sharpness. ...In general, the image seems to be less detailed even in the sense of overall contrast, aside from all other applied meanings.
What Avisynth function are you using to display the file? What's your viewing script? The poorer quality may be due to the use of a poor decoder. A good option is FFVideoSource(), which you can get by installing the FFMpegSource plugin (http://code.google.com/p/ffmpegsource/) - it uses FFMpeg to display the video.

edit:
But anyway, I mean, I knew that if turned off the effects of the graphics card, it would look worse, or rather, more like in the preview, if not EVEN worse, but that defeats the purpose of the whole idea pretty much.
Graphics cards normally don't affect video playback - it's determined by the decoder, renderer and player you use. All proper H.264 decoders will output the exact same image, and by default, I believe no particular filtering is applied by video cards. So the differences will stem from any postprocessing filters you've personally applied, and from the choice of renderer in your player. What filters have you applied?

Ditto666

7th November 2010, 12:26

Sure it's accurate, since you can't (and shouldn't) expect it to include the effect of any postprocessing filters that you personally apply in your video playback. It's accurate relative to playback on a normally configured media player (MPC-HC or otherwise), not one with customized settings.

What Avisynth function are you using to display the file? What's your viewing script? The poorer quality may be due to the use of a poor decoder. A good option is FFVideoSource(), which you can get by installing the FFMpegSource plugin (http://code.google.com/p/ffmpegsource/) - it uses FFMpeg to display the video.

edit:

Graphics cards normally don't affect video playback - it's determined by the decoder, renderer and player you use. All proper H.264 decoders will output the exact same image, and by default, I believe no particular filtering is applied by video cards. So the differences will stem from any postprocessing filters you've personally applied, and from the choice of renderer in your player. What filters have you applied?

I realize now that wasn't the proper way of phrasing things. Yes, it itself is accurate but not for what the end result actually ends up being which would be fixed by incorporating whatever parameters are set on the operating system for video playback.

In terms of the function for display, that never even crossed my mind. I have no function for that. I guess it goes to the default? Dunno... You think this might get it to utilize my video card?

EDIT: I haven't applied any filters in FFDShow or MPC. But yes, you are right, it's video settings that I've made for the graphics card to apply for reasons that I described in the previous post. Also you are right that by default, it's set to utilize whatever settings the player would use which is usually nothing, but even without the adjustments I've personally made, setting the graphics card to handle the PQ imitates the look more closely to how it would be in a proper display configuration. It's general though for every display that might come with a computer or whatever, so obviously it can't be 100% dead-on.