Log in

View Full Version : Refining very-low bitrate 720p encoding options


gamebox
26th November 2014, 23:21
Hello all. :)

I am looking for ways to further refine/optimize my high-resolution low-bitrate encodes. The footage is real-life, lots of closeups of people/skin, room interiors present, some noise in dark areas originating from camera (CMOS?) sensor.

For 720p encodes at 3 Mbps I use:
bitdepth=8 cabac=1 ref=8 deblock=1:-1:-1 analyse=0x1:0 me=umh subme=10 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=24 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=0 chroma_qp_offset=0 threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=1 b_adapt=2 b_bias=0 direct=3 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=abr mbtree=1 bitrate=3000 ratetol=1.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.40 aq=1:1.00

Encodes usually end up having quantizer of 23-25, which is acceptable to me (25 as the last resort). The process is performed at about 1 fps on single-core Athlon64 3500+, which is approximately about 40 hours per encode, and I can accept that (but not much slower, not more than, say, 15-20%).

I have questions about these options and their influence on quality and speed:
- would merange of more than 24 improve quality, and how would it affect encoding speed (raising from 16 to 24 didn't seem to slow it more than, let's say, 10%)
- B-frames as references: strictly hierarchical. I've set it this way primarily because it seems to be "doing good" for standalone playability. Would "Non-strict" make video unplayable on blu-ray players, media players, set top boxes, my Radeon 4350 GPU, etc? Would it bring better visual quality?
- Is using more than 3 B-frames allowed by spec (in light of standalone support mostly), and would it bring quality increase? I've used mostly 2-3 B-frames on SD Xvid, and most of real-life scenes couldn't use more anyway; the picture was rarely "steady enough" to be encoded with more than 2 in a row.
- Trellis quantization: is "Always on" better than "Final macroblock only", and does it affect device compatibility? What does each one of them do (I have some understanding of the Trellis itself)?
- PSY-RD: 1, PSY-Trellis: 0. I'm very careful here - is it best to leave defaults on?
- Variance-AQ: Normal. Seems most important for me - is "Auto variance AQ" still considered "experimental", and does it bring standalone issues? Which way is the Auto-variance AQ different than Normal AQ; if I understand correctly, Normal chooses quantizers for each frame, and Auto goes deeper - manipulating them inside a frame, on a block-level? If it is so, is Auto applying more compression on low-contrast textures and less in high-detail areas?

Two biggest issues I have are with details in lower-contrast areas that sometimes get washed out and blocks made flat - for instance, with scenes shot without providing well enough lighting for people's faces and skin. For me, this issue seems hard to solve without compromising psycho-visual options in the entire clip, but those are essential at such low bitrates, as they keep details in "important" areas of the picture on account of the ones that draw less viewer's "attention".
The second issue is the camera-sensor noise. It exists in very dark (low-contrast) areas of image (on screen edges - peripheral parts of the scene, in distant furniture/carpetry/walls that are dark but not fully off-focus, etc). It is not much pronounced, and not highly noticable when watching the video, as well-lit objects draw more attention, but those are the areas of constant texture changes, and as such, I presume, require lots of "attention" from an encoder. Can x264's Noise Reduction help with that, or do I need some pre-filter? And, regarding that issue, I've noticed x264 encodes vary in bitrate somewhat less than xvid did - I always had an impression that H.263 quantization was somehow "simplyfing" the image and textures, so off-focus, low contrast scenery remains (almost) static through P and B frames. Is it really so, or just my impression?

Thanks a lot for your time! :)

Blue_MiSfit
27th November 2014, 03:45
3 Mbps isn't very low low bitrate for most 720p content ;)

1-2 Mbps is very low bitrate!

Just use the slowest preset you can, with 2 passes.

x264's noise reduction is simple and somewhat effective, but you'll probably better off doing some preflitering - especially to nuke out that pesky chroma noise that comes from CMOS sensors.

Another option is to subsample down to 960x540 or similar.

gamebox
27th November 2014, 05:28
@Blue_MiSfit
I thought 3 Mbps was low because I aim to keep image quality very close to original, without too visible blocking and image "simplification", and the content itself has decent amount of texture "movement" and changes, it is not documentary-like static. :) The source is professional blu-ray edit, with very high image quality, so original bitrate is probably many times higher than mine. I went for 2, 2.5 Mbps at first, but it proved to be too little - I was getting obvious "softening" and "bluring" in parts of image.

Camera noise is very luma too. If it was chroma-only I'd probably filter it out very simply, as I can tolerate rather high chroma noise reduction. Resolution subsampling is not an option.

Any help about those options I mentioned? Thanks in advance. :)

xooyoozoo
28th November 2014, 01:15
You seem to be trying to micromanage x264, but your reasons for doing so aren't particularly clear or compelling. I don't think most people here will be able to offer advice of much depth beyond "use a preset and tuning".

If you want to make a Bluray, make a Bluray. If you're encoding a collection of clips, use CRF (instead of ABR as indicated in your command line). If you don't like CRF's filesize uncertainty, use CRF with VBV controls to limit local max-bitrate. As you're concerned about compatibility, you should also force a conservative Level (3.1 or 4.0 for 720p).

would merange of more than 24 improve quality

Maybe, but you should probably just follow the presets.

B-frames as references: strictly hierarchical. I've set it this way primarily because it seems to be "doing good" for standalone playability. Would "Non-strict" make video unplayable on blu-ray players, media players, set top boxes, my Radeon 4350 GPU, etc? Would it bring better visual quality?

Without a clear understanding of your intended playback targets, you shouldn't artificially limit the encoder's abilities. Some early BluRay players might need a strict hierarchy. Everything else won't care.

But seriously, stick with presets/tunings.

Is using more than 3 B-frames allowed by spec (in light of standalone support mostly)

"Consecutive b-frames" is an encoder-specific setting and doesn't mean much in terms of the actual spec. The spec might limit something along the line of "max latency of pictures", but that number is much much larger than 3 or even 16.

Trellis quantization: is "Always on" better than "Final macroblock only", and does it affect device compatibility

Stick with presets.

PSY-RD: 1, PSY-Trellis: 0. I'm very careful here - is it best to leave defaults on?

At ~3 mbps for 720p, you don't need to worry about this (outside of setting preset and tuning, obviously). The defaults here become too aggressive when you're at lower bitrates.

Variance-AQ: Normal. Seems most important for me - is "Auto variance AQ" still considered "experimental", and does it bring standalone issues?

Yes. No. Stick with presets/tunings.

Camera noise is very luma too. If it was chroma-only I'd probably filter it out very simply, as I can tolerate rather high chroma noise reduction

Like mentioned, you might have to do some high quality prefiltering. If you don't want to deal with avisynth and setting up filtering there, the newest Handbrake GUI/CLI has NLMeans as a filtering option. It's slow, but it's probably the best "built-in" denoiser that you'll find.

gamebox
29th November 2014, 11:59
Thanks xooyoozoo. :)

I'll give a try to the noise prefilter in Handbrake, though it might affect encoding speed so much as to make it unbearable (though probably not as much as using similar noise prefilters for analog-TV captured footage on my previous SDRAM based Duron system years ago :) ).

How does adaptive quantization in X264 "behave" actually? If AutoVarianceAQ treats various parts of a single image differently, what does it actually do - applies more compression on high contrast textures or the opposite - on less pronounced ("background") details? Is "normal" AQ doing the same, only analyzing the complexity of different frames instead of working on parts of one frame? I remember, far ago, that adaptive quantization in Xvid didn't suit my taste, at least for analog TV captures (a bit "noisy" as I never applied too "agressive" noise filtering since I didn't want the image look like a photoshopped wannabe-model pic). In X264 AQ doesn't seem to bother me, though I've yet to do more tests - perhaps the difference this time comes from digital signal right from the start with clear difference in complexity between background and pronounced details.

SuLyMaN
29th November 2014, 12:23
change your rig :D

Sent from my HM 1SW using Tapatalk

gamebox
29th November 2014, 14:05
What's wrong with Athlon64 - a reliable, power saving (90nm+CnQ CPU, ultra fast DDR1 ram, Radeon4350, 22' LED FullHD DVI monitor) high picture quality, very low-end HTPC for my current H264 HD needs? :)

Seriously though, an upgrade is planned, but not just yet. :) My next rig will probably be something like A8 APU based quad, but I plan it in approximately 3 years to cope with high-quality HEVC demands. :) For the time being, Athlon 64 does the job - I process handful of videos at the moment. If things take a turn for the worse, I might buy a dual core for my platform, but will continue doing 1-thread only x264 encodes in order to squeeze out every single bit of quality from the encoder. :)

fedexx2
7th December 2014, 22:04
What's wrong with Athlon64 - a reliable, power saving (90nm+CnQ CPU, ultra fast DDR1 ram, Radeon4350, 22' LED FullHD DVI monitor) high picture quality, very low-end HTPC for my current H264 HD needs? :)

A modern quadcore CPU has about the same TDP of your old Atlhon 3500+ but it encodes 8-10 times faster.
I've tested your settings on my i5 cpu and got 9.50fps in 2nd pass (40W used by cpu only), and it will complete the encoding in about 4-6 hours instead of 40.
An old Athlon can be a good cpu for a low-end htpc (but there're better cpu at lower power too, like Amd AM1 platform: ~12W) but there's not much power saving, especially in encoding :p

gamebox
10th December 2014, 12:49
Cool, glad to know that, fedexx2. :)

The APUs I'm considering for my next upgrade are quads of course, and they are up to about 65W TDP. Expected per-core improvement in performance over Athlon is about 2x for current models, and given the number of cores total speedup should be between 6x and 8x. I consider it the least-acceptable level of performance for HEVC though (up to, say, 1080p), as I become more and more impressed with it's image quality and size reductions, and (honestly) H264 alone wouldn't motivate me to upgrade. However, for HEVC, I would also prefer a system with GPU decoding support - either right from the start or obtainable in (very) near future, and I'm trying to find out something about expected developments in that field at the moment.

Other semi-upgrade options (as AM1 you mentioned) aren't my goal as (despite faster encoding and lower consumption) the benefits of further energy-savings wouldn't cover the investment, and anything below quad would still be inappropriate for my use of HEVC in (near) future.