Mercurial > mplayer.hg
comparison DOCS/tech/encoding-tips.txt @ 8463:e421b4ab7815
encoding tips - collected from mplayer-users list mailings by
Martin Pavon <martin_199ar@yahoo.com.ar>
(some additions/changes by me)
author | arpi |
---|---|
date | Sun, 15 Dec 2002 18:40:42 +0000 |
parents | |
children | 805b19425c19 |
comparison
equal
deleted
inserted
replaced
8462:800d77666843 | 8463:e421b4ab7815 |
---|---|
1 | |
2 ENCODING QUALITY - OR WHY AUTOMATISM IS BAD. | |
3 | |
4 Hi everyone. | |
5 | |
6 Some days ago someone suggested adding some preset options to mencoder. | |
7 At that time I replied 'don't do that', and now I decided to elaborate | |
8 on that. | |
9 | |
10 Warning: this is rather long, and it involves mathematics. But if you | |
11 don't want to bother with either then why are you encoding in the | |
12 first place? Go do something different! | |
13 | |
14 The good news is: it's all about the bpp (bits per pixel). | |
15 | |
16 The bad news is: it's not THAT easy ;) | |
17 | |
18 This mail is about encoding a DVD to MPEG4. It's about the video | |
19 quality, not (primarily) about the audio quality or some other fancy | |
20 things like subtitles. | |
21 | |
22 The first step is to encode the audio. Why? Well if you encode the | |
23 audio prior to the video you'll have to make the video fit onto one | |
24 (or two) CD(s). That way you can use oggenc's quality based encoding | |
25 mode which is much more sophisticated than its ABR based mode. | |
26 | |
27 After encoding the audio you have a certain amount of space left to | |
28 fill with video. Let's assume the audio takes 60M (no problem with | |
29 Vorbis), and you aim at a 700M CD. This leaves you 640M for the video. | |
30 Let's further assume that the video is 100 minutes or 6000 seconds | |
31 long, encoded at 25fps (those nasty NTSC fps values give me | |
32 headaches. Adjust to your needs, of course!). This leaves you with | |
33 a video bitrate of: | |
34 | |
35 $videosize * 8 | |
36 $videobitrate = -------------- | |
37 $length * 1000 | |
38 | |
39 $videosize in bytes, $length in seconds, $videobitrate in kbit/s. | |
40 In my example I end up with $videobitrate = 895. | |
41 | |
42 And now comes the question: how do I chose my encoding parameters | |
43 so that the results will be good? First let's take a look at a | |
44 typical mencoder line: | |
45 | |
46 mencoder -dvd 1 -o /dev/null -oac copy -ovc lavc \ | |
47 -lavcopts vcodec=mpeg4:vbitrate=1000:vhq:vqmin=2:\ | |
48 vlelim=-4:vcelim=9:lumi_mask=0.05:dark_mask=0.01:vpass=1 \ | |
49 -vop scale=640:480,crop=716:572:2:2 | |
50 | |
51 Phew, all those parameters! Which ones should I change? NEVER leave | |
52 out 'vhq'. Never ever. 'vqmin=2' is always good if you aim for sane | |
53 settings - like 'normal length' movies on one CD, 'very long movies' | |
54 on two CDs and so on. vcodec=mpeg4 is mandatory. | |
55 | |
56 The 'vlelim=-4:vcelim=9:lumi_mask=0.05:dark_mask=0.01' are parameters | |
57 suggested by D Richard Felker for non-animated movies, and they | |
58 improve quality a bit. | |
59 | |
60 But the two things that have the most influence on quality are | |
61 vbitate and scale. Why? Because both together tell the codec how | |
62 many bits it may spend on each frame for each bit: and this is | |
63 the 'bpp' value (bits per pixel). It's simply defined as | |
64 | |
65 $videobitrate * 1000 | |
66 $bpp = ----------------------- | |
67 $width * $height * $fps | |
68 | |
69 I've attached a small Perl script that calculates the $bpp for | |
70 a movie. You'll have to give it four parameters: | |
71 a) the cropped but unscaled resolution (use '-vop cropdetect'), | |
72 b) the encoded aspect ratio. All DVDs come at 720x576 but contain | |
73 a flag that tells the player wether it should display the DVD at | |
74 an aspect ratio of 4/3 (1.333) or at 16/9 (1.777). Have a look | |
75 at mplayer's output - there's something about 'prescaling'. That's | |
76 what you are looking for. | |
77 c) the video bitrate in kbit/s and | |
78 d) the fps. | |
79 | |
80 In my example the command line and calcbpp.pl's output would look | |
81 like this (warning - long lines ahead): | |
82 | |
83 mosu@anakin:~$ ./calcbpp.pl 720x440 16/9 896 25 | |
84 Prescaled picture: 1023x440, AR 2.33 | |
85 720x304, diff 5, new AR 2.37, AR error 1.74% scale=720:304 bpp: 0.164 | |
86 704x304, diff -1, new AR 2.32, AR error 0.50% scale=704:304 bpp: 0.167 | |
87 688x288, diff 8, new AR 2.39, AR error 2.58% scale=688:288 bpp: 0.181 | |
88 672x288, diff 1, new AR 2.33, AR error 0.26% scale=672:288 bpp: 0.185 | |
89 656x288, diff -6, new AR 2.28, AR error 2.17% scale=656:288 bpp: 0.190 | |
90 640x272, diff 3, new AR 2.35, AR error 1.09% scale=640:272 bpp: 0.206 | |
91 624x272, diff -4, new AR 2.29, AR error 1.45% scale=624:272 bpp: 0.211 | |
92 608x256, diff 5, new AR 2.38, AR error 2.01% scale=608:256 bpp: 0.230 | |
93 592x256, diff -2, new AR 2.31, AR error 0.64% scale=592:256 bpp: 0.236 | |
94 576x240, diff 8, new AR 2.40, AR error 3.03% scale=576:240 bpp: 0.259 | |
95 560x240, diff 1, new AR 2.33, AR error 0.26% scale=560:240 bpp: 0.267 | |
96 544x240, diff -6, new AR 2.27, AR error 2.67% scale=544:240 bpp: 0.275 | |
97 528x224, diff 3, new AR 2.36, AR error 1.27% scale=528:224 bpp: 0.303 | |
98 512x224, diff -4, new AR 2.29, AR error 1.82% scale=512:224 bpp: 0.312 | |
99 496x208, diff 5, new AR 2.38, AR error 2.40% scale=496:208 bpp: 0.347 | |
100 480x208, diff -2, new AR 2.31, AR error 0.85% scale=480:208 bpp: 0.359 | |
101 464x192, diff 7, new AR 2.42, AR error 3.70% scale=464:192 bpp: 0.402 | |
102 448x192, diff 1, new AR 2.33, AR error 0.26% scale=448:192 bpp: 0.417 | |
103 432x192, diff -6, new AR 2.25, AR error 3.43% scale=432:192 bpp: 0.432 | |
104 416x176, diff 3, new AR 2.36, AR error 1.54% scale=416:176 bpp: 0.490 | |
105 400x176, diff -4, new AR 2.27, AR error 2.40% scale=400:176 bpp: 0.509 | |
106 384x160, diff 5, new AR 2.40, AR error 3.03% scale=384:160 bpp: 0.583 | |
107 368x160, diff -2, new AR 2.30, AR error 1.19% scale=368:160 bpp: 0.609 | |
108 352x144, diff 7, new AR 2.44, AR error 4.79% scale=352:144 bpp: 0.707 | |
109 336x144, diff 0, new AR 2.33, AR error 0.26% scale=336:144 bpp: 0.741 | |
110 320x144, diff -6, new AR 2.22, AR error 4.73% scale=320:144 bpp: 0.778 | |
111 | |
112 A word for the $bpp. For a fictional movie which is only black and | |
113 white: if you have a $bpp of 1 then the movie would be stored | |
114 uncompressed :) For a real life movie with 24bit color depth you | |
115 need compression of course. And the $bpp can be used to make the | |
116 decision easier. | |
117 | |
118 As you can see the resolutions suggested by the script are all | |
119 dividable by 16. This will make the aspect ratio slightly wrong, | |
120 but no one will notice. | |
121 | |
122 Now if you want to decide which resolution (and scaling parameters) | |
123 to chose you can do that by looking at the $bpp: | |
124 | |
125 < 0.10: don't do it. Please. I beg you! | |
126 < 0.15: It will look bad. | |
127 < 0.20: You will notice blocks, but it will look ok. | |
128 < 0.25: It will look really good. | |
129 > 0.25: It won't really improve visually. | |
130 > 0.30: Don't do that either - try a bigger resolution instead. | |
131 | |
132 Of course these values are not absolutes! For movies with really lots | |
133 of black areas 0.15 may look very good. Action movies with only high | |
134 motion scenes on the other hand may not look perfect at 0.25. But these | |
135 values give you a great idea about which resolution to chose. | |
136 | |
137 I see a lot of people always using 512 for the width and scaling | |
138 the height accordingly. For my (real-world-)example this would be | |
139 simply a waste of bandwidth. The encoder would probably not even | |
140 need the full bitrate, and the resulting file would be smaller | |
141 than my targetted 700M. | |
142 | |
143 After encoding you'll do your 'quality check'. First fire up the movie | |
144 and see whether it looks good to you or not. But you can also do a | |
145 more 'scientific' analysis. The second Perl script I attached counts | |
146 the quantizers used for the encoding. Simply call it with | |
147 | |
148 countquant.pl < divx2pass.log | |
149 | |
150 It will print out which quantizer was used how often. If you see that | |
151 e.g. the lowest quantizer (vqmin=2) gets used for > 95% of the frames | |
152 then you can safely increase your picture size. | |
153 | |
154 > The "counting the quantesizer"-thing could improve the quality of | |
155 > full automated scripts, as I understand ? | |
156 | |
157 Yes, the log file analysis can be used be tools to automatically adjust | |
158 the scaling parameters (if you'd do that you'd end up with a three-pass | |
159 encoding for the video only ;)), but it can also provide answers for | |
160 you as a human. From time to time there's a question like 'hey, | |
161 mencoder creates files that are too small! I specified this bitrate and | |
162 the resulting file is 50megs short of the target file size!'. The | |
163 reason is probably that the codec already uses the minimum quantizer | |
164 for nearly all frames so it simply does not need more bits. A quick | |
165 glance at the distribution of the quantizers can be enlightening. | |
166 | |
167 Another thing is that q=2 and q=3 look really good while the 'bigger' | |
168 quantizers really lose quality. So if your distribution shows the | |
169 majority of quantizers at 4 and above then you should probably decrease | |
170 the resolution (you'll definitly see block artefacts). | |
171 | |
172 | |
173 Well... Several people will probably disagree with me on certain | |
174 points here, especially when it comes down to hard values (like the | |
175 $bpp categories and the percentage of the quantizers used). But | |
176 the idea is still valid. | |
177 | |
178 And that's why I think that there should NOT be presets in mencoder | |
179 like the presets lame knows. 'Good quality' or 'perfect quality' are | |
180 ALWAYS relative. They always depend on a person's personal preferences. | |
181 If you want good quality then spend some time reading and - more | |
182 important - understanding what steps are involved in video encoding. | |
183 You cannot do it without mathematics. Oh well, you can, but you'll | |
184 end up with movies that could certainly look better. | |
185 | |
186 Now please shoot me if you have any complaints ;) | |
187 | |
188 -- | |
189 ==> Ciao, Mosu (Moritz Bunkus) | |
190 | |
191 =========== | |
192 ANOTHER APPROACH: BITS PER BLOCK: | |
193 | |
194 > $videobitrate * 1000 | |
195 > $bpp = ----------------------- | |
196 > $width * $height * $fps | |
197 | |
198 Well, I came to similar equation going through different route. Only I | |
199 didn't use bits per pixel, in my case it was bits per block (BPB). The block | |
200 is 16x16 because lots of software depends on video width/height being | |
201 divisable by 16. And because I didn't like this 0.2 bit per pixel, when | |
202 bit is quite atomic ;) | |
203 | |
204 So the equation was something like: | |
205 | |
206 bitrate | |
207 bpb = ----------------- | |
208 fps * ((width * height) / (16 * 16)) | |
209 | |
210 (width and height are from destination video size, and bitrate is in | |
211 bits (i.e. 900kbps is 900000)) | |
212 | |
213 This way it apeared that the minimum bits per block is ~40, very | |
214 good results are with ~50, and everything above 60 is a waste of bandwith. | |
215 And what's actually funny is that it was independant of codec used. The | |
216 results were exactly the same, whether I used DIV3 (with tricky nandub's | |
217 magick), ffmpeg odivx, DivX5 on Windows or XviD. | |
218 | |
219 Surprisingly there is one advantage of using nandub-DIV3 for bitrate | |
220 starved encoding: ringing almost never apears this way. | |
221 | |
222 But I also found out, that the quality/BPB isn't constant for | |
223 drastically different resolutions. Smaller picture (like MPEG1 sizes) | |
224 need more BPB to look good than say typical MPEG2 resolutions. | |
225 | |
226 Robert | |
227 | |
228 | |
229 =========== | |
230 DON'T SCALE DOWN TOO MUCH | |
231 | |
232 Sometimes I found that encoding to y-scaled only DVD qualty (ie 704 x | |
233 288 for a 2.85 film) gives better visual quality than a scaled-down | |
234 version even if the quantizers are significantly higher than for the | |
235 scaled-down version. | |
236 Keep in mind that blocs, fuzzy parts and generaly mpeg artefacts in a | |
237 704x288 image will be harder to spot in full-screen mode than on a | |
238 512x208 image. In fact I've see example where the same movie looks | |
239 better compressed to 704x288 with an average weighted quantizer of | |
240 ~3 than the same movie scaled to 576x240 with an average weighted | |
241 quantizer of 2.4. | |
242 Btw, a print of the weighted average quantizer would be nice in | |
243 countquant.pl :) | |
244 | |
245 Another point in favor of not trying to scale down too much : on hard | |
246 scaled-down movies, the MPEG codec will need to compress relatively | |
247 high frequencies rather than low frequencies and it doesn't like that | |
248 at all. You will see less and less returns while you scale down and | |
249 scale down again in desesperate need of some bandwidth :) | |
250 | |
251 In my experience, don't try to go below a width of 576 without closely | |
252 watching what's going on. | |
253 | |
254 -- | |
255 Rémi | |
256 | |
257 =========== | |
258 TIPS FOR ENCODING | |
259 | |
260 That being said, with video you have some tradeoffs you can make. Most | |
261 people seem to encode with really basic options, but if you play with | |
262 single coefficient elimination and luma masking settings, you can save lots | |
263 of bits, resulting in lower quantizers, which means less blockiness and | |
264 less ugly noise (ringing) around sharp borders. The tradeoff, however, is | |
265 that you'll get some "muddiness" in some parts of the image. Play around | |
266 with the settings and see for yourself. The options I typically use for | |
267 (non-animated) movies are: | |
268 | |
269 vlelim=-4 | |
270 vcelim=9 | |
271 lumi_mask=0.05 | |
272 dark_mask=0.01 | |
273 | |
274 If things look too muddy, making the numbers closer to 0. For anime and | |
275 other animation, the above recommendations may not be so good. | |
276 | |
277 Another option that may be useful is allowing four motion vectors per | |
278 macroblock (v4mv). This will increase encoding time quite a bit, and | |
279 last I checked it wasn't compatible with B frames. AFAIK, specifying | |
280 v4mv should never reduce quality, but it may prevent some old junky | |
281 versions of DivX from decoding it (can anyone conform?). Another issue | |
282 might be increased cpu time needed for decoding (again, can anyone | |
283 confirm?). | |
284 | |
285 To get more fair distribution of bits between low-detail and | |
286 high-detail scenes, you should probably try increasing vqcomp from the | |
287 default (0.5) to something in the range 0.6-0.8. | |
288 | |
289 Of course you also want to make sure you crop ALL of the black border and | |
290 any half-black pixels at the edge of the image, and make sure the final | |
291 image dimensions after cropping and scaling are multiples of 16. Failing to | |
292 do so will drastically reduce quality. | |
293 | |
294 Finally, if you can't seem to get good results, you can try scaling the | |
295 movie down a bit smaller or applying a weak gaussian blur to reduce the | |
296 amount of detail. | |
297 | |
298 Now, my personal success story! I just recently managed to fit a beautiful | |
299 encode of Kundun (well over 2 hours long, but not too many high-motion | |
300 scenes) on one cd at 640x304, with 66 kbit/sec abr ogg audio, using the | |
301 options I described above. So, IMHO it's definitely possible to get very | |
302 good results with libavcodec (certainly MUCH better than all the idiot | |
303 "release groups" using DivX3 make), as long as you take some time to play | |
304 around with the options. | |
305 | |
306 | |
307 Rich | |
308 | |
309 ============ | |
310 ABOUT VLELIM, VCELIM, LUMI_MASK AND DARK_MASK PART I: LUMA & CHROMA | |
311 | |
312 | |
313 The l/c in vlelim and vcelim stands for luma (brightness plane) and chroma | |
314 (color planes). These are encoded separately in all mpeg-like algorithms. | |
315 Anyway, the idea behind these options is (at least from what I understand) | |
316 to use some good heuristics to determine when the change in a block is less | |
317 than the threshold you specify, and in such a case, to just encode the | |
318 block as "no change". This saves bits and perhaps speeds up encoding. Using | |
319 a negative value for either one means the same thing as the corresponding | |
320 positive value, but the DC coefficient is also considered. Unfortunately | |
321 I'm not familiar enough with the mpeg terminology to know what this means | |
322 (my first guess would be that it's the constant term from the DCT), but it | |
323 probably makes the encoder less likely to apply single coefficient | |
324 elimination in cases where it would look bad. It's presumably recommended | |
325 to use negative values for luma (which is more noticable) and positive for | |
326 chroma. | |
327 | |
328 The other options -- lumi_mask and dark_mask -- control how the quantizer | |
329 is adjusted for really dark or bright regions of the picture. You're | |
330 probably already at least a bit familiar with the concept of quantizers | |
331 (qscale, lower = more precision, higher quality, but more bits needed to | |
332 encode). What not everyone seems to know is that the quantizer you see | |
333 (e.g. in the 2pass logs) is just an average for the whole frame, and lower | |
334 or higher quantizers may in fact be used in parts of the picture with more | |
335 or less detail. Increasing the values of lumi_mask and dark_mask will cause | |
336 lavc to aggressively increase the quantizer in very dark or very bright | |
337 regions of the picture (which are presumably not as noticable to the human | |
338 eye) in order to save bits for use elsewhere. | |
339 | |
340 Rich | |
341 | |
342 =================== | |
343 ABOUT VLELIM, VCELIM, LUMI_MASK AND DARK_MASK PART II: VQSCALE | |
344 | |
345 OK, a quick explanation. The quantizer you set with vqscale=N is the | |
346 per-frame quantizer parameter (aka qp). However, with mpeg4 it's | |
347 allowed (and recommended!) for the encoder to vary the quantizer on a | |
348 per-macroblock (mb) basis (as I understand it, macroblocks are 16x16 | |
349 regions composed of 4 8x8 luma blocks and 2 8x8 chroma blocks, u and | |
350 v). To do this, lavc scores each mb with a complexity value and | |
351 weights the quantizer accordingly. However, you can control this | |
352 behavior somewhat with scplx_mask, tcplx_mask, dark_mask, and | |
353 lumi_mask. | |
354 | |
355 scplx_mask -- raise quantizer on mb's with lots of spacial complexity. | |
356 Spacial complexity is measured by variance of the texture (this is | |
357 just the actual image for I blocks and the difference from the | |
358 previous coded frame for P blocks). | |
359 | |
360 tcplx_mask -- raise quantizer on mb's with lots of temporal | |
361 complexity. Temporal complexity is measured according to motion | |
362 vectors. | |
363 | |
364 dark_mask -- raise quantizer on very dark mb's. | |
365 | |
366 lumi_mask -- raise quantizer on very bright mb's. | |
367 Somewhere around 0-0.15 is a safe range for these values, IMHO. You | |
368 might try as high as 0.25 or 0.3. You should probably never go over | |
369 0.5 or so. | |
370 | |
371 Now, about naq. When you adjust the quantizers on a per-mb basis like | |
372 this (called adaptive quantization), you might decrease or (more | |
373 likely) increase the average quantizer used, so that it no longer | |
374 matches the requested average quantizer (qp) for the frame. This will | |
375 result in weird things happening with the bitrate, at least from my | |
376 experience. What naq does is "normalize adaptive quantization". That | |
377 is, after the above masking parameters are applied on a per-mb basis, | |
378 the quantizers of all the blocks are rescaled so that the average | |
379 stays fixed at the desired qp. | |
380 | |
381 So, if I used vqscale=4 with naq and fairly large values for the | |
382 masking parameters, I might be likely to see lots of frames using | |
383 qscale 2,3,4,5,6,7 across different macroblocks as needed, but with | |
384 the average sticking around 4. However, I haven't actually tested such | |
385 a setup yet, so it's just speculation right now. | |
386 | |
387 Have fun playing around with it. | |
388 | |
389 Rich | |
390 | |
391 ====================== | |
392 TIPS FOR ENCODING OLD BLACK & WHITE MOVIES: | |
393 | |
394 I found myself that 4:3 B&W old movies are very hard to compress well. In | |
395 addition to the 4:3 aspect ratio which eats lots of bits, those movies are | |
396 typically very "noisy", which doesn't help at all. Anyway : | |
397 | |
398 > After a few tries I am | |
399 > still a little bit disappointed with the video quality. Since it is a | |
400 > "dark" movies, there is a lot of black on the pictures, and on the | |
401 > encoded avi I can see a lot of annoying "mpeg squares". I am using | |
402 > avifile codec, but the best I think is to give you the command line I | |
403 > used to encode a preview of the result: | |
404 | |
405 > | |
406 > First pass: | |
407 > mencoder TITLE01-ANGLE1.VOB -oac copy -ovc lavc -lavcopts | |
408 > vcodec=mpeg4:vhq:vpass=1:vbitrate=800:keyint=48 -ofps 23.976 -npp lb | |
409 > -ss 2:00 -endpos 0:30 -vop scale -zoom -xy 640 -o movie.avi | |
410 | |
411 1) keyint=48 is way too low. The default value is 250, this is in *frames* | |
412 not seconds. Key frames are significantly larger than P or B frames, so the | |
413 less key frames you have, better the overall movie will be. (huh, like Yoda | |
414 I speak ;). Try keyint=300 or 350. Don't go beyond that if you want | |
415 relatively precise seeking. | |
416 | |
417 2) you may want to play with vlelim and vcelim options. This can gives you | |
418 a significant "quality" boost. Try one of these couples : | |
419 | |
420 vlelim=-2:vcelim=3 | |
421 vlelim=-3:vcelim=5 | |
422 vlelim=-4:vcelim=7 | |
423 (and yes, there's a minus) | |
424 | |
425 3) crop & rescale the movie before passing it to the codec. First crop the | |
426 movie to not encode black bars if there's any. For a 1h40mn movie | |
427 compressed to a 700 MB file, I would try something between 512x384 and | |
428 480x320. Don't go below that if you want something relatively sharp when | |
429 viewed fullscreen. | |
430 | |
431 4) I would recommend using the Ogg Vorbis audio codec with the .ogm | |
432 container format. Ogg Vorbis compress audio better than MP3. On a typical | |
433 old, mono-only audio stream, a 45 kbits/s Vorbis stream is ok. How to | |
434 extract & compress an audio stream from a ripped DVD (mplayer -dvd 1 | |
435 -dumpstream) : | |
436 | |
437 rm -f audiodump.pcm ; mkfifo -m 600 audiodump.pcm | |
438 mplayer -quiet -vc null -vo null -aid 128 -ao pcm -nowaveheader stream.dump & | |
439 oggenc --raw --raw-bits=16 --raw-chan=2 --raw-rate=48000 -q 1 -o audio-us.ogg | |
440 +audiodump.pcm & | |
441 wait | |
442 | |
443 For a nice set of utilities to manager the .ogm format, see Moritz Bunkus' | |
444 ogmtools (google is your friend). | |
445 | |
446 5) use the "v4mv" option. This could gives you a few more bits at the | |
447 expense of a slightly longer encoding. This is a "lossless" option, I mean | |
448 with this option you don't throw away some video information, it just | |
449 selects a more precise motion estimation method. Be warned that on some | |
450 very un-typical scenes this option may gives you a longer file than | |
451 without, although it's very rare and on a whole film I think it's always a | |
452 win. | |
453 | |
454 6) you can try the new luminance & darkness masking code. Play | |
455 with the "lumi_mask" and "dark_mask" options. I would recommend using | |
456 something like : | |
457 lumi_mask=0.07:dark_mask=0.10:naq: | |
458 lumi_mask=0.10:dark_mask=0.12:naq: | |
459 lumi_mask=0.12:dark_mask=0.15:naq | |
460 lumi_mask=0.13:dark_mask=0.16:naq: | |
461 Be warned that these options are really experimental and the result | |
462 could be very good or very bad depending on your visualization device | |
463 (computer CRT, TV or TFT screen). Don't push too hard these options. | |
464 | |
465 > Second pass: | |
466 > the same with vpass=2 | |
467 | |
468 7) I've found that lavc gives better results when the first pass is done | |
469 with "vqscale=2" instead of a target bitrate. The statistics collected | |
470 seems to be more precise. YMMV. | |
471 | |
472 > I am new to mencoder, so please tell me any idea you have even if it | |
473 > obvious. I also tried the "gray" option of lavc, to encode B&W only, | |
474 > but strangely it gives me "pink" squares from time to time. | |
475 | |
476 Yes, I've seen that too. Playing the resulting file with "-lavdopts gray" | |
477 fix the problem but it's not very nice ... | |
478 | |
479 > So if you could tell me what option of mencoder or lavc I should be | |
480 > looking at to lower the number of "squares" on the image, it would be | |
481 > great. The version of mencoder i use is 0.90pre8 on a macos x PPC | |
482 > platform. I guess I would have the same problem by encoding anime | |
483 > movies, where there are a lot of region of the image with the same | |
484 > color. So if you managed to solve this problem... | |
485 | |
486 You could also try the "mpeg_quant" flag. It selects a different set of | |
487 quantizers and produce somewhat sharper pictures and less blocks on large | |
488 zones with the same or similar luminance, at the expense of some bits. | |
489 | |
490 > This is completely off topic, but do you know how I can create good | |
491 > subtitles from vobsub subtitles ? I checked the -dumpmpsub option of | |
492 > mplayer, but is there a way to do it really fast (ie without having to | |
493 > play the whole movie) ? | |
494 | |
495 I didn't find a way under *nix to produce reasonably good text subtitles | |
496 from vobsubs. OCR *nix softwares seems either not suited to the task, not | |
497 powerful enough or both. I'm extracting the vobsub subtitles and simply use | |
498 them with the .ogm | |
499 | |
500 / .avi : | |
501 1) rip the DVD to harddisk with "mplayer -dvd 1 -dumpstream" | |
502 2) mount the DVD and copy the .ifo file | |
503 2) extract all vobsubs to one single file with something like : | |
504 | |
505 for f in 0 1 2 3 4 5 6 7 8 9 10 11 ; do \ | |
506 mencoder -ovc copy -oac copy -o /dev/null -sid $f -vobsubout sous-titres | |
507 +-vobsuboutindex $f -ifo vts_01_0.ifo stream.dump | |
508 done | |
509 | |
510 (and yes, I've a DVD with 12 subtitles) | |
511 -- | |
512 Rémi | |
513 | |
514 ================================ | |
515 | |
516 TIPS FOR SMOKE & CLOUDS | |
517 | |
518 Q: I'm trying to encode Dante's Peak and I'm having problems with clouds, | |
519 fog and smoke: They don't look fine (they look very bad if I watch the | |
520 movie in TVout). There are some artifacts, white clouds looks as snow | |
521 mountains, there are things likes hip in the colors so one can see frontier | |
522 curves between white and light gray and dark gray ... (I don't know if you | |
523 can understand me, I want to mean that the colors don't change smoothly) | |
524 In particular I'm using vqscale=2:vhq:v4mv | |
525 | |
526 A: Try adding "vqcomp=0.7:vqblur=0.2:mpeg_quant" to lavcopts. | |
527 | |
528 Q: I tried your suggestion and it improved the image a little ... but not | |
529 enough. I was playing with different options and I couldn't find the way. | |
530 I suppose that the vob is not so good (watching it in TV trough the | |
531 computer looks better than my encoding, but it isn't a lot of better). | |
532 | |
533 A: Yes, those scenes with qscale=2 looks terrible :-( | |
534 | |
535 Try with vqmin=1 in addition to mpeg_quant:vlelim=-4:vcelim=-7 (and maybe | |
536 with "-sws 10 -ssf ls=1" to sharpen a bit the image) and read about vqmin=1 | |
537 in DOCS/tech/libavc-options.txt. | |
538 | |
539 If after the whole movie is encoded you still see the same problem, it will | |
540 means that the second pass didn't picked-up q=1 for this scene. Force q=1 | |
541 with the "vrc_override" option. | |
542 | |
543 Q: By the way, is there a special difficult in encode clouds or smoke? | |
544 | |
545 A: I would say it depends on the sharpness of these clouds / smokes and the | |
546 fact that they are mostly black/white/grey or colored. The codec will do | |
547 the right thing with vqmin=2 for example on a cigarette smoke (sharp) or on | |
548 a red/yellow cloud (explosion, cloud of fire). But may not with a grey and | |
549 very fuzzy cloud like in the chocolat scene. Note that I don't know exactly | |
550 why ;) | |
551 | |
552 A = Rémi | |
553 | |
554 |