I'm having some trouble encoding. Most notably, when I set the bitrate below 500-ish, the first second becomes blurry. I can get good quality, but not small enough files.
Can someone give me good windows MEncoder scripts, 2 or 3 passes, 3 MB (or lower if possible)/min?
The number of MB/min is entirely dependant on how many frames are skipped (with -vf decimate). 3 MB/min is a bitrate of 409 if no frames are ever skipped. (..and higher if so. example would be: half of all frames skipped = bitrate of 818) Also you might want to lower those numbers if your 3MB/min figure included audio.
To see what settings other people used to encode the final pass of any h264 video, open it with a hex editor, and it will tell you near the beginning of the file (usually begins with "cabac=1") :)
If the first second is a trouble for you, use the zones setting to force a particular quantizer for a particular region of the movie.
That way, you can give a low quantizer (i.e. high bitrate) for the intro, while everything else is, say, 300 kbit/s by average.
Well, I have next to no experience with this, but this has worked for me before:
Pass 1:
-x264encopts subq=4:bframes=3:b_pyramid:weight_b:threads=auto:pass=1
Pass 2:
x264encopts subq=6:partitions=all:8x8dct:me=umh:frameref=5:bframes=3:b_pyramid:weight_b:threads=auto:pass=2
You will also have to specify bitrate and any sound settings, which I have not tried. But perhaps my silly settings will provoke someone who actually knows something about this to respond.
Joined: 11/11/2006
Posts: 1235
Location: United Kingdom
Important thing to remember: decimate does not work with threads > 1 or bframes > 0. Using decimate with either threads of bframes will cause choppiness and generally bad things. At least, this is the case in mencoder.. it's possible threads and decimate might work in another encoder somewhere.
Also, I strongly advise you not to use b-frames in AVIs.
Now to actually be helpful. The following is (probably) what I used for the last SM64 encode I did. (save as something.bat):
I think qcomp=1 and qp=20 on the first pass is what I did to fix my initial-blurring problem. At the very least qcomp is overwritten by 1st pass data, so I believe it makes very little difference whether it's in the command line or not. Also take note at the abnormally high bitrate. This is because decimate forces duplicate frames to 0 bytes, which x264 does not take into account for. As a result, for a game that runs at 20fps, the specified bitrate should be ~3 times what you're aiming for.
Where games are almost fully 60fps with no lag and very little blank transition screens, b-frames will probably be better than decimate. Here's what I used for Ecco 2:
Since decimate isn't used, I can afford to use as many threads as required to maximise speed :)
Both of the above batch files are based off of the ones in the MakingAVI Resource.
<adelikat> I am annoyed at my irc statements ending up in forums & sigs
Mencoder's manpage says that threads have "a slight penalty to compression quality" - can you actually see that penalty? I'm currently moving on a level where I can't touch the bitrate anymore (lower: looks crappy; higher: too big end result) and so was wondering whether this would be an option to at least try and speed up the whole process without destroying the quality achievements I got from already using bframes and such.
threads: This option allows to spawn threads to encode in parallel on multiple CPUs. You can manually select the number of threads to be created or, better, set threads=auto and let x264 detect how many CPUs are available and pick an appropriate number of threads. If you have a multi-processor machine, you should really consider using it as it can to increase encoding speed linearly with the number of CPU cores (about 94% per CPU core), with very little quality reduction (about 0.005dB for dual processor, about 0.01dB for a quad processor machine).
Barely noticable amount. This may have even improved with newer versions of mencoder.
<adelikat> I am annoyed at my irc statements ending up in forums & sigs
Not that I don't trust the official documentation on this, but the document you linked also stated that 7 was the maximum for subq, although the manpage states it's 9. I will try it out something, though. Thanks for the link :)
Important thing to remember: decimate does not work with threads > 1 or bframes > 0. Using decimate with either threads of bframes will cause choppiness and generally bad things. At least, this is the case in mencoder.. it's possible threads and decimate might work in another encoder somewhere.
Also, I strongly advise you not to use b-frames in AVIs.
Now to actually be helpful. The following is (probably) what I used for the last SM64 encode I did. (save as something.bat):
I think qcomp=1 and qp=20 on the first pass is what I did to fix my initial-blurring problem. At the very least qcomp is overwritten by 1st pass data, so I believe it makes very little difference whether it's in the command line or not. Also take note at the abnormally high bitrate. This is because decimate forces duplicate frames to 0 bytes, which x264 does not take into account for. As a result, for a game that runs at 20fps, the specified bitrate should be ~3 times what you're aiming for.
Where games are almost fully 60fps with no lag and very little blank transition screens, b-frames will probably be better than decimate. Here's what I used for Ecco 2:
Since decimate isn't used, I can afford to use as many threads as required to maximise speed :)
Both of the above batch files are based off of the ones in the MakingAVI Resource.
Works well if you add -vf scale=320:240 -sws 9 to the first pass. Thanks for the help.
Not that I don't trust the official documentation on this, but the document you linked also stated that 7 was the maximum for subq, although the manpage states it's 9. I will try it out something, though. Thanks for the link :)
Look at the difference in 7 and 9. ENORNMOUS encoding speed hit.
Some notes about playback-power-changing parameters...
1) I highly recommend against ever using more than 3 bframes in a row. CPU usage ramps up exponentially for playback (but do use b_pyramid if you use bframes).
2) If you do use 3 bframes, (because that's fine when you don't want to decimate) using bidirectional motion estimation (option is "bime") is pretty good at helping to save bits. but if you want to use that option, keep "frameref" at 3 or below (maybe 4 if the resolution is very small) because CPU usage ramps up exponentially exponentially. And with "mixed_refs" on, it's exponentially exponentially exponential. :)
Those above notes are really only valid when the resolution is above 256x224 and other small rez's used here. No point in making an encode at 320x240 that needs a quad-core 4GHz machine using hardware acceleration to run smoothly :P
No point in making an encode at 320x240 that needs a quad-core 4GHz machine using hardware acceleration to run smoothly :P
For some reason, the video gets so blurry it's nothing more than a joke if I don't downscale, but looks good if I do.
Not sure what that has to do with what I said. If you want to make a high res encode (say, 640x480 for example), you can't use a video filter that makes the first pass output to a different resolution. multiple pass encode need a few things consistent between the passes. input and output video size, and framerate are among them, as well as number of bframes used. Also a good rule of thumb is that bitrate should almost increase linearly with one of the dimensions. so a 640x480 encode should get about 2x the bitrate of a 320x240 encode. Even though it's 4x the area, the quants should end up about the same.
It makes the first second blurry, no matter how many times I run the nth pass. A bitrate of above 400 makes it over 4 MB/min. A bitrate of 700 solves the blur problem, but it's way too large..
Help? D:
