View Full Version : Encoding with h264 at low bitrates [bits/(pixel*frame): 0.09 - 0.11]
b66pak
10th February 2009, 21:06
Hi. I want to encode some tv shows with h264 (using megui) at low bitrates [bits/(pixel*frame): 0.09 - 0.11].
For those unfamiliar with this it means for example: 1/4 cd-r (175mb) for 42min (average) at 624x352@24fps or 1/8 cd-r (87.5mb) for 21min (average) at 624x352@24fps.
Can you suggest downsizing methods, custom matrix, megui profiles, your experience etc?
Thanks a lot.
_
Dark Shikari
10th February 2009, 21:09
0.1 is now considered low? (http://mirror05.x264.nl/Dark/force.php?file=./x264clips/BigBuckBunny.mkv)
On that note, BPP is a terrible measure of quality.
Atak_Snajpera
10th February 2009, 22:28
BTW . Who created this ridiculous value???
Esurnir
10th February 2009, 22:50
BTW . Who created this ridiculous value???
AutoGK?
D734
10th February 2009, 23:06
so around ~550kbps bitrate (AACplus2 suggested over mp3 to).
i've done some of those a while ago with SGA (for fun and learning experience)
i don't use megui anymore but when i did sharktooth (http://forum.doom9.org/showthread.php?t=139765) profiles worked good with settings.
dxva-hd-insane (even tho your doing sd encodes) would be a good idea as it doesn't do 16 ref frames (like unrestricted insane) which can double encoding time (also as i hear 5-6 is the most you normally need unless anime/cartoon).
some people dont like to do me=tesa (satd exaustive) because it slows things down a bit but you may want that over umh (multi hex) considering the low bitrate your doing.
also note that for the encodes, re-encoding a 720p x264 to 624x352 x264 will give better results then just re-encoding a 624x352 xvid to 624x352 x264
Atak_Snajpera
10th February 2009, 23:26
also note that for the encodes, re-encoding a 720p x264 to 624x352 x264 will give better results then just re-encoding a 624x352 xvid to 624x352 x264
Oh my god! you've just discovered america :)
D734
10th February 2009, 23:58
also note that for the encodes, re-encoding a 720p x264 to 624x352 x264 will give better results then just re-encoding a 624x352 xvid to 624x352 x264Oh my god! you've just discovered america :)
lol, its a no brainer but you would actually be surprised how many dont know that.
smok3
11th February 2009, 00:46
AutoGK?
first seen in the original Gordian Knot i belive?
Sagekilla
11th February 2009, 01:33
Ignoring the fact that bpp is meaningless, ~500 kbps (bpp = 0.1 for 624x352 @ 24 fps) would give you very good quality. Hell, my own DVD rips @ 848x480 average around 1 mbps for the video. Extrapolating backwards, that would make a bitrate of around ~500 kbps also good for your video. (Note: Bitrate scaling isn't linear to resolution. Doubling the resolution usually requires less than twice the bitrate, and halving the resolution might not always require half the bitrate).
Stop using pointless metrics like bpp and just stick with crf mode. crf = 20 - 22 should give you very good quality at low bitrates.
ajp_anton
11th February 2009, 07:49
Note: Bitrate scaling isn't linear to resolution. Doubling the resolution usually requires less than twice the bitrate, and halving the resolution might not always require half the bitrateIf double res needs less than double bitrate, then half res needs more than half bitrate (at least when "half res" = original res, halved from the doubled one).
DJ Bobo
11th February 2009, 12:14
I don't know what's wrong with taking bpp as an approximating quality measure. I'm aware that different videos may require different bpp, but it's a fast "rule of thumb" for those who don't have time to do compressiblity tests and stuff, and need to hit a specific size target.
I would agree that going below 0.1bpp is not healthy and that it's considered a low bitrate. Did you ever see a blu-ray disc with less than 5GB for the main movie?? I didn't think so.
Even 720p rips hit the 4GB mark easily, which results in about 0.25bpp.
But, b66pak, I would still go with light bicubic resizing (default avisynth setting) instead of bilinear, bilinear washes too much for my taste. Make sure to filter the noise well though.
@Sagekilla: what's up with you guys following that "upsizing trend"?! encode anamorphic, let the player handle the upsizing! MPC HC can do bicubic resizing, I don't know what's wrong with that! just wasting bitrate for nothing IMHO...
nurbs
11th February 2009, 13:48
I use crf 22 for my rips and bpp vary greatly. I looked at some movies on my harddrive now (blu-ray rips, 720p or equivalent number of pixels) and the bpp values are between 0.1 and 0.35. Assuming that crf gives a more or less constant quality difference between source and encode that makes bpp pretty useless, because while you can say most movies above ~0.3 bpp will look good it doesn't tell you anything about the quality of rips below that value and there are still cases where this is not enough. Also with higher resolutions you can generally get away with less bitrate so you'd have to take that also into account.
Sharktooth
11th February 2009, 14:21
how many times i have to say BPP is a completely useless metric?
leave it alone. use CRF instead or do a compression test if you need to hit a filesize.
BPP is useless. period.
DJ Bobo
11th February 2009, 16:58
As said, I'm well aware of the limitations of the bpp index, but in times of "time is money", you can get away with it as an approximation for the quality you should be expecting.
Anything below 0.1bpp should look like crap
Anything between 0.1 and 0.2bpp should look good
Anything above 0.2bpp should look very good
- providing right filtering! -
And as they say, exceptions confirm the rule :p
No doubt that a compressibility test is the best method, I'm not arguing about that, don't worry, we're on the same side ;)
OLD SCHOOL ISN'T THAT BAD GUYS! :rolleyes:
_DW_
11th February 2009, 17:09
how many times i have to say BPP is a completely useless metric?
leave it alone. use CRF instead or do a compression test if you need to hit a filesize.
BPP is useless. period.
Given that bpp is crap how useful is a compression test? I run it just about every time I encode something but for some reason I'm never happy with the 50%. I always bump it up to 60 to 80%.
Got a link to where I can study what it actually does?
DJ Bobo
11th February 2009, 17:21
@ DW
I'll try to explain the compressibility test with DivX terms: 100% uses the lowest possible quantizer, which is 2 in the case of DivX. 50% equates Quantizer 4. 75% Quantizer 3. You seem to dislike anything higher than Quantizer 3.
Quantizers are a bit different in the h.264 world, but they follow the same logic.
Sagekilla
11th February 2009, 18:11
As said, I'm well aware of the limitations of the bpp index, but in times of "time is money", you can get away with it as an approximation for the quality you should be expecting.
No doubt that a compressibility test is the best method, I'm not arguing about that, don't worry, we're on the same side ;)
Or you can be smart and not waste -any- time by just using crf. crf 20 will give about the same quality every time you use it. Only one run needed. No need to do a compressibility pass, or relying on on bpp to tell you what size you need.
It's not a bash against "old school methods." It's just being smart. Like everyone said, and as you acknowledged, a bpp of X will look great on one video but horrid on another. But, crf of Y on one video will look just as good on one video as it does on every other.
Save your time, stop doing guess work, and use crf.
Edit: Yes I know I can just encode anamorphic video. No longer a concern of 720x480 or 848x480 though. 720p rips of Blu-ray all the way ;)
DJ Bobo
11th February 2009, 19:17
@ Sagekilla
Am I missing something here? I thought CRF-encoding is for people that don't care about final file size?!
The point behind bpp is to get a quick approximation of what the resolution should be for a given target file size (I don't know if you got this specific point right)
poisondeathray
11th February 2009, 19:37
Back to the original topic/theme regarding tips for lower bitrate encoding:
-Depending on the source / desired goal, preprocessing with some denoising filters might help lower bitrate requirements
-Use higher quality x264 encoder settings
-I would disable psy rd /psy trellis, they tend to "eat up" too much bitrate , and ringing artifacts are more readily visible at low bitrates
It will take you a few minutes to test out various settings on a short representative clips
b66pak
11th February 2009, 22:31
Hi. I was given the BPP value so we can quickly get the bitrate for a desired resolution@framerate and NOT as a quality measure...
Example:
-for 1920x1080@24fps BPP 0.1 we talking about 4977kb/s
-for 1280x720@24fps BPP 0.1 ... 2212kb/s
-for 720x480@24fps BPP 0.1 ... 830kb/s
-for 720x576@25fps BPP 0.1 ... 1037kb/s
-for 640x368@30fps BPP 0.1 ... 706kb/s
-for 640x368@24fps BPP 0.1 ... 566kb/s
-for 624x352@30fps BPP 0.1 ... 660kb/s
-for 624x352@24fps BPP 0.1 ... 527kb/s
you get the ideea...
thank you Sagekilla! i didn't know that bitrate scaling isn't linear to resolution...
Dark Shikari provided (on the first reply) a 10min cartoon (1920X1080@24fps) at a stunning BPP 0.03!!!
now lets talk about avisynth resizing for low bitrates...
DJ Bobo kindly suggested soft bicubic resize...what about neutral or sharp resizing?...pro and contra...
_
Ranguvar
13th February 2009, 21:44
I like sharp bicubic for keeping a sharp look without hurting the encoder too much. YMMV, as every video is different. Do a compression test (Google). Encode a small segment with different resizers. Experience is everything.
Sagekilla
13th February 2009, 22:33
Each one to the right is sharper and eats up some more bits to encode (using CRF, or under bitrate you suffer a higher quality penalty)
Spline16 < Spline36 < Spline64
I generally stick with Spline36. If you play around with Bicubic though (b and c), you can adjust the sharpness of it to your personal taste. I usually do Blu-ray -> 720p rips so Spline36 is more then enough for me. Again, YMMV and try it yourself! What I think looks good could be considered excessive by someone else, or not enough by another person.
Edit: One last note, x264 can give -extremely- good quality even at stupidly low bitrates. So doing something like 656x368 rips @ 500 - 700 kbps will still look good.
Sagittaire
14th February 2009, 09:38
Example:
-for 1920x1080@24fps BPP 0.1 we talking about 4977kb/s
-for 1280x720@24fps BPP 0.1 ... 2212kb/s
-for 720x480@24fps BPP 0.1 ... 830kb/s
-for 720x576@25fps BPP 0.1 ... 1037kb/s
-for 640x368@30fps BPP 0.1 ... 706kb/s
-for 640x368@24fps BPP 0.1 ... 566kb/s
-for 624x352@30fps BPP 0.1 ... 660kb/s
-for 624x352@24fps BPP 0.1 ... 527kb/s
you get the ideea...
_
Unfortunaly entropy don't work like that. For same source higher resolution mean lower entropy. For same source overall quantizer is constant with Bitrate / ( W x H x Fps ) ^ N with N = [0.5 - 0.75]. That's mean that at 1920x1080@24fps, BPP 0.1, 4977kb/s you have really lower overall quantizer than 624x352@24fps, BPP 0.1, 527kb/s. And I speak only about quantizer. Compression artefact size are scaling with size block (blocking, ringing ...) and in HVS term higher resolution mean lower relative size for compression artefact. In fact for HVS N will be certainely really lower in most case for real perceptual quality by pixel.
For this reason it will be difficult to compare really different codec like MPEG4 ASP and MPEG4 AVC: if optimal result for your eyes for XviD is 720*400 at 2 Mbps then x264 will certainely produce better result for 720*400 at 2 Mbps. Anyway same source at 1024*576 at 2 Mbps will produce optimal result with x264 with really higher quality than 720*400 at 2 Mbps with XviD or x264.
ajp_anton
14th February 2009, 15:24
quantizer is constant with Bitrate / ( W x H x Fps ) ^ N with N = [0.5 - 0.75].I may have no idea what I'm getting into here, but should the "fps" really be inside that parenthesis (and get ^'d to N)?
Sagittaire
14th February 2009, 16:00
|---------------|--------------------|--------------------|--------------------|
| | files sizes | bit/(pel*fps) | bit/(pel^0.75*fps) |
|---------------|--------------------|--------------------|--------------------|
| q2 1024*576 | 3389 Kbps | 0.239 bpf | 6.63 sci |
| q2 720*400 | 1890 Kbps | 0.273 bpf | 6.33 sci |
| q2 512*288 | 1143 Kbps | 0.323 bpf | 6.32 sci |
| q2 384*208 | 714 Kbps | 0.372 bpf | 6.26 sci |
|---------------|--------------------|--------------------|--------------------|
| q3 1024*576 | 2067 Kbps | 0.146 bpf | 4.04 sci |
| q3 720*400 | 1188 Kbps | 0.172 bpf | 3.98 sci |
| q3 512*288 | 735 Kbps | 0.207 bpf | 4.07 sci |
| q3 384*208 | 462 Kbps | 0.241 bpf | 4.05 sci |
|---------------|--------------------|--------------------|--------------------|
| q4 1024*576 | 1492 Kbps | 0.105 bpf | 2.92 sci |
| q4 720*400 | 875 Kbps | 0.127 bpf | 2.93 sci |
| q4 512*288 | 548 Kbps | 0.155 bpf | 3.03 sci |
| q4 384*208 | 344 Kbps | 0.179 bpf | 3.02 sci |
|---------------|--------------------|--------------------|--------------------|
source 1280*720
resize with lanczos
encoding with XviD
|----------------|--------------------|--------------------|--------------------|
| | files sizes | bit/(pel*fps) | bit/(pel^0.75*fps) |
|----------------|--------------------|--------------------|--------------------|
| q20 1280*720 | 4026 Kbps | 0.182 bpf | 5.63 sci |
| q20 720*400 | 1728 Kbps | 0.250 bpf | 5.79 sci |
| q20 512*288 | 1057 Kbps | 0.299 bpf | 5.85 sci |
| q20 384*208 | 661 Kbps | 0.345 bpf | 5.80 sci |
|----------------|--------------------|--------------------|--------------------|
| q25 1280*720 | 2074 Kbps | 0.094 bpf | 2.90 sci |
| q25 720*400 | 924 Kbps | 0.134 bpf | 3.09 sci |
| q25 512*288 | 573 Kbps | 0.162 bpf | 3.17 sci |
| q25 384*208 | 363 Kbps | 0.189 bpf | 3.18 sci |
|----------------|--------------------|--------------------|--------------------|
| q30 1280*720 | 1023 Kbps | 0.046 bpf | 1.43 sci |
| q30 720*400 | 460 Kbps | 0.067 bpf | 1.54 sci |
| q30 512*288 | 286 Kbps | 0.081 bpf | 1.58 sci |
| q30 384*208 | 181 Kbps | 0.094 bpf | 1.59 sci |
|----------------|--------------------|--------------------|--------------------|
source 1920*1088
resize with lanczos
encoding with x264
IgorC
14th February 2009, 19:36
so around ~550kbps bitrate (AACplus2 suggested over mp3 to).
It implies that audio has 50 kbps as generally audio track has 10% of video bitrate or 9% of total bitrate.
For me this bitrate distribution had always a good balance between audio and video quality. (speaking of 2 channel,stereo)
HE-AAC2 (PS) is only recommended for bitrates up to 36 kbps. For 50 kbps HE-AAC1.
b66pak
14th February 2009, 23:14
i made a test with all the resizers that i know using a 10 min tv show sample (1280x720@24fps)...i was using constant quality mode at 22...
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x1:0x111 / me=umh / subme=7 / psy_rd=1.0:0.0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=0 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=1 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=crf / crf=22.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / vbv_maxrate=10000 / vbv_bufsize=10000 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00
results:
tv.show.sample.10min.sharp.point.cqm.22.mkv 48,267,030 bpp 0.116 639.90 kb/s SSIM Mean Y:0.9752983 PSNR Mean Y:43.908 U:49.263 V:49.480 Avg:45.069 Global:44.365
PointResize(624,352) # Point (Sharp) #source 1280x720@23.976
tv.show.sample.10min.sharp.lanczos4.cqm.22.mkv 41,992,763 bpp 0.101 556.38 kb/s SSIM Mean Y:0.9803237 PSNR Mean Y:44.711 U:49.383 V:49.631 Avg:45.788 Global:45.144
Lanczos4Resize(624,352) # Lanczos4 (Sharp) #source 1280x720@23.976
tv.show.sample.10min.sharp.lanczos.cqm.22.mkv 41,953,020 bpp 0.101 555.85 kb/s SSIM Mean Y:0.9806010 PSNR Mean Y:44.769 U:49.381 V:49.626 Avg:45.838 Global:45.197
LanczosResize(624,352) # Lanczos (Sharp) #source 1280x720@23.976
tv.show.sample.10min.sharp.blackman.cqm.22.mkv 41,751,270 bpp 0.100 553.16 kb/s SSIM Mean Y:0.9810045 PSNR Mean Y:44.859 U:49.416 V:49.666 Avg:45.920 Global:45.282
BlackmanResize(624,352,taps=4) # Blackman (Sharp) #source 1280x720@23.976
tv.show.sample.10min.sharp.spline64.cqm.22.mkv 41,746,432 bpp 0.100 553.09 kb/s SSIM Mean Y:0.9809477 PSNR Mean Y:44.843 U:49.417 V:49.661 Avg:45.907 Global:45.268
Spline64Resize(624,352) # Spline64 (Sharp) #source 1280x720@23.976
tv.show.sample.10min.neutral.spline36.cfr.22.mkv 41,735,038 bpp 0.100 552.95 kb/s SSIM Mean Y:0.9810253 PSNR Mean Y:44.859 U:49.416 V:49.665 Avg:45.921 Global:45.283
Spline36Resize(624,352) # Spline36 (Neutral) #source 1280x720@23.976
tv.show.sample.10min.sharp.bicubic.cqm.22.mkv 41,703,237 bpp 0.100 552.52 kb/s SSIM Mean Y:0.9811394 PSNR Mean Y:44.878 U:49.382 V:49.634 Avg:45.931 Global:45.292
BicubicResize(624,352,0,0.75) # Bicubic (Sharp) #source 1280x720@23.976
tv.show.sample.10min.neutral.spline16.cqm.22.mkv 41,365,207 bpp 0.099 548.02 kb/s SSIM Mean Y:0.9818558 PSNR Mean Y:45.038 U:49.461 V:49.710 Avg:46.080 Global:45.450
Spline16Resize(624,352) # Spline16 (Neutral) #source 1280x720@23.976
tv.show.sample.10min.neutral.bicubic.cqm.22.mkv 41,311,213 bpp 0.099 547.31 kb/s SSIM Mean Y:0.9819993 PSNR Mean Y:45.080 U:49.494 V:49.745 Avg:46.121 Global:45.494
BicubicResize(624,352,0,0.5) # Bicubic (Neutral) #source 1280x720@23.976
tv.show.sample.10min.soft.bicubic.cqm.22.mkv 40,426,374 bpp 0.097 535.53 kb/s SSIM Mean Y:0.9841569 PSNR Mean Y:45.608 U:49.725 V:49.989 Avg:46.605 Global:45.998
BicubicResize(624,352,0.333,0.333) # Bicubic (Soft) #source 1280x720@23.976
tv.show.sample.10min.soft.bilinear.cqm.22.mkv 40,259,584 bpp 0.096 533.28 kb/s SSIM Mean Y:0.9845548 PSNR Mean Y:45.726 U:49.786 V:50.055 Avg:46.714 Global:46.115
BilinearResize(624,352) # Bilinear (Soft) #source 1280x720@23.976
tv.show.sample.10min.neutral.gauss.cqm.22.mkv 39,755,442 bpp 0.095 526.60 kb/s SSIM Mean Y:0.9856732 PSNR Mean Y:46.051 U:49.928 V:50.201 Avg:47.011 Global:46.436
GaussResize(624,352) # Gauss (Neutral) #source 1280x720@23.976
so for same source at same crf (22) i had:
PointResize (Sharp) > 48,267,030
Lanczos4Resize (Sharp) > 41,992,763
LanczosResize (Sharp) > 41,953,020
BlackmanResize (Sharp) > 41,751,270
Spline64Resize (Sharp) > 41,746,432
Spline36Resize (Neutral) > 41,735,038
BicubicResize(0,0.75) (Sharp) > 41,703,237
Spline16Resize (Neutral) > 41,365,207
BicubicResize(0,0.5) (Neutral) > 41,311,213
BicubicResize(0.333,0.333) (Soft) > 40,426,374
BilinearResize (Soft) > 40,259,584
GaussResize (Neutral) > 39,755,442
and a SSIM beyond 0.98 (with the exception of PointResize)...
_
b66pak
14th February 2009, 23:37
regarding "doubling the resolution usually requires less than twice the bitrate" i made a test using a 10 min tv show sample (1280x720@24fps)...i was using Spline36 (Neutral) and constant quality mode at 22...
Encoding settings: cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x1:0x111 / me=umh / subme=7 / psy_rd=1.0:0.0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=0 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=1 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=crf / crf=22.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / vbv_maxrate=10000 / vbv_bufsize=10000 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00
results:
tv.show.sample.10min.neutral.spline36.cqm.22.272p.mkv 24,300,289 bpp 0.097 320.85 kb/s SSIM Mean Y:0.9818042 PSNR Mean Y:44.447 U:48.736 V:48.852 Avg:45.454 Global:44.772
Spline36Resize(480,272) # Spline36 (Neutral) #source 1280x720@23.976
tv.show.sample.10min.neutral.spline36.cqm.22.352p.mkv 41,735,038 bpp 0.100 552.95 kb/s SSIM Mean Y:0.9810253 PSNR Mean Y:44.859 U:49.416 V:49.665 Avg:45.921 Global:45.283
Spline36Resize(624,352) # Spline36 (Neutral) #source 1280x720@23.976
tv.show.sample.10min.neutral.spline36.cqm.22.400p.mkv 57,106,432 bpp 0.105 757.55 kb/s SSIM Mean Y:0.9805054 PSNR Mean Y:45.065 U:49.754 V:50.029 Avg:46.146 Global:45.519
Spline36Resize(720,400) # Spline36 (Neutral) #source 1280x720@23.976
tv.show.sample.10min.neutral.spline36.cqm.22.480p.mkv 87,703,920 bpp 0.114 1164.91 kb/s SSIM Mean Y:0.9803663 PSNR Mean Y:45.422 U:50.223 V:50.553 Avg:46.517 Global:45.878
Spline36Resize(848,480) # Spline36 (Neutral) #source 1280x720@23.976
so considering 480x272 as base i get:
for 168% increase in resolution > 172% increase in bit rate
for 221% increase in resolution > 236% increase in bit rate
for 312% increase in resolution > 362% increase in bit rate
_
Ranguvar
15th February 2009, 07:55
The resolution/bitrate data is interesting, but metrics are nowhere near sufficient for deciding quality.
Sagittaire
15th February 2009, 09:57
so considering 480x272 as base i get:
for 168% increase in resolution > 172% increase in bit rate
for 221% increase in resolution > 236% increase in bit rate
for 312% increase in resolution > 362% increase in bit rate
_
Your result are false ... simply because crf mode doesn't mean constant overall quantizer like show OPSNR. Increase resolution imply always lower BPP for same source.
b66pak
15th February 2009, 18:54
@ Sagittaire the results are not false...you could say the interpretation is wrong...it will be nice to see other opinions too...
_
Sagekilla
15th February 2009, 19:30
What he means is that crf mode isn't the best way to show that there's a nonlinear curve regarding bitrate vs resolution. If you managed to encode each source perfectly so they had the -exact- same PSNR (Also, encoding without AQ and psy-rd since they would skew the results) you would see that something like 720p wouldn't require exactly double the bitrate as 640x360.
As you increase resolution, you're increasing the amount of redundancy present in each frame. Generally speaking, unless your source image is something extremely contrived like a black and white checkerboard pattern (this never happens in real footage) you will always require less bitrate then usual for an increase in resolution.
JohannesL
15th February 2009, 20:16
What he means is that crf mode isn't the best way to show that there's a nonlinear curve regarding bitrate vs resolution. If you managed to encode each source perfectly so they had the -exact- same PSNR (Also, encoding without AQ and psy-rd since they would skew the results) you would see that something like 720p wouldn't require exactly double the bitrate as 640x360.
As you increase resolution, you're increasing the amount of redundancy present in each frame. Generally speaking, unless your source image is something extremely contrived like a black and white checkerboard pattern (this never happens in real footage) you will always require less bitrate then usual for an increase in resolution.
720p is four times the area of 640x360, but for the reasons you stated, the bitrate difference is usually around 2x.
Sagekilla
15th February 2009, 21:50
You're doubling the resolution in both dimensions though. 50x50 = 2500, 100x100 = 10000. 100x100 is "four times bigger" than 50x50, when looking at it area wise. You need to look at the linear increase in resolution, not the square increase. 1280x720 has four times the square area as 640x360. But it only has twice the linear increase in resolution: (1280x720) ^ 0.5 vs (640x360) ^ 0.5.
Another example: Let's say you have a video that has a resolution of 1920x1080 and another with 3840x1080. Does the 3840x1080 video have twice the resolution? No, it has twice the area (measured in pixels^2). But only 41% more linear resolution.
b66pak
16th February 2009, 20:43
@Sagekilla and @JohannesL
common practice contradicts you: average 100min 640x360 is encoded to 700mb (1 cd-r) and average 100min 1280x720 in encoded to 4.4gb (1 dvd-r) witch is 6+ bigger...
for "720p is four times the area of 640x360, but for the reasons you stated, the bitrate difference is usually around 2x" it would be like 640x360 to 1 cd-r and 1280x720 to 2 cd-r or 1280x720 to 1 dvd-r and 640x360 to 1/2 dvd-r witch is unseen...
i consider that bigger resolution have more fine details (and not redundancy - or may be only for cartoons!) so it should be harder to encode!
not using aq and psy-rd give false positive results...files are lower but the fine details are ruined (textures of faces, dark scenes)...
for this line how do you improve the results (meaning lower the size of the final encode)?
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x1:0x111 / me=umh / subme=7 / psy_rd=1.0:0.0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=0 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=1 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=crf / crf=22.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / vbv_maxrate=10000 / vbv_bufsize=10000 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00
nurbs
16th February 2009, 21:02
for this line how do you improve the results (meaning lower the size of the final encode)?
Use a higher crf for the encode to get a lower size. If you do a crf encode and use slower (higher quality) options the filesize will not necessarily be lower, you'll only get better quality per bitrate.
Sagekilla
16th February 2009, 21:10
@b66pak: That's with constant bitrate. Constant bitrate != constant quality. If you read anything I said, it no longer applies when you're doing that. If you keep quality constant, and compare size vs resolution, it won't be perfectly linear. I don't encode with 2-pass, I use crf instead. My 480p rips average 1500 - 1800 kbps @ crf 19, and my 720p rips average 3500 - 4000 kbps. How do you explain that? If we look at your square increase in resolution (2.67 times), the bitrate only went up by 2.27 times.
To increase quality, enable 8x8dct for one. No reason for it not to be on. Likewise, b-pyramid could help. And why are you using VBV with 1-pass CRF? That's just a bad idea IIRC.
b66pak
16th February 2009, 21:30
did you read this?
i made a test using a 10 min tv show sample (1280x720@24fps)...i was using Spline36 (Neutral) and constant quality mode at 22...
Encoding settings: cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x1:0x111 / me=umh / subme=7 / psy_rd=1.0:0.0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=0 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=1 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=crf / crf=22.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / vbv_maxrate=10000 / vbv_bufsize=10000 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00
results:
tv.show.sample.10min.neutral.spline36.cqm.22.272p.mkv 24,300,289 bpp 0.097 320.85 kb/s SSIM Mean Y:0.9818042 PSNR Mean Y:44.447 U:48.736 V:48.852 Avg:45.454 Global:44.772
Spline36Resize(480,272) # Spline36 (Neutral) #source 1280x720@23.976
tv.show.sample.10min.neutral.spline36.cqm.22.352p.mkv 41,735,038 bpp 0.100 552.95 kb/s SSIM Mean Y:0.9810253 PSNR Mean Y:44.859 U:49.416 V:49.665 Avg:45.921 Global:45.283
Spline36Resize(624,352) # Spline36 (Neutral) #source 1280x720@23.976
tv.show.sample.10min.neutral.spline36.cqm.22.400p.mkv 57,106,432 bpp 0.105 757.55 kb/s SSIM Mean Y:0.9805054 PSNR Mean Y:45.065 U:49.754 V:50.029 Avg:46.146 Global:45.519
Spline36Resize(720,400) # Spline36 (Neutral) #source 1280x720@23.976
tv.show.sample.10min.neutral.spline36.cqm.22.480p.mkv 87,703,920 bpp 0.114 1164.91 kb/s SSIM Mean Y:0.9803663 PSNR Mean Y:45.422 U:50.223 V:50.553 Avg:46.517 Global:45.878
Spline36Resize(848,480) # Spline36 (Neutral) #source 1280x720@23.976
so considering 480x272 as base i get:
for 168% increase in resolution > 172% increase in bit rate
for 221% increase in resolution > 236% increase in bit rate
for 312% increase in resolution > 362% increase in bit rate
_
i was using crf too (crf=22.0)! it is lower because i wanted lower files. what is wrong with my line? how can i improve it so i can reproduce your results?
would you like to post your line?
_
P.S. for me 480p means 848X480
b66pak
16th February 2009, 22:51
To increase quality, enable 8x8dct for one. No reason for it not to be on. Likewise, b-pyramid could help. And why are you using VBV with 1-pass CRF? That's just a bad idea IIRC.
the encoding is for a standalone which don't support any of this settings...
_
Sagittaire
17th February 2009, 10:01
did you read this?
i was using crf too (crf=22.0)! it is lower because i wanted lower files. what is wrong with my line? how can i improve it so i can reproduce your results?
would you like to post your line?
_
P.S. for me 480p means 848X480
One more time your result are false. crf mode is not constant quantizer mode (absolute constant quality). Make encoding with qp mode.
common practice contradicts you: average 100min 640x360 is encoded to 700mb (1 cd-r) and average 100min 1280x720 in encoded to 4.4gb (1 dvd-r) witch is 6+ bigger...
Well don't prove anything. Moreover HVS quality for each pixel is by far better for 720p on 4.4 Gb. You can't compare like that. Here real comparison at constant quantizer.
|---------------|--------------------|--------------------|--------------------|
| | files sizes | bit/(pel*fps) | bit/(pel^0.75*fps) |
|---------------|--------------------|--------------------|--------------------|
| q2 1024*576 | 3389 Kbps | 0.239 bpf | 6.63 sci |
| q2 720*400 | 1890 Kbps | 0.273 bpf | 6.33 sci |
| q2 512*288 | 1143 Kbps | 0.323 bpf | 6.32 sci |
| q2 384*208 | 714 Kbps | 0.372 bpf | 6.26 sci |
|---------------|--------------------|--------------------|--------------------|
| q3 1024*576 | 2067 Kbps | 0.146 bpf | 4.04 sci |
| q3 720*400 | 1188 Kbps | 0.172 bpf | 3.98 sci |
| q3 512*288 | 735 Kbps | 0.207 bpf | 4.07 sci |
| q3 384*208 | 462 Kbps | 0.241 bpf | 4.05 sci |
|---------------|--------------------|--------------------|--------------------|
| q4 1024*576 | 1492 Kbps | 0.105 bpf | 2.92 sci |
| q4 720*400 | 875 Kbps | 0.127 bpf | 2.93 sci |
| q4 512*288 | 548 Kbps | 0.155 bpf | 3.03 sci |
| q4 384*208 | 344 Kbps | 0.179 bpf | 3.02 sci |
|---------------|--------------------|--------------------|--------------------|
source 1280*720
resize with lanczos
encoding with XviD
|----------------|--------------------|--------------------|--------------------|
| | files sizes | bit/(pel*fps) | bit/(pel^0.75*fps) |
|----------------|--------------------|--------------------|--------------------|
| q20 1280*720 | 4026 Kbps | 0.182 bpf | 5.63 sci |
| q20 720*400 | 1728 Kbps | 0.250 bpf | 5.79 sci |
| q20 512*288 | 1057 Kbps | 0.299 bpf | 5.85 sci |
| q20 384*208 | 661 Kbps | 0.345 bpf | 5.80 sci |
|----------------|--------------------|--------------------|--------------------|
| q25 1280*720 | 2074 Kbps | 0.094 bpf | 2.90 sci |
| q25 720*400 | 924 Kbps | 0.134 bpf | 3.09 sci |
| q25 512*288 | 573 Kbps | 0.162 bpf | 3.17 sci |
| q25 384*208 | 363 Kbps | 0.189 bpf | 3.18 sci |
|----------------|--------------------|--------------------|--------------------|
| q30 1280*720 | 1023 Kbps | 0.046 bpf | 1.43 sci |
| q30 720*400 | 460 Kbps | 0.067 bpf | 1.54 sci |
| q30 512*288 | 286 Kbps | 0.081 bpf | 1.58 sci |
| q30 384*208 | 181 Kbps | 0.094 bpf | 1.59 sci |
|----------------|--------------------|--------------------|--------------------|
source 1920*1088
resize with lanczos
encoding with x264
Dark Shikari
17th February 2009, 10:15
One more time your result are false. crf mode is not constant quantizer mode (absolute constant quality).But constant quantizer definitely isn't constant quality.
One of the issues of comparing various resolutions is whether you are:
a) Comparing quality for two different resolutions shown at two different display sizes.
or
b) Comparing quality for two different resolutions, both of which are upscaled to the same display size on playback.
moviefan
17th February 2009, 23:15
With reference to the 2nd post in this thread, Dark Shikari, could you please post your command line for encoding Big Buck Bunny at such a low bitrate? I calculated it quickly and it must be somewhere around 1.5 Mbps right? This is amazing, except for one or two slightly blocky fades, extremely good quality!
Dark Shikari
17th February 2009, 23:31
With reference to the 2nd post in this thread, Dark Shikari, could you please post your command line for encoding Big Buck Bunny at such a low bitrate? I calculated it quickly and it must be somewhere around 1.5 Mbps right? This is amazing, except for one or two slightly blocky fades, extremely good quality!The blocky fades are because I was using RDRC, an experimental ratecontrol mode that... among other things... sort of fails on fades. It'd probably be a bit worse overall but better on the fades if you used a normal build.
I basically just maxed the x264 settings and used a bit of psy-trellis for sharpness.
moviefan
17th February 2009, 23:40
Hm, I'm currently trying to encode an animated video which is very clean (animated should be...) at about 4 Mbps (1080p, no black bars). It looks pretty good, but there are some scenes where, for some reason, a part of the picture (not randomly, it depends on the content of that part) looks blocky, not many details, totally crappy. And I am at 4 Mbps as I said and that's why I am asking for your settings... I read that it is not recommended to use --weightb for animated content. Why is that and are there other things to consider? Also, can I use psy trellis without psy-rdo? Is psy-rdo recommended?
photoguy123
19th February 2009, 17:39
a nonlinear curve...
Is this anything like jumbo shrimp? :)
vmrsss
23rd February 2009, 23:53
For same source overall quantizer is constant with Bitrate / ( W x H x Fps ) ^ N with N = [0.5 - 0.75].
So, what is the correct formula:
bitrate/(W * H * F)^N
as above, or
bitrate/((W * H)^N * F)
as in Sagittaire's tables?
vmrsss
1st March 2009, 15:04
hi. anybody with the answer to the question above?
Sagittaire
2nd March 2009, 10:58
it's bitrate/(W * H * F)^N ... Anyway if you have constant Fps you can use bitrate/((W * H)^N * F).
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.