Janzki wrote:Maybe a simple MeGUI guide a la EADFAG with the basic settings and maybe a few tips would make people more willing to try h.264 encoding.
Yeah, that would probably be a better option, or rather more user friendly. I think the easiest way to get people encoding with x264 is to give them something familliar, this is why a lot of people first start off with the VfW codec (familliar program, familliar interface); unfortunately though, VfW sucks for H.264 (and it sucked for ASP too (DivX/XviD), but those have become tolerated hacks).
The first thing that springs to mind is to keep away from Virtualdub completely for encoding (obviously still using it for your lossless stuff and previews), but still provide a GUI that is not too dissimilar to XviD. Then you can use the XviD Read <a href=http://www.a-m-v.org/guides/avtech31/>ErMaC & AbsoluteDestiny's Friendly AMV Guides</a> section as a basis or template for the guide. Again it's providing them with something that is familliar. The only problem here is that there are a number of differences between ASP and H.264 that you need to stress in the guide. The original XviD guide gets the user to output a constant quantizer 2 encode somewhere along the lines; well Q18 in H.264 is roughly similar to Q2 ASP. If your newbie goes putting Q2 in x264, you will get some pretty hugeass files, much larger than XviD at Q1.
As I will have mentioned before, I got a computer in 2000, and command lines aren't something the average end user had to deal with in that sort of time. Everything is heavily GUI based. Fortunately for me I had been using computers in school and stuff since around 1997. I got to be friends with the school computer whizzkid, and he showed me a thing or two about creating boot disks, formatting and generally giving the IT staff a hard time
, so fortunately for me, I wasn't completely green to DOS or command lines.
I've been using x264 for a long time now, it's certainly going on for 18 months to 2 years, and back then I started off with the VfW (back then MP4 support was pretty niche and MKV didn't support H.264 either). After a few non serious tests (just basically gauging the difference between XviD and x264), I thought to myself, "Well I've been encoding for around 5 years now. Video codecs come and go, they get upgrades, it's always getting better, but the audio has always been MP3, and that hasn't come as far as video coding has. Why don't I look into AAC and see if I can hack it into AVI?" And so it was, I made some truly bastardised (but fully functional) test encodes.
Being in fansubbing I was thinking what effect this would have on Joe Average, the leecher. I thought, "Well this requires them to install 2 codecs" (no CCCP back then, and before I got into a bit of a flame war with a DVD ripper, I hadn't liked or used FFDShow), "For the sake of having to install a third component, I might as well use MP4 and do it the spec compliant way". Unfortunately for me, the only way to encode spec compliant files at that time (as far as I was aware) was to use the x264 CLI. I hated CLI. There had been so many programs that I wanted to use before but couldn't because I was a CLI phobe, but this was it. I had to get to grips with it no matter what.
I remembered batch files from back in the day, so that was my starting point, x264.exe and a batch file in the same directory with my source AVS file. I ran the x264 CLI to get it's help and basically built up a minimal command line in the batch; I then went through the help again and added in any switches or options that I wanted to change. I ran the batch and that was it. It worked perfect. I had output a raw H.264, and then I went on to encode tha audio (can't remember what I first used, might have been FAAC or Nero) and mux with mp4box. So it was that I came to using H.264 + AAC in MP4, and I've never looked back.
And this is why I wrote a guide to the CLI. I could have hassled trythil or Coderjoe to come up with an XviD like GUI and written a Read <a href=http://www.a-m-v.org/guides/avtech31/>ErMaC & AbsoluteDestiny's Friendly AMV Guides</a> style walkthrough, but learning CLI widened my options. There are a lot more programs that I can now use; some or most of which don't have GUIs, or of those that do have GUIs, they tend not to have all the features (the design is another complication, ie grouping of options and how you will represent something for example multiple choice, or user entry).
It means that I can use the latest versions of x264 and mp4box and make use of any new features, because obviously, they appear in the CLI before someone's GUI. Since there are some programs that are CLI only, for example the reference MPEG-4 ALS (a lossless MPEG-4 audio codec, which can also be stored in .mp4), I found that learning CLI really opened my options, and really, it's barely any more difficult that making an AVISynth script.
That is why I wrote the CLI guide, because I could see that it would be beneficial in more ways that one (add to that, due to it's format, it's easier to list the options and explain them, rather than littering them throughout a guide when you come to a GUI screen that has those certain options). Also by providing all the relevant information, it means that people can make an informed decision rather than entering random numbers that may be suboptimal. There are a few tips and hints littered in the guide, but I purposely try not to tell them what is best, what I think is best, or what to use. I do this in the hopes that people looking for a great encode will try things of their own accord, and perhaps if they find anything interesting, they will share.
Reading a post or two down, I see Corran's batch. Very nice little batch it is too. However I did this once before. I wrote a basic batch to automate encoding the video, audio and muxing to mp4. If I recall correctly, it also checked for an existing audio file (IF EXIST, IF NOT EXIST etc), and if an AAC or MP3 already existed, then it would mux that file (assuming the file is there because you encoded it before hand). I handed the batch file with the programs and such round to a few people to kick them off encoding with x264; unfortunately it seems from the few encodes I had seen, that they didn't change the default values.
For instance you would have a few AMVs encoded at 1000kbps (which is obviously a number I picked out of thin air for the sake of putting a number in the batch file). The thing with that is that 1000kbps may look awesome for one video, and absolute shite for another. It's a basic concept, but a lot of people just assume that more bitrate = higher quality. While this is true, people often fall into the trap of treating bitrate as a sort of measure of quality. Eg you would assume 500kbps would look crap, but for easily compressible sources it may look great, on the other hand an action AMV would look ass at 500kbps, you can't judge quality by bitrate.
An easy way to visualise this is by getting two different images. Something like 640x480 will be good and save them in photoshop at 100% JPG quality. You will see that the filesizes can vary a lot. Now think of 24 of these images in a row, each slightly different. That difference between the two images becomes more apparent as you increase the number of images. While it's true that temporal compression will get rid of a lot of the filesize, the point of interest is that these two sequences can be very different, and the filesize can be a lot different, which is why you shouldn't measure quality by filesize.
Say you have two images again, one is 350KB, the other is 100KB. This could represent one high quality keyframe in a video, or two JPG images. Now what a lot of people might do is encode all of their AMVs at a set bitrate, say they use 1500kbps. Now encoding all your videos at the same filesize, is like saying you will save all your images at the same filesize. Now if you take the two JPG images, and at the same quality level (lets say Q70 in photoshop) one is 350KB and one is 100KB, but you always "encode your stuff at the same filesize", say 150KB; the 350KB image has to drop a lot of quality to reach the target, but the 100KB image will look fantastic (since you would up the quality level to reach the filesize).
Same applies for video. You do a Q2 encode on two AMVs (lossless sources preferable) and see how much the filesize can vary. You have encoded these at the same quality. One video might have came out at 2500kbps, the other at 900kbps. Say if you always go for the same filesize, something like 10MB per minute, which seems to be popular; that is around 1235kbps (including 128kbps audio). Now the 900kbps video has already attained very good quality (Q2 at that bitrate), so to meet that target of 1235kbps you have to uncap the quantizers. That would mean using Q1 in places, which is considered wastage because it does not bring a worthwhile visual improvement. You may as well just keep it at 900kbps; it's already high quality.
Now as for the 2500kbps AMV, you have to lose a lot of quality to bring it back down to 1235kbps. This means using higher quantizers which is basically dropping the quality level (similar to how you had to drop the quality level in photoshop to make the 350KB image to 150KB). Using higher quantizers means more course rounding, which causes visual errors, such as blocking and ringing. It's almost impossible to guess at it, but it may end up using an average of Q4 or Q5 to bring the 2500kbps source down to 1235, and let me tell you, that is pretty ugly.
Also, contrary to what you might assume, quality does not rise proportionately with bitrate. You can encode a video at 500kbps, and it will look pretty bad, but encoding it at 1000kbps will look a lot better (certainly not "twice" as good). Similarly, going up to 1500kbps may not look a whole lot different to the 1000kbps (and definitely not "three times better", than the 500kbps). You see the reason this is, because the most noticable details are stored early on in the codec, the low frequency co-efficients don't use a lot of bitrate anyway. It's the fine details that eat up all the bitrate. That is why the difference between 1000kbps and 1500kbps may not be a lot; at 1000kbps you may already be retaining the bulk of the image quality, any additional bitrate on top of that will be used for storing the high frequency co-efficients (which the eye does not notice easily, and additionally they require a lot of space to store).
High frequency co-efficiencts basically transliate to "fine detail", ie really thin lines. This is why sharpening a video decreases compression, because you increas the number of high frequency co-efficients. The most common form of this rule is seen in limiting XviD at Q2 for encoding. Most details are retained at Q2; Q1 retains even more, but they are higher frequency, require more bits and they eye does not notice them easily. This is why a Q1 encode is much larger than Q2, but looks barely any better. It is better, just your eyes can't see the "additional quality" that well. And so, I have completely gone off on a tangent once again...
The reason in giving the batch file out was so that they have some kind of template so they can manipulate and try higher quality settings if they had a good CPU, or were prepared for a wait. What Corran has done is very helpful, no doubt. But I do worry that people will simply just use the default values, rather than getting the most from the codec.
Well enough of my encoding life story; but that gives you a little insight as to why I use MP4, and why I wrote the x264 CLI guide. I know that some people are working on guides and such; and I think it would be a shame for my guide never to make it to the org, but I just have so little time these days. It would probably be nice to have it up there as an alternative guide for people willing to stray from GUIs.
Corran wrote: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.
I agree there is a lot to read, but the way I designed it means you can skip straight to the batch, or go skip to the relevant set of switches you want to check out. It's hard for us to understand because we take video editing and encoding for granted having done this for so long, but looking from the outside in, the whole process of ripping DVDs, IVTC, filtering and even editing is something Joe Average would probably struggle with at first (I mean just look at the newbies putting out interlaced videos, or stuff with subtitles, they start somewhere).
The Read <a href=http://www.a-m-v.org/guides/avtech31/>ErMaC & AbsoluteDestiny's Friendly AMV Guides</a> itself isn't exactly dumbed down enough for Joe Average to follow either; you need a bit of an idea of what you are doing, the process you follow and so on, allowing you to find which section of the guide you need, because the Read <a href=http://www.a-m-v.org/guides/avtech31/>ErMaC & AbsoluteDestiny's Friendly AMV Guides</a> isn't like:
1. Rip DVD: Go here and see the DVD ripping walkthrough
2. Use Virtualdubmod to import .vob and save as AVI
3. Import to Windows movie maker and make AMV
4. Save as 2060kbps WMV.
It covers a manner of things that are essential, and not so essential (but still are pretty important quality wise, stuff like colourspaces which I bet most people don't think twice about). Bearing this in mind, I didn't think my guide was beyond the scope of the Read <a href=http://www.a-m-v.org/guides/avtech31/>ErMaC & AbsoluteDestiny's Friendly AMV Guides</a>, after all, the Read <a href=http://www.a-m-v.org/guides/avtech31/>ErMaC & AbsoluteDestiny's Friendly AMV Guides</a> goes on to explain temporal compression, B-frames and the like. If you are telling me it is, then I am flattered, because the Read <a href=http://www.a-m-v.org/guides/avtech31/>ErMaC & AbsoluteDestiny's Friendly AMV Guides</a> is awesome, but really, it's as simple as reading through how to create a batch file, add switches, and there is a description of the switches there too if you want to find out what one does.
I don't think the guide is too advanced for people, it's just long and looks that way. Of course it's easy for me to say what with having an interest in encoding, I already understand this stuff (and as such it's not easy to see it from someone elses point of view).
I appreciate your comments, but I don't think I'll be changing the guide in such a way that it loses it's format. I hope that not handing it on a plate to people will get them to come up with their own command lines and so on, similarly like with AVISynth; instead of giving them pre-made scripts (which can be great for one source and damn useless for the next), give them the knowledge to create their own. Just like the proverb, "If you give a man a fish, he will have a single meal. If you teach him how to fish, he will eat all his life".
Perhaps I am too wrapped up in encoding, but I don't think it's something that should be dumbed down indefinately. Just things like why videos should have a resolution divisible by 16 is a good start, then you go on to explain that the reason is because macroblocks are 16x16, and using a non mod 16 resolution means inefficient use of macroblocks, and also that they get displayed "offscreen" and can cause display errors or tearing with some decoders that don't work around such things. Or why lanczos resizing shouldn't be used for downscaling, because it sharpens, which a) causes ringing or haloing in a source, and b) creates more high frequency coefficients and therefore does not compress as well as it should.
The rule of thumb is lanczos/bicubic for upscaling (which you should try to avoid anyway since it's just wastage; use anamorphic where possible), and bilinear for downscaling. If it's too soft for you then there are always sharpening filters which you have finer control of compared to just a lanczos scale. I see so many mistakes. Sure I'm not perfect, but I see basic mistakes in encodes from supposedly the best fansub groups. A little knowledge helps everyone, I want to spread the information and help people get better quality.
Most times you only release an AMV or fansub once, so in my opinion, it needs to be at it's best, so you can come back to it in 3 or 4 years time and think, "Damn that still looks good". I mean look at all the awesome AMVs in the top 10% list. Quite a few of them are good old constrained paramater bitstream MPEG-1 encodes (you know, the 352x240 @ 1150kbps stuff, with 224kbps audio). They don't cut it in today's world, and it's a shame.
But you know, having said that, I kind of wonder if that old .mpg encode adds something to the video, a sort of retro or nostalgic feel. I'm very fond of my SNES and MegaDrive games. If someone were to re-release the same games but with better graphics and audio, it just wouldn't be the same. One thing is sure, if you do an exceptional job in the first place, you can look back on it and think, "That was pretty fucking good for it's time". One particular SNES game that has that effect for me is Donkey Kong Country. You play Super Mario World, or one of the Sonic series on the MegaDrive, then compare it to Donkey Kong. They are all awesome games, but Donkey Kong is worlds apart, and despite it's age; the high quality it was at it's time still shows now.
.oO(I'm going off at a tangent again -_-)
Dumbing down encoding has already had bad effects on the industry what with DivX. In case anyone reading didn't know, storing DivX or XviD encodes using B-frames in AVI is bad. AVI isn't properly capable of B-frames, and the VfW framework has certain limitations which mean frames literally get packed together (pretty ugly really, they do this so two frames get forced through the decoder at once). Now we have the .divx file format, which is basically .avi but hacked up more to support menus, dual audio and so on. Wouldn't it have been great if these people spent their time implementing some better MP4 menu makers, splitters and so on, instead of hacking old formats?
Melanchthon wrote:Useful guide, Zero1. For some reason parts of it make more sense than the EADFAG-style walkthroughs I've read.
Thanks, it's kind of weird seeing as I used the XviD guide as a template (the formatting and quicklinks part) that my guide would be easier to follow than the thing it was based on (lol), but it means what I was trying to achieve has worked. I know a few people have found this useful, it's really nice that I can share something I know with the rest of the AMV community. In the long run it ought to ease the distro costs for the site (smaller files = less data to transfer = less cost to run), also make downloads faster in general, even for those on slower broadband, and perhaps make it a little more accessible for dial up users, and increase quality at the same time. It really is a great thing to be part of.
Qyot27 wrote: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).
What is so bad about "pushing" MP4? It already has a lot of favour in the AMV scene, so it's not like we are trying to twist people's arms. It's the ISO spec container from MPEG, for MPEG. Storing H.264 in .mp4 is only natural, as is storing MPEG-1 in .mpg, or are you suggesting we store MPEG-1 encodes or any other type that has it's own specific container in MKV now "just because"?
In my opinion it's silly to use MKV if you aren't using any of it's features that make it useful. You might as well use MP4 and benefit from better 3rd party and commercial software support (the leechers benefit from this too). If you are using features like softsubs, then fair enough, but if you are using plain H.264 + AAC, MKV offers no benefits whatsoever. If people feel like working around some limitations Quicktime's H.264 decoder has (in as much as not using 8x8 DCT or custom quant matrices), then that MP4 is playable on Quicktime, making it accessible for people with Macs (and noobs too, because not everyone likes or knows about VLC). If people are smart enough to softsub, then I think that they are probably smart enough to goolge mkvmergegui and throw 3 files into it and press mux
As we all know PSP and iPod play H.264 and AAC in MP4, who's to say in a year or so these devices won't be updated enough to have the CPU power to play our AMVs off the bat? That's another potential goody with MP4. Also whilst on subject, Apple unveiled it's "iTV", which will play H.264+AAC in MP4 too (but the spec is unknown at the moment, so don't get excited just yet).
Qyot27 wrote: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.
There are still some people around who have an irrational fear of FFDShow, which probably stems back to when OGM and MKV were in development, stuff was crashing and people were blaming MKV/OGM/FFDShow or whatever. Whose compile you get matters too, some work, some don't (properly). At the moment I use CoreAVC and CoreAAC with Haali for my MP4 encodes; but someone who has never heard of, or wants to install these or CCCP can still watch my stuff if they have Nero installed, or if the file doesn't use high profile, they can watch it in Quicktime too.
This is where interoperability comes into play, and is a nice thing for the newbs (depending on whether or not you care if people can see your video or not, I simply have written a guide on H.264+AAC in MP4 playback a long time ago, so it's a non issue for me). One thing about VLC, is that it has some oddities with MKV. Perhaps not of much concern to the AMV scene, but it tends to crash VLC when storing native ASP in it (ie non hacky XviD encodes). IMO that's pretty poor. A few encoders I know have been using native ASP in MKV on purpose to give VLC users a hardtime and getting them to migrate to CCCP >.> The poor Mac users; heh.
Willen wrote: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).
Winamp should be shot. Well at least my registry entries will be of use to some people. Even though they may think WMP is evil, it's a hell of a lot better than Winamp for video.
Qyot27 wrote:The --longhelp readout from x264's commandline shows that the command is just --thread-input, without the 's' or an integer setting.
You guys found an error, thanks. That's just the kind of feedback I want. I know where this came from, I've been copy pasting sections to retain the formatting and use it like a template, I obviously forgot to change the usage part of it (and the "s" on the end of it).
How the tables turn.