View Full Version : mencoder & x264, the same stuff?
zhangtrinity
30th August 2005, 22:06
Sorry about my begainer's question, but that really hunts me down.
1. Looked through the forum, and I guess mencoder & x264 are quite similar, somethimes they can replace eachother on different platform. Am I right? I have a PowerBook, and right now use FFmpegX 0.0.9t with mencoder.
2. Is there anybody could tell me, with a giving VOB file size, like 720x544, and duration of movie, can I figure out how big is the final mp4 file? Since I don't care about how big my file should be, It becomes a wired problem.
Please don't be annoyed by these simple questions, it'll really help me out.
jellysandwich
30th August 2005, 22:49
1) Mencoder is for XviD, lavc, Snow and AVC encoding, while x264 is only for AVC encoding. If you're going to encode using AVC, you should use x264 since it's updated more often, leaving mencoder slightly behind.
2) How big will the final MP4 file be? That's up to you. It takes into account many things such as cropping, resizing, encoding agnostic used, how much bitrate you give it, and audio. All of that is decided by YOU (but of course, there are programs out there to help you).
I hope that helps.
js
bond
30th August 2005, 23:00
1. Looked through the forum, and I guess mencoder & x264 are quite similar, somethimes they can replace eachother on different platform. Am I right? I have a PowerBook, and right now use FFmpegX 0.0.9t with mencoder. x264 is an avc encoder, it can be used in different tools, of which the most popular ones are the x264 commandline tool, x264vfw, mencoder or ffmpeg
there is also a x264 plugin for quicktime 7 for mac available here (http://forum.doom9.org/showthread.php?t=99321)
2. Is there anybody could tell me, with a giving VOB file size, like 720x544, and duration of movie, can I figure out how big is the final mp4 file? Since I don't care about how big my file should be, It becomes a wired problem.you mean "big" regarding filesize or "big" regarding the picture size?
if your input is 720x544 you can of course also get an output size of 720x544 produced by x264
regarding filesize you can influence this yourself by setting a specific bitrate in x264
zhangtrinity
30th August 2005, 23:18
Thanks million for both of you. So as bond said, it sounds like x264 is used by Mencoder for AVC encoding job. If it's the case, I feel lots of better.
About the file size, still have some doubts.
1.Get the info from my forum searching, when I do the encoding, the final movie's picture size shouldn't exceed the origal (like if the mpeg-2 is 720x544, the mp4 one's best shot is 720x544)
2.But since I don't care about the GB of the file, I guess there must be peek bitrates for a giving movie. Over that peek, the extra is a waste, and that's what I try to avoid.
So are there some goody tools may be helpful?
IRMA1024
31st August 2005, 14:37
for Question #2 :
the size of movie (filesize) is not directly depend on the screen size (video resolution) for example both 720x544 or 800x600 can have same filesize and same bitrate but different quality...
when encoding, the source is the best quality, because each encoding process is decreasing quality (lossy), so it is better not larger than source resolution, because it is waste of bitrate.
the encoded movie quality depend on three things (in my opinion)
1.movie resolution and duration
2.encoder and encoding settings
3.bitrate you give to encoder
- larger resolution or longer duration need more bitrate
- the better encoder or settings give higher quality but longer encoding time
- more bitrate you gave, resulting in larger filesize...
some hint :
for DVD source, ~100minutes duration, 720x480 resolution, encoded with x264 with 700-800kbps bitrate and 720x480res is enough, usually resulting ~700MB filesize including audio, there is a lot of encoding guide you can read...
numaios
31st August 2005, 14:56
OK, but when are we starting to overkill the codec abilities? Above 2.000, 2.500 or 4.000 kbps?
stephanV
31st August 2005, 15:14
That depends completely on your resolution and content. I have samples that average around 4000 kbps for 624x352 at qp 24 (which is not an incredibly low qp).
IRMA1024
31st August 2005, 16:15
OK, but when are we starting to overkill the codec abilities? Above 2.000, 2.500 or 4.000 kbps?
based on my experience that 1200kbps is overkill for DVD source (on x264 best settings), resulting filesize ~1GB including sound...
but best result should come when using lossless coding, i heard it is available on x264
akupenguin
31st August 2005, 16:56
It's not a question of codec abilities: H.264 doesn't saturate at any bitrate. The limit is how much detail is actually in the source, since it's already compressed on the DVD. And that really varies.
zhangtrinity
31st August 2005, 17:21
So, like numaios said, "but when are we starting to overkill the codec abilities? Above 2.000, 2.500 or 4.000 kbps?" That's what I want to know exactly. I guess akupenguin is right, it all depends on the sources, and the sources vary from one to the other. If I want the best quality of the movie with x264, is there any way for me to get the betrate which should not be exceeded?
DarkZell666
31st August 2005, 17:57
If you want to "predict" the filesize, a very simple and fast (and somehow innacurate : +/- 25% in the worse case) calculation can be done:
final filesize (Mbytes) = ((bitrate(kbps) / 8) x film duration in seconds / 1024)
(... no need to be an expert to do this :P)
-> example : 800kbps / 8 x 7200 (2hours) / 1024 = 703,125MB
Perfect for a 700MB CD =)
Using 2pass encoding will solve the +/- 25% accuracy problem and give better bitrate allocation, resulting in much better visual quality.
But, rather than trying to figure out a bitrate, which depends on too many things (resolution, length, amount of "action" scenes, etc...) and which isn't constant at all if you do it the efficient way, try using the "constant quantizer" setting. This is the best way to go if the final filesize doesn't bother you that much (ex: if you want to fit 2 or 3 movies on a Data-DVD)
Explanation :
On one hand, if you use a low bitrate (<600kbps), some scenes with very fast-motion will be extremely ugly. On the other hand, using 4000kbps bitrate will be pure overkill in "still" scenes, but the fast-motion scenes will look fine.
Using constant quantizer will "let x264 determine the necessary bitrate to achieve the desired quality" (this is a very simplified and "far-from-exact" interpretation for you to understand better).
Try using Quantizers from 10 to 15 for near DVD quality (go up to 25 if you're not too difficult), and x264 will use the necessary bitrate at any moment of the movie (the bitrate will fluctuate a lot) to get the corresponding quality. The higher the quantizer, the lower the bitrate. A quantizer is in fact some sort of "compression factor".
The only problem with this method is that you cannot predict AT ALL the final filesize. You are only garanteed to have a consistent quality throughout the movie. I'll recommend you resize the movie to 640*480 (for 4:3) or 640*352 (for 16:9) since higher resolutions seem to be useless (for my eyes at least :p) All depends on what you are exactly trying to do :)
akupenguin
31st August 2005, 18:19
On one hand, if you use a low bitrate (<600kbps), some scenes with very fast-motion will be extremely ugly. On the other hand, using 4000kbps bitrate will be pure overkill in "still" scenes, but the fast-motion scenes will look fine.
That's why CBR sucks. And why x264 doesn't use CBR, even in a 1pass encode (unless you explicitely enable VBV). You don't need CQP for that, an ABR or 2pass encode also makes fast motion non-ugly without spending 4mbits on the stills.
Try using Quantizers from 10 to 15 for near DVD quality
QP 10 is way better than DVD quality.
(Of course, lossy->lossy can only lose less information, not gain. I'm just saying that if you had the source before it went through MPEG2, then H.264@QP=10 would be much higher quality than an average DVD. So if you encode @QP=10 from DVD, most of the bits will be spent reproducing MPEG2 artifacts, not actual content.)
But I agree that if you want a simple way to determin a max useful bitrate, CQP works.
Hmm... maybe I should make an AQP mode, whereby you get all the motion-adaption from 2pass/ABR but specify quality instead of bitrate.
zhangtrinity
31st August 2005, 18:26
From DarkZell666 "I'll recommend you resize the movie to 640*480 (for 4:3) or 640*352 (for 16:9) since higher resolutions seem to be useless (for my eyes at least ) All depends on what you are exactly trying to do " That's what I want to know. By the way, if I have a movie 720x576, is that necessary to resize to 640*352 (for 16:9)? I mean the resize will not harm the over-all quality? Is that true? Thanks million for help!
zhangtrinity
31st August 2005, 18:39
Put it this way, orignal movie 720x576, when I try to resize it, the option are either keep 720x576 or squeese to 640x352(16:9). As I concerned , if later on I play the file with a bigger screen, like apple 23', which method is better? in a large screen , will the higher resolutions still seem to be useless? By the way, in the encoding for the best quality , how about the b-frame , some bady said in the archive purpose, b-frame is unnecessary, is that true? Welcome to correct me?
numaios
1st September 2005, 04:38
QP 10 is way better than DVD quality.
(Of course, lossy->lossy can only lose less information, not gain. I'm just saying that if you had the source before it went through MPEG2, then H.264@QP=10 would be much higher quality than an average DVD. So if you encode @QP=10 from DVD, most of the bits will be spent reproducing MPEG2 artifacts, not actual content.)
But I agree that if you want a simple way to determin a max useful bitrate, CQP works.
Hmm... maybe I should make an AQP mode, whereby you get all the motion-adaption from 2pass/ABR but specify quality instead of bitrate.
And approximately, what's the max useful bitrate if we encode from the DVD "The Matrix", for instance?
What does CQP stand for? Constant quantizer prediction?
DarkZell666
3rd September 2005, 14:31
@zhangtrinity :
Resizing the picture to a (slightly) lower resolution only results in an slight loss of detail, but since there are less pixels to encode for a given bitrate and/or filesize, the quality of the encoding will be better (the pixels will be reproduced more precisely). Resizing to 640*352 hardly loses any detail (if you use lanczos or bicubic resizing). Here is a simple calculation for you :
720*576 is 414720 pixels per frame.
640*352 is 225280 pixels per frame (which is 1.841, almost twice less pixels, half of the original picture surface).
Don't try resizing to a lower resolution unless you are encoding cartoon/anime material otherwise you'll get a rather blurred picture.
As far as XviD is concerned, b-frames lower the bitrate drastically since the quantizer used for b-frames is higher (+2 in the most cases), but hardly impact (in some cases _not at all_) the visual quality. I have no idea of how the b-frames work in x264/AVC, but I guess the idea behind them is the same.
But be aware that b-frames are very CPU-time consuming, as well to encode as to decode. I wouldn't consider them as useless in any case, but if you plan on editing the encoded movie and reencoding it later for "final use", use them then, not before.
@numaios :
A bitrate can't just pop out "from the box" :/
All depends on what you are trying to do.
If it's for putting on a 700MB CD, just do the calculation I've posted a bit further up/down in the thread. If it's for "archiving", forget the bitrate idea and use CQP (let's say 15-20 to take into account what akupenguin said :P), the bitrate will be adjusted to "what is necessary". Then you can calculate the average bitrate using the obtained final filesize and adapt the bitrate accordingly (reencode it then using 2pass ABR =))
In any case I think the best thing to do is do your own tests and let your own eyes judge the result ;)
numaios
3rd September 2005, 23:46
I see... So if I want to achieve the highest -without wasting- bitrate, I must do 2 encodings (one CQP to find out the bitrate and then the 2-pass to encode it).
And what does CQP stand for?
akupenguin
5th September 2005, 10:53
"Constant Quantization Parameter"
And you don't need to waste an encode. The CQP could be the 1st pass of the final encode. (I recommend ABR 1st pass in general because it lets you specify bitrate instead of QP. But you want to specify QP, so CQP 1st pass is just as good.)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.