View Full Version : bpf in Megui
gizmo27
29th July 2009, 10:11
Is there an option to touch to the bits*pixel/frame in Megui encoding with Xvid ?
In the aim to choose the correct resolution for an optimal encoding
Such as GK
tebasuna51
29th July 2009, 11:15
I think you are talking about the Qf (quality factor in Gspot), Bits/(Pixel*Frame) in MediaInfo.
In MeGUI you can select bitrate and resolution, I like select the bitrate for the desired resolution and Qf:
bitrate = Qf x fps x width x height = Qf x fps x width x (width / AspectRatio)
If you want select the resolucion for a desired Qf and bitrate:
width = sqr( (bitrate x AspectRatio) / (Qf x fps) )
gizmo27
29th July 2009, 11:32
why doesn't Megui caculate automatically the résolution starting from the bpf ? Such as GK did ?
nurbs
29th July 2009, 11:40
Because bpf is relatively useless since it doesn't take the complexity of the source into account. Testing the compressibility would be useful, but megui doesn't help you with that either. I guess most people just stick to a resolution and filesize no matter what or have their favorite resolution and to crf/cqp encodes and don't care about the size.
gizmo27
30th July 2009, 11:57
I know for x264 that output resolution really doesn't matter but it's not the case for xvid
so why the devs haven't made a little calculator which calculate the formule : BPF = bitrate/(output resolution*fps) ????????????
nurbs
31st July 2009, 17:43
It's the same for every codec, at least all of the mpeg codecs. Higher source complexity requires higher bpp, higher resolution requires less bpp.
gizmo27
3rd August 2009, 03:26
I don't think so
X264 encodes with better quality than Xvid
BPF for X264=0.25 and for Xvid=0.30
nurbs
3rd August 2009, 12:50
Yes, and MPEG1 will need an even higher bitrate to be transparent. That's not the issue here. You say that x264=0.25, but that's not true for every source. For a cartoon like the Simpsons you can probably get away with half or a third of that value without there being a visible difference while for a very grainy movie like 300 you'll probably need much more for it to look good. As I said how much you need so your encode looks good depends mainly on the source complexity (higher needs more bpf) and the resolution (higher need less bpf). Of course more efficient codecs need less bitrate to reach transparency all other things being equal but you can't just pick a random bpf value and expect the result to look good.
gizmo27
3rd August 2009, 13:15
I'm totally agree on what you said
;)
but...
the resolution is one of the more important aspects for the video quality
in that case why ignoring it ?
nurbs
3rd August 2009, 14:11
I'm not sure what you mean. Most people encode 1080p, 720p or somewhere around DVD resolutions. If you have a specific target filesize you are somewhat restricted in what resolutions you can use, say you can use a single layer DVD for your 720p movies, but getting a 1080p movie on there would probably not be the best idea if you want quality. So you have settled for a resolution somewhere around 720p and want to hit a specific bpf value to determine the framesize of your encode. It would be useless to use a little higher or lower resolution just so you hit a specific bpf value because you do not know what quality that bpf value gives you for one specific movie. So imagine you want a bpf of 0.25 so you choose a resolution a bit lower than 720p to get that, but what you don't know beforehand is that with the bitrate you use that encode would already be perfectly transparent at 720p or even higher resolutions. So what you are doing is destroying detail by downsizing. You could just randomly increase or decrease the resolution of your encodes for the same effect on quality on average as sticking to a specific bpf value.
My bottom line is that if you have a certain filesize restriction for whatever reason (CD, DVD, FAT32, idiotic scene rules) you just stick to one resolution that's genarally appropriate for it or you do a comp test and change the resolution accordingly. If you are not restricted by that you just pick whatever resolution you want and do a crf/cqp encode.
By the way, I reencode my blu-rays with x264 with --crf 22 at 720p. I checked a few files and bpf generally comes out somewhere between 0.15 and 0.2, but I have files close to 0.1 and above 0.4 as well. I know that this crf value will give me an acceptable visual quality. Under the assumption that the files between 0.15 and 0.2 are representative for the majority of files out there how exactly is a bpf value of 0.175 +/- 0.025 (+/- 15%) going to help you pick a resolution for your encode.
gizmo27
3rd August 2009, 17:46
I gonna give an example to be sure :
I've got a film : 2h lenght
I want to encode it with Xvid
max size = 700MB on a CD
Can I choose a 720p resolution ?
nurbs
3rd August 2009, 18:16
Probably not, unless it's a cartoon, an increadibly clean source or you use heavy denoising. That's my point, it depends on the source video.
Counterpoint:
http://mirror05.x264.nl/Dark/Flash/lowbitrateanime.html
Cartoon, 0.008 bpf. Doesn't look half bad. According to you one should use 30 times the bitrate because h.264 needs 0.25 bpf.
elguaxo
3rd August 2009, 18:38
@gizmo27:
this was posted in the MPEG-4 ASP section ;)
http://forum.doom9.org/showthread.php?p=841511#post841511
You can not base your decisions on this formula. The formula only gives you the false feeling that you know what you're doing when you're actually making a blind guess. This formula is more like a chant. Snakeoil.
Dark Shikari
3rd August 2009, 18:44
@gizmo27:
this was posted in the MPEG-4 ASP section ;)
http://forum.doom9.org/showthread.php?p=841511#post841511Indeed, a good post.
More technically, there are many issues with the bpp approach.
When you downscale a film by, say, a factor of 2 in each direction in order to encode it, you're effectively doing three things (this is in MPEG-4 ASP terms):
1. Increasing the macroblock size from 16x16 to 32x32, reducing overhead but also reducing the fine-grainedness of mode decisions and partition sizes.
2. Increasing the transform size from 8x8 to 16x16, compressing more efficiently in flat areas but much less so on sharp edges.
3. Lowpassing the bottom, right, and bottom right quadrants of the "virtual" 16x16 transform. This is where the bits are saved.
4. Reducing motion vector precision from halfpel to fullpel.
The sacrifices here, especially 4), are really going to hurt compression.
Now, not to say that there isn't a point at which downscaling is worth it; this point is just a lot higher quantizer than you think it is, probably around the time that a large portion of bits are spent on things that are easily encoded on a larger scale: macroblock modes, large partitions and their motion vectors, and DC coefficients.
gizmo27
20th August 2009, 17:46
Did you know that there a freeware which calculate, for avi, the bpf, choosing a resolution : it's named apsect
link : http://www.free-codecs.com/download/Aspect.htm (http://www.free-codecs.com/download/Aspect.htm)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.