Recommended bits / (pixel*frame) for H.264

[Kayaker]

Hi there.
When I used to encode to Xvid, I usually resize to get bits/(pixel*frame) from 0.220 to 0.300 depending the case.

Now that I'm starting to encode to H.264 ( codec x264 ) , I was wondering what are the "recommended values" for bits/(pixel*frame).

I know that there are no hard numbers, but something to start with. Maybe 0.100 to 0.150 ?

Also in Xvid I used to do always two passes.
As x264 is so slow (compared to Xvid) , I do just one pass in ABR to match de desidered final size.

The difference between one/two/three passes en x264 are as always have been ?

Thanks a lot.

[Sirber]

I used to do 0.07 to 0.10 for movies in RV10, since x264 is better, those number should be good enough for "normal people". ;)

[berrinam]

There's no point in doing two-pass if you aren't aiming at a specific filesize. Since you are looking for good bits/(pixel*frame) values, I suspect you don't care so much about final filesize, so a good approach is to use Constant Ratefactor (crf) mode. This does a one-pass quality mode. A crf value of around 18 is roughly equivalent to XviD's CQ2, so try values around 18-26

[Kayaker]

Actually berrinam, there are times I do care about size, and at these times what I do is resize down to get good bits/(pixel*frame) _AND_ my desidered final size.
But when I'm interested just in quality I suppose your suggestion applies.

I thought for that you must use a quantisizer.
What is the relation between what you have just said ( crf value ) and quantisizer value ?
It's the same I guess ?

[stax76]

BPF is not usable as quality measure, it's just most sources are withing a similar compresibility range. That being said quality is more interesting than BPF. I have no experience with x264, for XviD you would set a fixed file size and than adjust the image size until you reach 60% quality (which requires decoding with post processing). StaxRip doesn't even know/display BPF, it's pointless.

[Kayaker]

Ok stax.
Maybe I'm used to do this "resize until BPF between 0.220 and 0.260" because I used to did encoding with Gordin Knot.
But I'm changin now to MeGUI for x.264 ( I have still to try StaxRip sorry ;-)

You're right about the quality setting.

But how can I know in advanced how much to resize to match a desidered final size AND a desidered quality ? (without trial an error of course)
If I set quality I can't set size.

How MEGui/StaxRip or whatever encoding frontend do this automatic resizing process ? How can be know how much to downsize to achieve desidered quality ?

[berrinam]

The CRF value in x264 is similar to the CQ value in x264. However, for the same filesize, crf encodes are better quality than CQ encodes.

These are unrelated to XviD's CQ (quantiser) value.

[berrinam]

MeGUI has no such automated resizing process whatsoever. It leaves it entirely up to the user.

[Kayaker]

OK.
And then, How do you suggest to do the resize down process to achieve a desidered quality AND filesize with x.264 ?

Of course, When I don't care about filesize there's no problem.

[stax76]

It requires a compressibility check, StaxRip supports this for x264 similar like for DivX/XviD. For x264 --crf 18 is 100%, DivX/XviD it is quantizer 2. For DivX/XviD the comp check is very safe, you can use the same quantizer for any source and get similar results so you always know exactly what you will get quality wise. I have heard and backed that up by some quick and dirty test I made that the situation is not that easy for x264 but more trial and error, since I refuse h264 I can't help much here.

[Kayaker]

Hey Stax, I took a look at staxrip and it looks very good. Maybe a contestant to MEGui? ;-)
At home I'll put it into work and test it more thoroughly.


BTW, what did you mean with
since I refuse h264 ?
Could you please explain a little bit ?

[stax76]

Could you please explain a little bit?

IMHO there's much hype but little gain but I must admit I didn't invest enough effort so my statement is not really fair.

[DarkZell666]

IMHO there's much hype but little gain but I must admit I didn't invest enough effort so my statement is not really fair.


Far from it ;) All codec comparisons will tell you that h264 is so much more efficient than MPEG4-ASP. My eyes can also tell you : I get the same quality out of x264 when encoding anime @ 300kbps than XviD @ 650kbps ... pretty neat huh ? ;)

Back to subject :
I agree with sirber on this :

I used to do 0.07 to 0.10 for movies in RV10, since x264 is better, those number should be good enough for "normal people". I personnaly squashed episodes into 100MB (with 64kbps audio), obtaining 0.128bits/pixel (that's what AutoRV10 told me at the time ;))

[Tuesday]

Hi there.
When I used to encode to Xvid, I usually resize to get bits/(pixel*frame) from 0.220 to 0.300 depending the case.

Now that I'm starting to encode to H.264 ( codec x264 ) , I was wondering what are the "recommended values" for bits/(pixel*frame).

Thanks a lot.

Hey, i've been using x264 for quite a few rips recently. I aim for 1CD rips with ~190kbps 5.1AAC audio so bitrates are usually 500-600ish.

After lots of trial encoding i've found that a bits/(pixel*frame) of ~1.6 produces more or less artifact-free image.

Just for referance i always denoise with Pixiedust so the image is fairly clean by the time its encoded and in general i'm encoding modern, movie (live action) sources.

[stax76]

Far from it All codec comparisons will tell you that h264 is so much more efficient than MPEG4-ASP. My eyes can also tell you : I get the same quality out of x264 when encoding anime @ 300kbps than XviD @ 650kbps ... pretty neat huh ?

I did not came to that conclusion on each and every of my tests. Possibly I did something wrong, what I will do much likely shortly is to run another test but this time invest more time and maybe create a discussion. Was there a comparisons that uses quality mode with non animated source?

[Lil' Jer]

Far from it ;) All codec comparisons will tell you that h264 is so much more efficient than MPEG4-ASP. My eyes can also tell you : I get the same quality out of x264 when encoding anime @ 300kbps than XviD @ 650kbps ... pretty neat huh ? ;)

Wow so you can compress something to look just a crappy as a crap quality XviD encode but at half the bitrate. Wooo.

[Lil' Jer]

IMHO there's much hype but little gain but I must admit I didn't invest enough effort so my statement is not really fair.

In my personal experience if deblocking is disabled an H.264 encode looks quite a bit worse than an XviD encode at the same bitrate (much more ringing and blocks). If it weren't for in-loop deblocking H.264 wouldn't even be worth the trouble for the slow encoding times.

[foxyshadis]

Wow so you can compress something to look just a crappy as a crap quality XviD encode but at half the bitrate. Wooo.
Well, if you need to fit a few movies or a series on a memory card or two for a trip, you can't really go wrong with that. Or if you need to offer streaming videos or downloads online. (Both of which are h.264's, and h.263's, entire reason for existence. Top quality backups at a reasonable size are just a nice side benefit.)

[stax76]

Alright, tested two of my samples again with the most recent codec versions, this time x264 did by far best if you don't count speed, XviD did good and DivX failed badly on one of the samples.

[DarkZell666]

Wow so you can compress something to look just a crappy as a crap quality XviD encode but at half the bitrate. Wooo.
I'll ignore this pointless comment. You don't seem to know what you are talking about :)


In my personal experience if deblocking is disabled an H.264 encode looks quite a bit worse than an XviD encode at the same bitrate (much more ringing and blocks). If it weren't for in-loop deblocking H.264 wouldn't even be worth the trouble for the slow encoding times.


For sure, deblocking is a very efficient feature in h264 : removing ugly blocks and the ringing of the previously coded frame before coding the next one (well, sort of looks like it works that way), hence producing much better quality :)

x264 _could_ need some more optimisation when inloop is disabled. IIRC ND AVC can use automatic inloop adjustement. There is still more progress to be made ... :)

@stax :
lol, when was last time you tried x264 ? XD

Actually, is all this bit/pixel business depends so much on the source (anime vs. real-life) ...
It's just like asking for a bitrate anyway, obviously you always have the same number of pixels each second ... but how much they move around (thus generating many motion vectors and keyframes) can vary quite much ...

[stax76]

lol, when was last time you tried x264 ? XD

I recall only very few unmotivated comparisons maybe around revision 300-400 so it was about time, thanks for the motivation btw. ;)


But how can I know in advanced how much to resize to match a desidered final size AND a desidered quality ?

What I did with the latest unofficial StaxRip build which uses x264 revision 490: Used the HQ Slow profile, changed it to single pass quality 20 (--crf 20) (has this profile options that should only be used for multipass?). After that I made comp. check and a 2 pass encode with the file size I had from the crf encode. A high complexity sample (sailing) was at 75%, a normal sample was at 85%, file size was quite a bit smaller than XviD q3 and quality was better so 80% is a reasonable value for x264. To make a long story short you would do exactly the same as with XviD (multipass/comp. check is explained in my DVD guide) but you would use 80% quality for x264 instead of 60% that should be used for XviD.

Edit: I know now what was wrong with my previous comparisons, ffdshow defaults (post processing) completely mess up. The ffdshow setup should not ask for this and rather enable it for ASP and disable it for AVC. The XviD decoder has also bad defaults as it defaults to quantizer 4 and disables post processing. IMHO should rather be Q3 and PP enabled.

[xyloy]

Hi there.
When I used to encode to Xvid, I usually resize to get bits/(pixel*frame) from 0.220 to 0.300 depending the case.

Now that I'm starting to encode to H.264 ( codec x264 ) , I was wondering what are the "recommended values" for bits/(pixel*frame).

I know that there are no hard numbers, but something to start with. Maybe 0.100 to 0.150 ?

Also in Xvid I used to do always two passes.
As x264 is so slow (compared to Xvid) , I do just one pass in ABR to match de desidered final size.

The difference between one/two/three passes en x264 are as always have been ?

Thanks a lot.

AFAIK, x264's three pass mode is only when you have a wrong filesize, or a very very low bitrate and BPF.

I usually use two pass mode, with a BPF between 0.250 and 0.200. Below 0.200 the blockinees is to great for me(maybe I should try 2,2 deblocking..), but it's just my personnal opinion.

Are you using Exhaustive and no turbo ? x264 can be pretty fast and still "beat" VP7 or RV10.

Did you try with Automated 2 pass encoding mode(along with turbo), 5 - MultiQpel for Subpixel Refinement, and Hexagon(or MultiHex) for the M.E. Algorithm ?

[Lil' Jer]

I'll ignore this pointless comment. You don't seem to know what you are talking about :)

I've seen people brag about making great quality rips of anime at 300kbit/sec using x264. I've seen their encodes and they look like crap. If that's what you like, fine, but it still looks like crap. Same for the supposed 720p at 1200kbit or less crowd. I've seen their example clips and they usually flucuate from being massive blockfests to being oversmooth with hardly any fine detail. Hardly what I'd call good quality, but again if that's what you like...

[DarkZell666]

Hardly what I'd call good quality, but again if that's what you like...


It's a matter of vocabulary : at 300kbps I get something anyone can watch without saying "omg this is ugly" first shot. Actually it's much nicer than XviD @ 650kbps, I got the bitrate wrong, I should have said 800 ^^

Obviously "GOOD" quality would be something near DVD quality, which you obviously won't have @300kbps.

Fancy fitting 25 minutes into 60MB rather than 180MB at samey quality : I won't say no ;)

Back to the bit/pixel business : I've just finished an encode @ 300kbps (2-pass bitrate) with a final average ratefactor of 26 (so it's far from being ugly :)).
(w * h * fps) / (BR*1024)
(576*432*30)/(300*1024) = 0.04 bpp

[xyloy]

ratefactor of 26
0.04 bpp
Sorry, but it is ugly(in itself, no need to compare with DVD quality to see it) for me.. :/

[DarkZell666]

The final encode looked pretty much like the source (in fact, cleaner because I used hqdn3d() on it).

I give up, you guys must have pixel-precise sight :)

[foxyshadis]

Sorry, but it is ugly(in itself, no need to compare with DVD quality to see it) for me.. :/
Obviously nothing constuctive can come out of a discussion consisting of "that's ugly" "looks great to me". Everyone's got their own ideas of "good enough", especially when it comes to portables and other hardware, and it's a lot easier to experiment to find out where your tastes lie than listen to twenty people with twenty different opinions, unless you have a very specific need.

[xyloy]

That's true and was my feeling since the beginning.:rolleyes:

I give up, you guys must have pixel-precise sight
Sorry it was too expensive. :D ;)

edit: appart from playback conditions, we might also not be talking with the same kind of source in mind. I have in mind a "crystal quality"(so to speak) 720*576 DVD progressive(often cropped and resized with a W-Zoom of ~75%) source, but maybe DarkZell666's source was not so great(noisy and/or even badly encoded) ?

[DarkZell666]

but maybe DarkZell666's source was not so great(noisy and/or even badly encoded) ?
... indeed ;)

[Chainmax]

If I recall correctly, the last XviD CQM comparisons showed that Sharktooth's eqm_v3_ulr showed good results at a b/pp of ~0.12. When encoding Trigun, I found that with proper filtering a b/pp of ~0.11 gave great results. Some sources might require more, some less, but Sirber's recommendation of 0.1 seems like a good general purpose value.

[Maldark]

I've found with live action sources, on a 2-pass setting 0.1 is quite enough, I recently did Serenity with 192kbps 5.1 AAC and a 64kbps audio commentary, and made it fit on a single cd, it looks and sound quite fantastic.

I also do a fair bit of anime, and i'd say it's safe to push it below 0.1 if you have adequate cleaning of the source, which i'd highly reccommend for anime.

Hope this actually answers your question :P

[Sagittaire]

BPF does not mean anything because same bit for each pixel does not mean same quality for each pixel. In fact BPF is very bad measurement for video quality ...

1) Source is really important.
With same resolution and same video codec quality can be really good at 300 Kbps and very bad at 3000 Kbps.

2) Resolution is really important
bit/(pel^0.75*fps) is really better than bit/(pel*fps) if you want good reference for high resolution interval


|---------------|--------------------|--------------------|--------------------|
| | 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


3) Video codec is really important
people can say XviD done good quality at 640*272 and 700 Kbps ... why use x264 ??? Simply because with same source and bitrate x264 will make encoding at 720*576 ... ;-)


little example:
http://jfl1974.free.fr/upload/superman.mp4
http://jfl1974.free.fr/upload/XMenIII.mp4

video 1920*1088 at 2 mbps
BPF = 2 000 000 / (1920 *1088 * 25) = 0.04

Quality is not so bad for BPF at 0.04 ... isn't it ... lol

[DarkZell666]

downloading the clips, free.fr is just too slow these days ;)
See ya in 20 minutes for edit :)

EDIT : Lol late edit man, I fell asleep waiting for the DL to finish :D
The superman trailer looks brilliant oO if that's 0.04bpp I say w00t :p

I guess HD is something great to happen, making those macroblocs so small you can hardly see the blocking when it occurs ... great stuff =)

[xyloy]

Quality is not so bad for BPF at 0.04 ... isn't it ... lol
I've already seen such behavior.
BPF starts to mean nothing(I mean my 0.250 max 0.200 min dvd-rip "limits" for x264 do not give the quality they should give) in some situations.

example: for a 320*200(resized to mod16 resolution 304*208 for x264) 70 FPS video(don't worry about the extra-low resolution, it's a lossless video capture from DOSBox 0.65 :D Thanks to the Zipped Motion Block VFW codec v0.1 given with it).
If I apply a 0.300 BPF(quality should be perfect) to get an appropriate bitrate and use it with XviD 1.2, XviD gives q8 frames and a crappy encode, even with two passes. ;)

Same thing with HD material, the usual BPF values known to give good(or bad) video quality for a classic standard definition dvd-rip doesn't mean anything anymore.

[Kayaker]

Strange, but I've encoded several cartoon episodes with constant quality = 22 and there are points in the episode where the lines become a lot more blocky thtan the rest.
maybe a buggy x.264 version.

By the way, what is the "recommended latest more stable version" ?

I download shartooth's binaries once in a while but I don't want to hit some buggy daily version.
What would be the "latest recommended version" ?

BTW, MEGui developers, is there any chance to add some metrics (like the ones discussed above) so we can play and resize and see how metrics change ?

[DarkZell666]

By the way, what is the "recommended latest more stable version" ?



My answer to this is "The very latest version" lol.

Each revision fixes a bug or improves something. The latest builds show major speed improvements and a couple of bugs have been fixed since. Actually if you want a "stable" build, use builds that don't have any patches (see x264.nl for bob0r's builds for example).

[thuongshoo]

Hi ! I read all post but I still don't know at all.
I have a mpeg file, 352x240 .Assuming its quality is very good. I dont want to resize, want a orginal resolution. How bitrate should I use for converting it ? Please give me a formula which you like. Someone says " bit / pixel*framerate " but someon says otherwise. This make me misunserstand

(w * h * fps) / (BR*1024)
(576*432*30)/(300*1024) = 0.04 bpp

and

video 1920*1088 at 2 mbps
BPF = 2 000 000 / (1920 *1088 * 25) = 0.04

Thanks!

[xyloy]

it's (w*h*fps) / (Bitrate*1000) not 1024

To keep the original quality(and if you have no file size limit), I think you should use no formula, but a Constant Quality(20 or 22 for example) if you use x264, or Constant Quantizer(4 is quite good) if you use XviD

[thuongshoo]

thanks! I will try

[leowai]

it's (w*h*fps) / (Bitrate*1000) not 1024
Sorry, I'm not very clear with this. Is this implies that:
bpp =(w*h*fps) / (Bitrate*1000)
Will bpp increase along with bitrate increased? Or the other way round as shown in the formula above??

Second, what is the "units" in of "bpp"? It's called "bits-per-pixel" or it is short form of term "bits / (pixel*frame)" in this title?

Thanks for your comments and answers. :)


[edit] typo

[GodofaGap]

That formula is inversed. The correct one is bitrate*1000/(W*H*FPS). The unit is bit per pixel.

[xyloy]

Yup. I knew there was somethin' else wrong..
(' should get more sleep.. :D )

Will bpp increase a long with bitrate increased?
Yes it will. It also increase with less frames per second or less widht/height(but I'm not suggesting you to lower thoses two things ;) ).

[thuongshoo]

To keep the original quality(and if you have no file size limit), I think you should use no formula, but a Constant Quality(20 or 22 for example) if you use x264, or Constant Quantizer(4 is quite good) if you use XviD
I want to keep the orginal quality and resolution. Can I do 2 pass converting ?

[xyloy]

2 pass is very useful for quality when you are limited in filesize(or bandwith). Otherwise, Constant Quality(for x264) or Constant Quantizer(for XviD) should give you what you want.

[leowai]

That formula is inversed. The correct one is bitrate*1000/(W*H*FPS). The unit is bit per pixel.

Yes it will. It also increase with less frames per second or less widht/height(but I'm not suggesting you to lower thoses two things ;) ).
Thank you to clearify on this and thanks for the tips. ;)

So, in another words, following formula is a reference bitrate for variety of video size and bitrate.

Required_Bitrate_in_kbps = bpp * (w * h * fps) / 1000


Hopefully that this will help up newbies regarding to the proper bitrate to set for encoding. I used bpp=0.1 for real life encoding with x264 and I satisfied on the encoding result with that bpp.

Probably, just to remind that it's just a guidance bitrate. Don't that the only way to go with. i.e. Anime may goes for a lower bpp. :)

[Chainmax]

it's (w*h*fps) / (Bitrate*1000) not 1024

I think you're wrong. As far as I know, only HDD manufacturers and some codecs use the decimal interpretation of the kilo prefix. The correct use is the binary version, 1024.

[GodofaGap]

All even not-so-modern codecs use 1000 bits for 1 kbps. The only exceptions I know are VP6 and, I believe, DivX3. For x264 its certainly 1000.

[Chainmax]

Ok. In any case, my measurements take into account 1KB = 1024B so keep that in mind.

[thuongshoo]

oh! very interesting ! :D
I don't know what x264 use. My knowledge :
1kbs = 1000 bits / second
1KB = 1024 bytes
1 byte = 8 bits

I have tried to use constans quantizer with x264. Its value is 22. Bad! size of orginal source is 68MB and converted file is 91MB

[xyloy]

Try 26 or 24 ;)