Posted: 12/17/2007 2:04 AM
Post subject: How are the videos so high quality, yet small?
Quote
Neillithan
Joined: 8/4/2007
Posts: 5
Okay, I'm sure this has been asked a hundred times here... but the truth is I did a search in the forum and came up with non relevant results. I realize a few things. The videos are being encoded at a low bit rate. Somewhere below 500. I also know the videos are being encoded in x264 with many many reference frames. But what I don't know is how the videos manage to be so small, yet high quality. I have attempted multiple times with x264 and all I can come up with is a huge file with good quality. What I'm really trying to get at is, what specific settings must I enable during the encoding process to achieve the quality of some of DeHacked's videos while keeping the video size small.. Also, is XviD able to produce videos with comparable quality / size? If so, then I would certainly like to know. Thanks in advance. -Neil
Posted: 12/17/2007 2:06 AM
Post subject: Re: How are the videos so high quality, yet small?
Quote
Bisqwit
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
XviD is inferior in quality to H.264. We enable many settings that improve quality / size ratio at the expense of encoding speed. Reading the mencoder manual helps understanding some, some are understood by trial&error.
Posted: 12/17/2007 2:08 AM
Quote
Tub
Joined: 6/25/2005
Posts: 1377
did you already try the hints mentioned here?
m00
Posted: 12/17/2007 1:12 PM
Quote
Warp
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
XviD, like DivX, uses the first MPEG-4 standard, which is of higher quality than MPEG-2, and of much higher quality than MPEG-1. H.264, aka. MPEG-4 Part 10, aka. AVC, is an extension to the MPEG-4 standard which improves it, and is capable of even higher quality for the same bitrates than the basic MPEG-4. x264 is one implementation of H.264. But higher quality is not always automatic. The compression has many, many different options, and which options are best depends on the type of input video. It's quite difficult for any software to automatically detect from the original video input what would be the best compression settings for a maximum quality/bitrate ratio. Thus codecs usually use quite generic default settings which work most of the time (I suppose usually tuned to give good results for most live video), but which might not always be the best settings for console videogame style images, which is a rather radical extreme compared to the typical video material. Thus manual fine-tuning is often required for best quality.
Posted: 12/17/2007 2:40 PM
Quote
moozooh
Senior Moderator
Joined: 8/4/2005
Posts: 5777
Location: Away
In addition to that, there are many settings that always improve quality in case with H.264 — but at the cost of much longer processing time, which is the primary reason most of them aren't enabled by default. It's not particularly unexpected here to see an x264 command line that makes the file compress about 100 times longer for about 5% increase in quality. To find and use such settings is crucial in order to make a good encode. Don't forget that the file is only encoded once.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Posted: 12/17/2007 2:47 PM
Quote
DeHackEd
Emulator Coder, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
The videos I make usually target 240-300 kbit (though there are plenty of exceptions) and use a set of very high quality encoding settings. Even with a 2.2 GHz Athlon64, I normally only get an encoding speed of 20-30 fps. But you get what you pay for. If you're willing to spend 12 hours to encode Chrono Trigger for each pass, you can get a very small AVI out of it when you're done. If you just want to just play with making something usable, using a "quantizer parameter" of 28 usually provides a good target for a single pass if you want.
Posted: 3/21/2008 6:12 AM
Quote
ccfreak2k
Joined: 11/1/2007
Posts: 100
It's also a case of computational complexity. The added quality-per-bit isn't 100% free; it costs more decode time. This can/usually is compensated by a faster CPU (or, even better, h.264 hardware decoding on the GPU. There's also multipass encoding, which DeHackEd can explain better than I can.