Encoding Tips for Mini-Size

What you need to encode faster and with quality

– CPU – the more cpu cores you have the faster you can encode, a dual-core CPU
is twice faster against encoding at single-core CPU, and quad-core CPU is 4 times faster against
encoding at single-core CPU, if you use a lot of avisynth filters (some simply call them filters)
other than resize filters then you might notice your multi-core CPU is not using all the cores
this is because avisynth is not designed yet to be multi-threaded, so when your using a lot of
avisynth filters your like encoding at single-core CPU only

– Settings – the higher the quality of the settings the longer/slower the encoding time
but for mini-size encoding its always advisable to set subme=10 (subpixel refinement or motion estimation)
and me=umh (motion estimation), trellis=2, aq-strength=0.6 for highest quality possible
you could get when re-encoding to small size, and if your in megui or staxrip its much easier
you just set preset=veryslow and tune=animation and that will automatically set all the settings of
x264 according to high quality anime compression, and as for encoding mode CRF is only 1-pass
so its faster than 2-pass encoding like average bitrate or filesize mode

– Resolution – the higher the output resolution the longer/slower the encoding time,
for example you encode 2 files with all same settings except that 1 file has output resolution of
576p (1024×576) while the other file has output resolution of 400p (704×400) you will then notice
that 400p is faster to encode than the 576p resolution, this is because part of encoding
is decoding too, in digital video when we say decoding it means playing the video,
but of course x264 wont prompt you with a media player and show you the video playback its
all happening behind the scenes to reserve more computing resources on the encoding process itself

– Software – dont believe a lot of people saying StaxRip is better, MeGUI is great, Handbrake is
awesome, Ripbot264 is super, etc this are all false because all of them uses thesame encoder
to output h264 videos and the name of this h264 encoder is x264, x264 is the best h264 encoder
out there at the moment and that wont change for a long time imo, and btw all those software like
StaxRip, MeGUI, Handbrake, Ripbot264, etc are considered “GUI Front Ends”

– Source – a source file is a video that you want to encode/convert to another format,
the higher the quality of the source file the higher the details youll preserved when you compress or re-encode
the video to small size, lossless video sources are the best like DVD (not DVD rips) and BluRay (not BluRay rips),
the original fansub releases are good sources too, never use rmvb/rm or even youtube videos as source because they
are already over compressed so they already loss too much details

– GPU – dont believe a lot of people saying CUDA encoding is better, yes CUDA based h264 encoders
are blazingly faster when encoding but compared to x264 output at preset=veryslow for example
the CUDA based encoders h264 output files are crap in quality
you can read more about GPU encoding woes here -> http://www.avidemux.org/admWiki/doku.php?id=tutorial:h.264#gpu_support
their are plans to port x264 to use the GPU too but so far no updates for it
and yes at the moment x264 is CPU based encoder, so you dont need a powerful GPU to encode fast
with x264 what you need is a multi-core CPU


x264 useful infos
1. qcomp (a x264 option/feature)
– lowers bitrate on high motion scenes
– increases bitrate on low motion scenes

2. qcomp+mbtree (a x264 option/feature)
– lowers bitrate on high motion block that means it will lower bitrate on parts of the scenes that are in high motion not the whole scene
– increases bitrate on high motion block that means it will higher bitrate on parts of the scenes that are in low motion not the whole scene
– so its recommended to always turn on mbtree do note that qcomp=1.0 will disable mbtree

3. frame counts
– the low motion the overall video the lower the frame count and thus lower the bitrate requirement or filesize overall
– the high motion the overall video the higher the frame count and thus higher the bitrate requirement or filesize overall

4. h264/x264 is bad at encoding dark scenes and/or dark areas
– thats why they invented AQ – Adaptive Quantization (a x264 feature/option) to re-allocate the bitrate more on dark areas/spots/scenes but AQ is not really that working efficiently for animation or cartoon videos
nevertheless its still always advisable to use AQ on animation or cartoon content to prevent other compression artifact that is called banding this is what banding looks like en.wikipedia.org/wiki/Colour_banding

5. Video Complexity/Compressibility – video can be called complex if it has more stuffs going on. like in a action movie for example it has lots of high motion throughout the video so its less compressible than lets say a drama tv show that has more low motion through out the video. for a more slightly technical explanation the movement in a low motion video will be easy to predict/estimate than the movement on a high motion video. the better the movement prediction or estimation the better the compressibility in terms of quality output. video objects on low motion video (like drama/moe anime) stays longer on screens so this means less bitrate needed overall to put them there and then put the background back. a high motion video (like action anime) will have lots of bits flying all over the screen from car crashes and explosions so that means more bitrate is needed and thus low compressibility and can be considered high complex video

you may wonder x264 feature especially qcomp increases bitrate on low motion scene so that means anime like K-On for example should be high in bitrate/filesize requirement especially when using CRF? the answer is because K-On has like 100% of each episode have low frame count so low frame count means not much bitrate/filesize needed for the overall video and K-On has less video complexity because its a low motion video so thats why if you notice when encoding anime video like K-on you could encode it at ridiculously high resolution with low filesize/bitrate but still will look good because its not just about low frame count (or having low/static motion scenes overall) its also about K-on anime having bright scenes overall and not much dark scenes

more reading: www.avidemux.org/admWiki/doku.php?id=tutorial:h.264

Encoding mini-size anime useful infos
1. Screens
– 4:3 videos or non-widescreen videos have square shape look when you view it
– 16:9 videos or widescreen videos have rectangular shape look when you view it
more reading: http://en.wikipedia.org/wiki/Aspect_ratio_(image)

2. Resolution
– SD means Standard Definition and this is usually 480p
preferred resize for mini-SD anime is 400p (704×400) for widescreen video and for non-widescreen video 384p (512×384) is advice resize
– HD means High Definition and this is usually equal or greater than 720p, but on the fansubbing world HD for widescreen starts at 1024×576 this is because some sources for HDTV are bad looking if they go with 720p and thus fansubbers resize it down to 576p
– preferred resize for mini-HD anime is 576p (1024×576) for widescreen video (on fansubbing terms)
more reading:
http://en.wikipedia.org/wiki/Blu-ray_Disc#Video

http://en.wikipedia.org/wiki/High-definition_video#Standard_high-definition_video_modes
– 288p is VCD resolution and we dont use this anymore as its too little on today’s standard desktop resolutions
we dont have desktop resolutions of 800×600 anymore so 288p is small and gets blurry in full screen mode viewing because of the big difference in resolution of your desktop (ex. 1366×768 or 768p) and the 288p video
– upscaling resizing up the video will not only make the video blurry but will loose more details when encoding to mini filesizes
– downscaling or resizing down the video of mini filesize encodes for example 720p resize to 400p will preserved more details and so low bitrate/filesize needs lower resolution to maintain a balance on bitrate allocation
but the downside of downscaling is that it will not be as sharp as the original source
simply because its lower resolution nevertheless if you want to preserved details more on mini size anime then downscaling is for you
– tutorial on resolution calculation -> Resolution Calculation
– the higher the resolution you set your output the longer the encoding time

3. Filesize
for 2-pass encoding of mini size anime:
– SD resolution – 60mb is appropriate in most cases
– HD resolution – 120mb is appropriate in most cases
for CRF encoding of mini size anime
– SD resolution – CRF value 24 to 27 is appropiate in most cases
– HD resoltution – CRF value of 28 to 31 is appropiate in most cases

4. Settings
– you may wonder why lots of fansubs have x264 settings meant for fast/low quality encoding this is because
they compensate it with higher bitrate or lower CRF value
– so for mini-size encoding to compensate with the low bitrate or higher CRF value its advisable to
use x264 settings that are higher or meant for slow/high quality encoding