Good resolutions and bitrates for x264 encodes

[microchip8]

Hi,

Maybe I ask silly questions for you encoding guru's, but since I'm new to encoding I wanted to give it a try.

I want to encode DVDs to x264+aac quadro (4 channels) using MEncoder on Linux. Now my questions are which resolutions shall I choose when scaling down and which video bitrate. I do not want to scale down that much since I know that it removes detail so I figured that a resolution of 608x400 or 608x384 is good enough for preserving details when scaling down. Are these resolutions good enough or should I choose different ones?

The other question is about bitrate. I want to do a 2-pass encoding with a bitrate of 1000 kbps. Will this bitrate be enough for the above resolutions even for high-motion bright movies? Can I use a lower bitrate with x264 without hurting quality (eg, without having block artifacts or some other weird effects)

The x264 options I use are...

- 3 frame references
- mixed frame references
- umh motion estimation
- 4 b-frames
- 8x8dct
- b-frames motion refinement
- chroma motion estimation
- trellis=1
- adaptive b-frames placement
- weighted prediction in b-frames
- auto insertion decision for b-frames
- CABAC
- Subpel refinement of 5
- Deblock with default values
- Direct prediction set to auto
- DCT Decimate disabled
- Fast P-Frame skipping disabled
- Partitions: p8x8,b8x8,i8x8,i4x4

I also read somewhere that more than 6 or 7 frame references can hurt quality in live-action movies, but a higher value of frame references can help in anime. Is this true?

Thanks in advance

[PuzZLeR]

which resolutions shall I choose when scaling down and which video bitrate. I do not want to scale down that much since I know that it removes detail so I figured that a resolution of 608x400 or 608x384 is good enough for preserving details when scaling down. Are these resolutions good enough or should I choose different ones?Depends what you want the encodes for and the true indicator of bitrate and resolution is BPP (bits per pixel). If you're only going to be watching on a small screen, you may as well make them even lower and save the bitrate. If you want bigger screen viewing don't downsize. Try and keep the resolution as close as possible to the original. I would either use anamorphic encoding or the lowest I'd go using square pixels is 640x480 for 4:3 DvD content, or 640x352 for 16:9 DvD content.I want to do a 2-pass encoding with a bitrate of 1000 kbps. Will this bitrate be enough for the above resolutions even for high-motion bright movies?Not really. You can get away with this bitrate for lower complexity stuff (sitcoms, news shows, etc.) but action flicks? Don't think so. Then again, since every flick is different you will never know. The best way to determine the true bitrate demands is by experimenting with CRF. 2-pass bitrate encoding only guarantees you a size, not a qualiity level.Can I use a lower bitrate with x264 without hurting quality (eg, without having block artifacts or some other weird effects)When encoding to H.264 from an MPEG-2 source, no matter how good or how bad the higher bitrate was, you will always lose quality lowering bitrate and will develop a higher risk of artifacts and such.I also read somewhere that more than 6 or 7 frame references can hurt quality in live-action movies, but a higher value of frame references can help in anime. Is this true?No it shouldn't hurt quality at all, only encoding and decoding speeds. The more MRFs you use the (much) slower the encode and, as well, some decoders/playback devices will begin to whine over a certain amount of these MRFs (but that will develop better over time). Usually more than 5 is overkill. Yes, anime and toons do typically ask for more - keep it at absolute max 10 (but 6-8 is probably more realistic). The standard of H.264 allows for 16, but I have yet to see a use for that many...yet.

I don't find anything wrong with your settings, although I'm no expert on what's optimal here and I'm sure the next person may have better points to make there, but before you go all out, I would recommend you try some CRF options to determine a feel for the right quality.

[microchip8]

hmmm, I do know that you always get a loss in quality when encoding but what I'm trying to do here is keep a reasonable file size (between 1 and 1.2-1.4 GB) but still preserving as much as possible quality for this file size. Then these encodes will be squeezed onto a DVD disc and I want to have 3-4 of them on 1 disc. I don't think CRF will be a good option for this as it has a unpredictable effect on the final file size.

I've heard that the H.264 codec is much more efficient in compressibility when compared to Xvid or DivX and you can get away with lower bitrates and still end up with the same or better quality when compared to a Xvid encode with a slightly higher bitrate.

I've done a 2-pass encode of Terminator 2 (Extended Edition) with a bitrate of 1150 kbps @ 608x384 (25 FPS) and the quality is really awesome. I did not notice any block artifacts in high-motion scenes but I'm also not that kind of guy who inspects every high-motion scene frame-by-frame just to see if there are any artifacts in it... During normal playback of this encode, it really looks good in high-motion scenes (or maybe my eyes are not tuned to see blocks in high-motion scenes)

[Sagittaire]

hmmm, I do know that you always get a loss in quality when encoding but what I'm trying to do here is keep a reasonable file size (between 1 and 1.2-1.4 GB) but still preserving as much as possible quality for this file size. Then these encodes will be squeezed onto a DVD disc and I want to have 3-4 of them on 1 disc. I don't think CRF will be a good option for this as it has a unpredictable effect on the final file size.

I've heard that the H.264 codec is much more efficient in compressibility when compared to Xvid or DivX and you can get away with lower bitrates and still end up with the same or better quality when compared to a Xvid encode with a slightly higher bitrate.

I've done a 2-pass encode of Terminator 2 (Extended Edition) with a bitrate of 1150 kbps @ 608x384 (25 FPS) and the quality is really awesome. I did not notice any block artifacts in high-motion scenes but I'm also not that kind of guy who inspects every high-motion scene frame-by-frame just to see if there are any artifacts in it... During normal playback of this encode, it really looks good in high-motion scenes (or maybe my eyes are not tuned to see blocks in high-motion scenes)

Well if you want more than 1 Gb for each movie you must choose very higher resolution and better quality for audio:
- Make encoding at 720*400 for movie
- Make encoding at 192 Kbps with 5.1 AAC

608*384 is really not a good resolution here. x264 can and must use very higher resolution than xvid with the same bitrate.

[microchip8]

Well if you want more than 1 Gb for each movie you must choose very higher resolution and better quality for audio:
- Make encoding at 720*400 for movie
- Make encoding at 192 Kbps with 5.1 AAC

608*384 is really not a good resolution here. x264 can and must use very higher resolution than xvid with the same bitrate.

I wish I could, but when I go above 608x400 the encoding speed drops a lot. Even at 608x400 I get speeds of ~8-10 FPS (depending on the movie). If I choose a higher resolution, this will drop even further. I'm using a single-core AMD Athlon 64 4000+ (2.4 GHz) with 1 GB DDR400 RAM, and I'm not really prepared to wait 12 or more hours for a 2-pass encode

EDIT: a further question, what are good SSIM value?

[Tack]

Do you really rip that many movies that encoding time is an issue? I'd much rather leave my computer encoding overnight (or over a weekend) and get the best possible quality. You only encode once, but you watch the thing more than once (presumably).

As to your other question, I'd say a good SSIM is anything over 0.95, and 0.98 or better should be very nearly transparent. But these metrics are no substitute for your own eyeballs.

[Dark Shikari]

The x264 options I use are...

- 3 frame references
- mixed frame references
- umh motion estimation
- 4 b-frames
- 8x8dct
- b-frames motion refinement
- chroma motion estimation
- trellis=1
- adaptive b-frames placement
- weighted prediction in b-frames
- auto insertion decision for b-frames
- CABAC
- Subpel refinement of 5
- Deblock with default values
- Direct prediction set to auto
- DCT Decimate disabled
- Fast P-Frame skipping disabled
- Partitions: p8x8,b8x8,i8x8,i4x4

I also read somewhere that more than 6 or 7 frame references can hurt quality in live-action movies, but a higher value of frame references can help in anime. Is this true?

Thanks in advance
More --refs never hurts, basically. More than about 4-6 is useless in live action but helps in anime and cartoons.

For your settings, I would suggest upping --subme to 6 (RDO is a HUGE help) and upping --trellis to 2 (its worth the speed loss). If you think that's too slow, lower --me to hex; my tests I ran recently show only a 1.7% quality loss over --me umh, compared to a 3.2% quality loss for using --trellis 1 instead of --trellis 2.

[microchip8]

Do you really rip that many movies that encoding time is an issue? I'd much rather leave my computer encoding overnight (or over a weekend) and get the best possible quality. You only encode once, but you watch the thing more than once (presumably).

I plan to ;)

As to your other question, I'd say a good SSIM is anything over 0.95, and 0.98 or better should be very nearly transparent. But these metrics are no substitute for your own eyeballs.

Thanks, I'm always getting SSIM values between 0.965 and 0.978

[microchip8]

More --refs never hurts, basically. More than about 4-6 is useless in live action but helps in anime and cartoons.

For your settings, I would suggest upping --subme to 6 (RDO is a HUGE help) and upping --trellis to 2 (its worth the speed loss). If you think that's too slow, lower --me to hex; my tests I ran recently show only a 1.7% quality loss over --me umh, compared to a 3.2% quality loss for using --trellis 1 instead of --trellis 2.

Thanks, I'll give them a try

[microchip8]

On a further note, as I understand it correctly there are 2 subme 6 modes. One with and one without RDO for B-Frames. Regarding trellis, --trellis 2 is only available for subme >= 6, right? it doesn't work with subme of 5 or lower?

[Dark Shikari]

On a further note, as I understand it correctly there are 2 subme 6 modes. One with and one without RDO for B-Frames. Regarding trellis, --trellis 2 is only available for subme >= 6, right? it doesn't work with subme of 5 or lower?
Well yeah, make sure to use --b-rdo also, that's a very effective option in my experience.

[microchip8]

Well yeah, make sure to use --b-rdo also, that's a very effective option in my experience.

OK, so I'm doing a small test here on The War Of The Worlds DVD in 2-pass mode @ 950 kbps with a 608x384 resolution, with the following MEncoder options on Linux. I'm encoding only the first chapter of the first DVD title

mencoder dvd://1 -dvd-device /dev/dvd -chapter 1-2 -vf crop=720:544:0:16,scale=608:384:0:0 -sws 10 -nosound -ovc x264 -x264encopts pass=1:qp=18:me=umh:nodct_decimate:nointerlaced:8x8dct:nofast_pskip:brdo:trellis=2:mixed_refs:noglobal_header:bime:keyint=250:keyint_min=25:frameref=3:bframes=4:b_adapt:b_pyramid:weight_b:direct_pred=auto:subq=6:chroma_me:cabac:deblock -passlogfile $HOME/h264.log -o /dev/null

Second pass options are the same, except I replace the qp=18 option with bitrate=950

so far, the encoding FPS rate has dropped to 4.27 FPS. I also noticed that every time I encode a DVD in 2-pass mode, the first pass is somehow slower than the second pass. I'll upload the file somewhere if you want to expect it or so :D

[Dark Shikari]

OK, so I'm doing a small test here on The War Of The Worlds DVD in 2-pass mode @ 950 kbps with a 608x384 resolution, with the following MEncoder options on Linux. I'm encoding only the first chapter of the first DVD title

mencoder dvd://1 -dvd-device /dev/dvd -chapter 1-2 -vf crop=720:544:0:16,scale=608:384:0:0 -sws 10 -nosound -ovc x264 -x264encopts pass=1:qp=18:me=umh:nodct_decimate:nointerlaced:8x8dct:nofast_pskip:brdo:trellis=2:mixed_refs:noglobal_header:bime:keyint=250:keyint_min=25:frameref=3:bframes=4:b_adapt:b_pyramid:weight_b:direct_pred=auto:subq=6:chroma_me:cabac:deblock -passlogfile $HOME/h264.log -o /dev/null

Second pass options are the same, except I replace the qp=18 option with bitrate=950

so far, the encoding FPS rate has dropped to 4.27 FPS. I also noticed that every time I encode a DVD in 2-pass mode, the first pass is somehow slower than the second pass. I'll upload the file somewhere if you want to expect it or so :D
Don't use QP mode; there's no point. CRF is much more effective in basically every way.

Also note that on your first pass you can use much less intensive settings; --me hex or dia, and --subme 3-5 instead of 6. This won't affect bitrate accuracy much and will save you a lot of time.

Of course I just prefer to use CRF onepass.

[microchip8]

Don't use QP mode; there's no point. CRF is much more effective in basically every way.

Also note that on your first pass you can use much less intensive settings; --me hex or dia, and --subme 3-5 instead of 6. This won't affect bitrate accuracy much and will save you a lot of time.

Of course I just prefer to use CRF onepass.

Won't this lower the quality somehow or is --me and --subme more related to compression than quality? I remember to read in the MPlayer documentation that if you use lower values for the first pass this will affect the values in the log file generated by the first pass thus there will be some effect on the second pass

[Dark Shikari]

Won't this lower the quality somehow or is --me and --subme more related to compression than quality? I remember to read in the MPlayer documentation that if you use lower values for the first pass this will affect the values in the log file generated by the first pass thus there will be some effect on the second pass
It won't affect it much at all. At least not noticably.

Yes, if you want exactly the bitrate you specify in your second pass, it might not be the best idea, but for most people it doesn't matter whether its 950.00 or 951.34.

[microchip8]

It won't affect it much at all. At least not noticably.

Yes, if you want exactly the bitrate you specify in your second pass, it might not be the best idea, but for most people it doesn't matter whether its 950.00 or 951.34.

Oki... regarding CRF, which value should I use. Is CRF better quality at higher values when compared to QP at a lower value, eg CRF=20 equals QP=18 in terms of quality. Since CRF is better than QP, I assume a somewhat higher value will not only give you a almost equal quality compared to QP but also a smaller file size

Also which setting should I disable for the first pass and which should I leave on?

[Dark Shikari]

Oki... regarding CRF, which value should I use. Is CRF better quality at higher values when compared to QP at a lower value, eg CRF=20 equals QP=18 in terms of quality. Since CRF is better than QP, I assume a somewhat higher value will not only give you a almost equal quality compared to QP but also a smaller file size

Also which setting should I disable for the first pass and which should I leave on?
CRF is roughly equivalent to QP.

The difference is not huge; its main advantage is that it can intelligently tweak QP when necessary rather than fixing QP at a specific value. This can give a slight quality advantage, enough to make it more worthwhile than QP.

[microchip8]

Thanks for the answers so far.... I'll be back, haha!

[microchip8]

Ok, so I went through the manual page of MPlayer and I saw there's a turbo option for x264 available which has 3 modes and I quote the documentation....

0 - disabled (default)
1 - Reduce subq, frameref and disable some inter-macroblock partition analysis modes.
2 - Reduce subq and frameref to 1, use a diamond ME search and disable all partition analysis modes.

Level 1 can increase first pass speed up to 2x with no change in the global PSNR of the final pass compared to a full quality first pass. Level 2 can increase first pass speed up to 4x with about +/- 0.05dB change in the global PSNR of the final pass compared to a full quality first pass.

Now, I see level 2 can decrease the PSNR to about 0.05dB for the final pass. How bad is that? Is 0.05dB even noticeable by a human?

[nm]

Now, I see level 2 can decrease the PSNR to about 0.05dB for the final pass. How worse is that? Is 0.05dB even noticeable by a human?
It can be noticeable given two different encoders (especially if one is optimized for PSNR and the other for something else), but in this comparison the final pass is encoded with the same encoder and the same settings, so there is not much difference. Just encode a couple of clips and see for yourself.

[Manao]

Instead of thinking in terms of difference of PSNR at same bitrate, it's easier to think of difference of bitrates at same PSNR. A difference of 0.05dB roughly translates into a different of 1% of bitrate.

So a 0.05dB loss is equivalent to a 1% bitrate increase. It's now up to you to say whether 1% bitrate is much or not.

[microchip8]

Well, I did a small test here on the first chapter of a DVD, one time with the turbo=1 the other time with the turbo=2 option. I used these options...

mencoder dvd://1 -dvd-device /dev/dvd -chapter 1-2 -vf crop=720:544:0:16,scale=608:384:0:0 -sws 10 -aid 128 -channels 4 -oac faac -faacopts mpeg=4:br=140:object=2 -ovc x264 -x264encopts pass=1:bitrate=1050:turbo=1:me=umh:me_range=25:nodct_decimate:nointerlaced:8x8dct:threads=auto:nofast_pskip:nobrdo:trellis=1:partitions=p8x8,b8x8,i8x8,i4x4:mixed_refs:bime:frameref=4:bframes=6:b_adapt:b_pyramid:weight_b:direct_pred=auto:subq=6:chroma_me:ssim:cabac:deblock -passlogfile $HOME/h264.log -o /dev/null

The only thing I changed was turbo=1 to turbo=2 and it came with the following SSIM values

turbo=1
SSIM: 0.9705248

turbo=2
SSIM: 0.9705228

there's a very small decrease in the SSIM when using the turbo=2 option

[foxyshadis]

Not only very small, but well below the margin of error. SSIM isn't anywhere near exact enough to assign meaning to five or six digits of precision. Better to visually compare them when they're that close, but you may find that you can't tell the difference visually either! That's why Megui and all the rest of the guis use the commandline equivalent of turbo=2.