Well, I really don't know what the problem is or if there is a problem... but, in this certain part of the anime, when I encode with x264 it's taking out some of the source footage(I think) Here's a link to XVID and x264 versions (1.8mb)
http://n-r-g.uk.to/miya/testtt.zip
(sorry I couldn't screenshot for some reason)
You see how much better the XVID looks x.x, Is there anything I could change in x264's settings that could make the .mp4 better? Durring the hole video .mp4 is better except the parts with the fuzz >< But if there is nothing I can do (going with filesizes) I'd pick mp4 lol
I guess I'll post my settings too:
http://img101.imageshack.us/img101/3081 ... aaaat9.jpg
Encoding problem >__>
-
trythil
- is
- Joined: Tue Jul 23, 2002 5:54 am
- Status: N͋̀͒̆ͣ͋ͤ̍ͮ͌ͭ̔̊͒ͧ̿
- Location: N????????????????
I don't know how that GUI works (I usually just use the command-line encoder), but if that "1000" is specifying 1000 kbit/s for the 2nd pass bitrate, that might be a large chunk of the problem.
Run a first pass at (say) constant quality 18 to see what kind of bitrate your video requires to look good. The constant quality scale is similar to the quantizer scale, and H.264 quant 18 is (approximately) H.263 at quant 2. The quantizer range in which video can look "good" is, of course, dependent on the source material and the viewer, but I've found that 22-24 isn't too bad.
Run a first pass at (say) constant quality 18 to see what kind of bitrate your video requires to look good. The constant quality scale is similar to the quantizer scale, and H.264 quant 18 is (approximately) H.263 at quant 2. The quantizer range in which video can look "good" is, of course, dependent on the source material and the viewer, but I've found that 22-24 isn't too bad.
-
MiyaDV
- Joined: Tue Aug 29, 2006 4:36 am
I think it did mean the kbit/s.. I lowerd it and raised it and it gave worse/better quality.
I did the conts. Qual at 18, 26, and 22, 26 looked just like the the footage you saw in the clip. but 22 looked alot better at 700kbs ( for 2 seconds) .
I don't know how to find the bitrate on the videos tho, I tryed opening in vlc and checking info ><wasnt>< lol
I did the conts. Qual at 18, 26, and 22, 26 looked just like the the footage you saw in the clip. but 22 looked alot better at 700kbs ( for 2 seconds) .
I don't know how to find the bitrate on the videos tho, I tryed opening in vlc and checking info ><wasnt>< lol
-
Zero1
- Joined: Fri Jan 02, 2004 12:51 pm
- Location: Sheffield, United Kingdom
- Contact:
I don't know who made that profile, but it isn't good.
As trythil says, you should run a constant quality first pass to gauge how much bitrate the video needs. Think of JPG images. You can get one image at 1024x768 that might be 100KB, or another that might be 600KB at the same quality level. Same applies for video (what with it being a sequence of images), although video is even more unpredictable because things like how much change there is between frames matter too. A static scene will compress more than an action scene because it codes all the important parts and for the following frames it just stores the difference. Obviously in an action sequence there is a lot more difference between frames and so it requires more bitrate to store the changes.
On to the settings.
Reference frames: 16
I do not need to go into detail, but basically, more reference frames = better, but do bear in mind that more reference frames pushes up RAM requirements for the viewer. Most people don't seem to have problems with 16 references these days, but just bear it in mind. A reasonable value seems to be 8-12, but go for 16 if you want.
Number of B-frames
3 is conservative. You may want to set this to something like 4 or 5. x264 only uses B-frames where it is suitable and setting a large max number of B-frames means that in certain scenes where it is possible, it will maximise the bitrate savings. H.264 does not suffer from DCT drift like ASP did (XviD/DivX) so a large number of B-frames is relatively safe.
B-frame mode
If the option is available to you, set it to auto. This allows it to switch between temporal and spatial during an encode. x264 will see which mode is most optimal before encoding a frame and use that. It just helps push up the efficiency a little more.
B-frame bias
If you find your source is high in P-frames (x264 will usually give you a little report), you can use B-bias to influence the use of more B-frames. It is not uncommon to have more B-frames than P-frames, so if you have more P-frames, consider increasing this value.
ME-range
Some people suggest that 21 is a good value. Others say that 32 is good. I have also heard that 64 is not good. Personally I would be inclined to try 32. 21 seems like a magic number someone plucked out of nowhere.
Scene change sensitivity
Oh God no. They set it to 100?! You should set it back to it's default 40, or try 50. Setting this too high means to many I and P frames will be used where they are not needed and be placed in non optimally.
ME Algorithm
Use UMH (uneven multi hex) if it is available to you (if you want to change the ME-range, you will need this option anyway). ESA (exhaustive search algorithm) is slow and no better than UMH.
Subpixel refinement.
I'm assuming this is what I know as subme. If it has levels 1-7, you should use 5,6 or 7. Personally I would use 6 or 7. At the moment without checking this GUI, it seems that it is using level 2? (unless they are labeling the subme items differently), and let me tell you, recently I saw an encode using subme 1, and it was awful. Subme 7 should say something like RDO on B-frames. Subme is one of the important ones, you shouldn't skimp on this one.
If you are brave, or looking for a reference, try
http://aflux.deltaanime.net/Zero1/MP4/x264.html
As trythil says, you should run a constant quality first pass to gauge how much bitrate the video needs. Think of JPG images. You can get one image at 1024x768 that might be 100KB, or another that might be 600KB at the same quality level. Same applies for video (what with it being a sequence of images), although video is even more unpredictable because things like how much change there is between frames matter too. A static scene will compress more than an action scene because it codes all the important parts and for the following frames it just stores the difference. Obviously in an action sequence there is a lot more difference between frames and so it requires more bitrate to store the changes.
On to the settings.
Reference frames: 16
I do not need to go into detail, but basically, more reference frames = better, but do bear in mind that more reference frames pushes up RAM requirements for the viewer. Most people don't seem to have problems with 16 references these days, but just bear it in mind. A reasonable value seems to be 8-12, but go for 16 if you want.
Number of B-frames
3 is conservative. You may want to set this to something like 4 or 5. x264 only uses B-frames where it is suitable and setting a large max number of B-frames means that in certain scenes where it is possible, it will maximise the bitrate savings. H.264 does not suffer from DCT drift like ASP did (XviD/DivX) so a large number of B-frames is relatively safe.
B-frame mode
If the option is available to you, set it to auto. This allows it to switch between temporal and spatial during an encode. x264 will see which mode is most optimal before encoding a frame and use that. It just helps push up the efficiency a little more.
B-frame bias
If you find your source is high in P-frames (x264 will usually give you a little report), you can use B-bias to influence the use of more B-frames. It is not uncommon to have more B-frames than P-frames, so if you have more P-frames, consider increasing this value.
ME-range
Some people suggest that 21 is a good value. Others say that 32 is good. I have also heard that 64 is not good. Personally I would be inclined to try 32. 21 seems like a magic number someone plucked out of nowhere.
Scene change sensitivity
Oh God no. They set it to 100?! You should set it back to it's default 40, or try 50. Setting this too high means to many I and P frames will be used where they are not needed and be placed in non optimally.
ME Algorithm
Use UMH (uneven multi hex) if it is available to you (if you want to change the ME-range, you will need this option anyway). ESA (exhaustive search algorithm) is slow and no better than UMH.
Subpixel refinement.
I'm assuming this is what I know as subme. If it has levels 1-7, you should use 5,6 or 7. Personally I would use 6 or 7. At the moment without checking this GUI, it seems that it is using level 2? (unless they are labeling the subme items differently), and let me tell you, recently I saw an encode using subme 1, and it was awful. Subme 7 should say something like RDO on B-frames. Subme is one of the important ones, you shouldn't skimp on this one.
If you are brave, or looking for a reference, try
http://aflux.deltaanime.net/Zero1/MP4/x264.html
7-zip // x264 (Sharktooth's builds) // XviD (Koepi's builds) // MP4box (celtic_druid's builds) // Firefox // CCCP