How to compress AMV using h.264

[Corran]

Cool, I knew you've been working on that for some time. Glad to finally see it. I agree with Janzki though. It is rather advanced for most editors to bother with.

And since I had too much free time I went and made a batch file to use with this guide to make things easier for myself. I hope other people will find useful too.

It requires an addtional app, BeSweet. (which is in the amvapp) As well as two plugins for it placed in the BeSweet executable directory:
VOBInput.dll and libmmd.dll (Very bottom of page)

To use the batch file simply edit or add the appropiate variables and save the file. Export your video project losslessly muxed with WAV audio and drag the resulting file onto the batch file. Once the batch is done running you will have an mp4 file in the same directory as the lossless copy.

(Right click, save as, and rename extension to .bat)
http://www.randomdestination.com/member ... to-mp4.txt

I plan on making the number of passes a variable but for now I'm tired of writing the batch...

[Melanchthon]

The passes on that .txt are numbered 1-3-3. Typo, or something I've missed in the docs somewhere?

Useful guide, Zero1. For some reason parts of it make more sense than the EADFAG-style walkthroughs I've read.

[Corran]

The passes on that .txt are numbered 1-3-3. Typo, or something I've missed in the docs somewhere?

Not a typo

--pass 3
--pass 3 is somewhat special. It isn't referred to as Second or Third pass, since the amount of passes you can do with it are infinate. The quality gain isn't, so don't go doing 10 pass encodes. It is really only useful for sources around 1000 frames or less where it doesn't have much time to average the bitrate properly. It essentially does the job of -pass 1 and --pass 2, but pass 1 is still required for initial stats collection. Instead of just reading from the stats file and providing output, it reads from the stats file, outputs and updates it. This means that if you do a 3 pass encode using the nth pass mode, it will be using refined stats from pass 2. The easy way to understand this is to visualise it.it will work from the stats from pass 1 that have been refined when you ran pass 2.

(Pass 1) --pass 1 = Initial stats collection
(Pass 2) --pass 3 = Output using Pass 1 stats + update stats file
(Pass 3) --pass 3 = Output using Pass 2 stats + update stats file

[Corran]

P.S. I don't claim any of the x264 settings in that batch file to be optimal. It was made solely for drag and drop automation. People would need to find out what settings are best for their source.

[Qyot27]

Because of Janzki's comment, I decided to try my hand at doing a GUI-centric encoding guide again. It'll cover both basic encoding with x264 through MeGUI (not explaining every option, just the more or less relevant ones) and basic operation of MeGUI itself, how to encode AAC with Quicktime Pro or iTunes, how to encode Vorbis with oggdropXPd (not that it needs much in the way of explaining, but for completeness' sake), and the muxing of the video and audio into either MP4 or MKV with YAMB or MKVMerge-GUI, respectively.

[trythil]

Because of Janzki's comment, I decided to try my hand at doing a GUI-centric encoding guide again. It'll cover both basic encoding with x264 through MeGUI (not explaining every option, just the more or less relevant ones) and basic operation of MeGUI itself, how to encode AAC with Quicktime Pro or iTunes, how to encode Vorbis with oggdropXPd (not that it needs much in the way of explaining, but for completeness' sake), and the muxing of the video and audio into either MP4 or MKV with YAMB or MKVMerge-GUI, respectively.

I think part of the problem here is the sheer number of programs you mentioned.

Zarxrax asked me to make a simple x264 GUI that would do both audio and video in one click. I got lazy and never finished it ( :P ), but he's giving it a try on his own.

If you want to make x264 popular in the larger AMV community, I think something like that is the first step -- not necessarily a guide to the existing programs out there.

[Willen]

You'd have to dumb it down with some overage for filesize vs. encoding efficiency. Choose the bare minimum of programs needed, and make sure they all easily obtainable without the need to purchase anything (QT Pro). I'd omit everything except the encoding and muxing of H.264 and AAC into MP4. OGG and MKV would just complicate things, especially if the quality gains of OGG and the flexibility of MKV aren't needed. Plus, the inclusion of more things in the encode/mux side means that more things are needed in the decode/file-splitting side, so simpler is better here.

[Qyot27]

Choose the bare minimum of programs needed, and make sure they all easily obtainable without the need to purchase anything (QT Pro)

My reason for including QT Pro is mainly because it's a heck of a lot more convenient and easier to set up to use than iTunes is as far as AAC encoding goes (although like I said, I'm covering both of them); the differences between the two are largely cosmetic, QT Pro being more compact and iTunes requiring more clicking around, aside from the obvious price difference (despite the fact that they both use the same encoder ). Either way, if one wants to use iTunes to encode the audio, then the video and audio still have to be muxed in a separate program afterwards, which means using MP4Box (which is what YAMB takes care of for those that don't want to use the command-line) or MKVMerge, depending entirely on which container the person wants to use.

They could potentially use Nero's AAC encoder or FAAC, but the support behind Apple's encoder far outweighs those because of the quality tests. If they wanted to use Nero's or FAAC then it would be completely possible to encode everything in MeGUI (but they'd still have to mux them in a separate step afterwards - and MeGUI's MP4 and MKV Muxing screens don't allow for anamorphic flagging - something that is far easier to do in YAMB or MKVMerge rather than worrying about during the encoding phase, so long as the video is already at the right base dimensions).

I'd omit everything except the encoding and muxing of H.264 and AAC into MP4. OGG and MKV would just complicate things, especially if the quality gains of OGG and the flexibility of MKV aren't needed.

It's just that I really don't agree with the push toward one container or the other, no matter what the reason is, especially since they both handle H.264 properly (MKV's only downside is that it's almost 100% likely not to have any hardware support, but for the vast majority of AMV viewing that's going to be irrelevant, as it already is). In either case extra steps are required, and for those that want to use MKV instead, I'm not going to ignore it, especially because I have more experience with using MKV than I do with MP4 (for video; that's one of the very reasons I use MKV more for nearly all of my own H.264 encodes - most MP4s I have and use on a daily basis are audio files and therefore I have .mp4, .m4a, and .m4p extensions all associated with Winamp 2).

I know how that last paragraph must have sounded, but what I'm saying is that even if the features that distinguish MKV from MP4 or vice-versa aren't needed, there may still be valid reasons to use said containers, and it should be covered so that the person reading it has a choice (the addition of Vorbis into the audio encoding is because of the tendency to use Vorbis with MKV due to the open-source factor inherent there). All it takes is to present it in an easy-to-follow layout based on which they want to use rather than trying to mix the two methods into the same section.

Plus, the inclusion of more things in the encode/mux side means that more things are needed in the decode/file-splitting side, so simpler is better here.

How so? If this is being aimed at the audience that uses the CCCP, then there's only the same two pieces of software involved - Haali's Media Splitter and ffdshow - and it doesn't matter whether it's H.264 and AAC in MP4, H.264 and AAC in MKV, or H.264 and Vorbis in MKV. If they use VLC or mplayer, they have everything already built-in, and if they want to use CoreAVC, CoreAAC, and CoreVorbis instead of ffdshow then they probably already know how to deal with that.

[Willen]

Plus, the inclusion of more things in the encode/mux side means that more things are needed in the decode/file-splitting side, so simpler is better here.

How so? If this is being aimed at the audience that uses the CCCP, then there's only the same two pieces of software involved - Haali's Media Splitter and ffdshow - and it doesn't matter whether it's H.264 and AAC in MP4, H.264 and AAC in MKV, or H.264 and Vorbis in MKV. If they use VLC or mplayer, they have everything already built-in, and if they want to use CoreAVC, CoreAAC, and CoreVorbis instead of ffdshow then they probably already know how to deal with that.

If everyone used CCCP then this would be a moot point. But I still see many download "Codec Pack X" recommendations, and many people use VLC as their player, which at least for AMVs is fine. But it's sub support is a bit lacking. But I digress.

The only thing I wish that the companies didn't do is use the MP4 extension for audio only files. I know that it is the only official extension for the MP4 container, but IMO it just causes confusion (look at what we have now with AVI). Apple has a good idea with M4A (and aside from the DRM stuff, M4P). Using MP4 gets people thinking "hey, it's an audio file" ala. MP3, especially since Winamp assumes that MP4 is audio-only (like they do for MP2).

And there is one potential downside to MKV - its greatest strength is its greatest weakness: the ability to support almost everything and anything. Which is almost the situation that we have with AVI, but without hacks. But better MKV than AVI for h.264 stuff. Don't get me wrong, I like MKV, if used when needed. It's like driving your Chevy Suburban down the street to get a carton of milk instead of your Toyota Camry. But once again, I digress.

I would like to see your guide. The more, the merrier.

[Corran]

Ok.... I've made some updates to the original batch from earlier. Now you can specifiy the number of passes in the settings. Also, instead of entering the bitrate you now specify a final target size in megabytes.

Both of these features require the batch to do a little bit of math so if you are not using windows 2000 or XP it will not work for you... sorry.

And to make things even easier here is a zipped file of everything needed. Just unzip it and drag your input video onto the batch file inside the folder. Of course, you will need to edit a few of the settings in the batch before you do that though... Besure to read the included README and follow Zero1's guide when configuring the additional settings.

http://www.randomdestination.com/member ... ebatch.zip