View Full Version : MPEG Layer 3 and h264 question
Blizzardstar
11th March 2007, 04:59
What is MPEG Layer 3? CBR VBR or ABR?
Also what is h264? I compress with Xvid and it says 263. Is it better (much better) or something?
setarip_old
11th March 2007, 07:22
Hi!What is MPEG Layer 3? CBR VBR or ABR?MPEG Layer 3 (".MP3") can be any one of the three you've noted...
munnasunna
11th March 2007, 07:53
h264 is much better than xvid at low bitrates, but xvid gives much better results than h264 at high bitrates like HD material.
Brother John
11th March 2007, 16:42
MPEG-1 Part 3 (Audio) Layer 3 is the full name of MP3.
ITU-T H.264 is the same as MPEG-4 Part 10 (Advanced Video Coding). Used e.g. by x264 and Nero AVC encoders.
MPEG-4 Part 2 (Visual) is the other (older than H.264) video format defined in MPEG-4. It's often refered to as "MPEG-4 ASP". Most common implementations are Xvid and DivX.
H.263 is a) an older ITU video standard and b) an encoding mode for MPEG-4 Visual encoders that uses the approach of the H.263 standard. Don't confuse this "H.263 encoding mode" with the "H.264 video standard". They're two completely different things.
All of those are "standards", i.e. basically just a set of rules (a few hundred pages of text each) defining how an audio/video stream should look. All the common en/decoding programs (LAME, x264, Xvid, DivX, Nero etc.) create/playback audio or video according to the rules defined in those standards.
Blizzardstar
11th March 2007, 18:00
Thanks everyone. :thanks:
But I have another question: How much is low enough bitrate for h264 to be better than h263?
My bitrate is usually around 300-600
If I should change to h264 where can I get it? And is the options menu similar to Xvid?
foxyshadis
12th March 2007, 04:51
It's not so much that h.264 is better at low and worse at high, it's just always smoother without tweaking the options quite a bit. The better and worse opinions come because at lower bitrates you're mostly concerned about avoiding blocking and noise, which h.264 easily smooths away, whereas at high you want all the detail, and sort of have to fight the codec to retain them. But there's a thread in the AVC forum that explains how.
At normal DVD-rip resolutions, you're way, way into 'low bitrate'. AVC will do miracles for you. 1000kbps is roughly where middling starts, and high can go from 1500 to 4000+ depending on how grungy the film is.
As for how to get it, you can use x264 in MeGUI/Staxrip/AVIDemux, you can use slightly obselete vfw x264 (http://gabextreme.googlepages.com/x264vfwunited) just like xvid, or you can also buy Nero Recode or Mainconcept.
Blizzardstar
12th March 2007, 19:43
I got the semi obsolete version.
But is there any kind of calculator? My limit is 100MB.
The options seem a bit limited compared to the xvid configuration menu...
foxyshadis
12th March 2007, 21:48
The same calculators that work with xvid will work with x264vfw. Bitrate is bitrate, as long as it's the same container.
Blizzardstar
13th March 2007, 00:36
So I should?:
1.Run first pass on xvid (So the calculator is accuarate)
2.Run first pass on x264 (So second pass bitrate is accurate)
2.Run final pass on x264?
>_< I make like 15 vids a day, it's seems kinda overwork. It's enough that I have to cut segments individually cause VirtualDub messes doing segments by itself.
Is this method correct or I'm just too newb?
LoRd_MuldeR
13th March 2007, 01:44
Blizzardstar, if you use the "x264 vfw" in VirtualDub, then you can give Avidemux a try ;)
The application itself is pretty similar to VirtualDub, but it supports much more input/output formats.
Furthermore Avidemux has x264, Xvid and many more encoders built-in, so no need to go through the "outdated" vfw-interface anymore :)
In case you like to give a try, you find recent builds for Win32 here:
http://forum.doom9.org/showthread.php?p=969514#post969514
Blizzardstar
13th March 2007, 02:22
Didn't work, first time it closed itself, seconf time it crashed. When I tried opening a file.
Anyway do I need to use that GordianKnot that the guide mentions?
foxyshadis
13th March 2007, 21:02
Why would you need a first pass just to use a calculator? How exactly do you use xvid's calculator? All you need is the length of the video and the size of the audio. Perhaps you could switch to one of the dozen or so other xvid calculators out there, that will automate the whole calculation when you drag your files in.
The two passes of x264 you'll need just like xvid, if you don't want to use crf.
Blizzardstar
14th March 2007, 05:19
Thank you :)
It works fine.
But there so less options in x264. Is there any way to control the frame rate? Or set it to PAL or NTSC?
foxyshadis
14th March 2007, 06:07
The xvid calculator can't control or set the frame rate; that's all done by the host (virtualdub or the avisynth script). The frame rate option is for one purpose only, calculating the total frame overhead in the avi. The framecount and time don't change in the encoded movie no matter what you set it to. (The frame drop ratio can, but that's not exactly fine-grained.)
Blizzardstar
14th March 2007, 17:27
I see... LOL I'm so noob It's embarassing XD
So how could I change the frame rate?
LoRd_MuldeR
14th March 2007, 17:40
I see... LOL I'm so noob It's embarassing XD
So how could I change the frame rate?
You need to change it in the host application.
If you frameserve the video into VirtualDub via Avisynth, you need to change the framerate in your AVS script. I'm not an Avisynth freak, but I think you can use the ChangeFPS() or ConvertFPS() command. In VirtualDub you can set the framerate at Video -> Framerate. But I don't know how good that performs compared to ConvertFPS() in Avisynth.
If you use Avidemux it's even more simple: Just use the "Resample FPS" video filter :cool:
Blizzardstar
15th March 2007, 02:35
I see. Thank you.
BTW What does NTSC-50 means? My card has that option besided NTSC and NTSC-J
foxyshadis
15th March 2007, 07:11
Just yet another of those strange format perversions used in one or two countries. NTSC transmission and encoding, but 50fps, maybe with 625 lines. Probably not something you'll ever need, unless it's a sort of stealth PAL option when there aren't any others.
Blizzardstar
16th March 2007, 03:37
Again Thank You so much.
Yet again, more question appear. It's about the first pass? Is there any way to auto-disscard it with x264? Also is there a signifficant difference between a FirstPass and FirstPass(fast) in quality?
foxyshadis
16th March 2007, 04:53
You can set the file to nul (or /dev/null on *nix/osx) and it will just throw away whatever comes out. Alternately, you can use the same target in the second as in the first, and it'll overwrite. Most guis will do one or the other for you automatically.
Fast first pass has only the tiniest difference to full, and isn't useful at all unless you're pushing the codec to its limits with super-low-bitrate, generally.
Blizzardstar
16th March 2007, 05:42
Thank you.
x264 seems to take a lot more time to process than xvid. Also takes into consideration the audio date even if it's the first pass (xvid didn't do this, seems like a waste of processing). Is there any way to change that? Also x264 stays more true for the original while xvid seems to smooth things out if the original wasn't that good to begin with. Argh dilemmas >_<
foxyshadis
16th March 2007, 08:35
x264 totally ignores audio, you won't get any in the output file at all. Not sure how it's taking it into consideration. You have to do it elsewhere, and mux in as a separate step after conversion. (Usually with mkvmerge or yamb/mp4box.)
Blizzardstar
16th March 2007, 21:25
I mean that in xvid I can choose to discard the first pass and it just creates a stat file with a 1/Kbs video rate and 0 for audio (since it's not the final file, later on I can compress the audio using VirtualDub with MP3 or LameMP3)
But in x264 it makes the first pass with the 1/Kbs rate for video as always but it makes the over 30MB for audio like if it were the final file.
Normally it takes the same amount of time the video plays for xvid to compress it, but with x264 it takes always around 130-150% of the original time, so I was wondering if it's due to the audio compression.
LoRd_MuldeR
16th March 2007, 21:40
Well, I don't know which application you use for encoding, but usually you can disable audio completely for the first pass. The video file created during the first pass will be deleted anyway. Encoding audio in first pass is a waste of time. All you need from first pass is the .stats file. This is 100% the same for both, Xvid and x264. Audio encoding is only needed for the second pass, as it will create the final file...
Blizzardstar
17th March 2007, 05:15
...so how do I do so it doesn't encode the audio in the first pass?
foxyshadis
17th March 2007, 09:50
Which application is it? (In vdub, audio->no audio; in vdubmod streams->stream list and remove everything; if you're using an avisynth script add KillAudio() somewhere in it.)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.