comparison DOCS/tech/encoding-tips.txt @ 29263:0f1b5b68af32

whitespace cosmetics: Remove all trailing whitespace.

29262:7d545a6b8aff

Let's further assume that the video is 100 minutes or 6000 seconds
long, encoded at 25fps (those nasty NTSC fps values give me
headaches. Adjust to your needs, of course!). This leaves you with
a video bitrate of:

                $videosize * 8 
$videobitrate = --------------
                $length * 1000

$videosize in bytes, $length in seconds, $videobitrate in kbit/s.
In my example I end up with $videobitrate = 895.

But the two things that have the most influence on quality are
vbitate and scale. Why? Because both together tell the codec how
many bits it may spend on each frame for each bit: and this is
the 'bpp' value (bits per pixel). It's simply defined as

         $videobitrate * 1000       
$bpp = -----------------------
       $width * $height * $fps

I've attached a small Perl script that calculates the $bpp for
a movie. You'll have to give it four parameters:

quantizers really lose quality. So if your distribution shows the
majority of quantizers at 4 and above then you should probably decrease
the resolution (you'll definitly see block artefacts).


Well... Several people will probably disagree with me on certain 
points here, especially when it comes down to hard values (like the
$bpp categories and the percentage of the quantizers used). But
the idea is still valid.

And that's why I think that there should NOT be presets in mencoder

You cannot do it without mathematics. Oh well, you can, but you'll
end up with movies that could certainly look better.

Now please shoot me if you have any complaints ;)

-- 
 ==> Ciao, Mosu (Moritz Bunkus)

===========
ANOTHER APPROACH: BITS PER BLOCK:

>          $videobitrate * 1000       
> $bpp = -----------------------
>        $width * $height * $fps

Well, I came to similar equation going through different route. Only I
didn't use bits per pixel, in my case it was bits per block (BPB). The block

scale down again in desesperate need of some bandwidth :)

In my experience, don't try to go below a width of 576 without closely
watching what's going on.

-- 
Rémi

===========
TIPS FOR ENCODING

I found myself that  4:3 B&W old movies are very hard  to compress well. In
addition to the 4:3 aspect ratio which  eats lots of bits, those movies are
typically very "noisy", which doesn't help at all. Anyway :

> After a few tries I am                                                        
> still a little bit disappointed with the video quality. Since it is a         
> "dark" movies, there is a lot of black on the pictures, and on the            
> encoded avi I can see a lot of annoying "mpeg squares". I am using            
> avifile codec, but the best I think is to give you the command line I         
> used to encode a preview of the result:                                       

>                                                                               
> First pass:                                                                   
> mencoder TITLE01-ANGLE1.VOB -oac copy -ovc lavc -lavcopts                     
> vcodec=mpeg4:vhq:vpass=1:vbitrate=800:keyint=48 -ofps 23.976 -npp lb          
> -ss 2:00 -endpos 0:30 -vf scale -zoom -xy 640 -o movie.avi                   

1) keyint=48 is way too low. The  default value is 250, this is in *frames*
not seconds. Keyframes are significantly larger than P or B frames, so the
less keyframes you have, better the overall movie will be. (huh, like Yoda
I  speak ;).  Try keyint=300  or  350. Don't  go  beyond that  if you  want

lumi_mask=0.13:dark_mask=0.16:naq:
Be warned that these options are really experimental and the result
could be very good or very bad depending on your visualization device
(computer CRT, TV or TFT screen). Don't push too hard these options.

> Second pass:                                                                  
> the same with vpass=2                                                         

7) I've found  that lavc gives better  results when the first  pass is done
with  "vqscale=2" instead  of a  target bitrate.  The statistics  collected
seems to be more precise. YMMV.

> I am new to mencoder, so please tell me any idea you have even if it          
> obvious. I also tried the "gray" option of lavc, to encode B&W only,          
> but strangely it gives me "pink" squares from time to time.                   

Yes, I've seen  that too. Playing the resulting file  with "-lavdopts gray"
fix the problem but it's not very nice ...

> So if you could tell me what option of mencoder or lavc I should be           
> looking at to lower the number of "squares" on the image, it would be         
> great. The version of mencoder i use is 0.90pre8 on a macos x PPC             
> platform. I guess I would have the same problem by encoding anime             
> movies, where there are a lot of region of the image with the same            
> color. So if you managed to solve this problem...                             

You could  also try the  "mpeg_quant" flag. It  selects a different  set of
quantizers and produce  somewhat sharper pictures and less  blocks on large
zones with the same or similar luminance, at the expense of some bits.

> This is completely off topic, but do you know how I can create good           
> subtitles from vobsub subtitles ? I checked the -dumpmpsub option of          
> mplayer, but is there a way to do it really fast (ie without having to        
> play the whole movie) ?                                                       

I didn't  find a way under  *nix to produce reasonably  good text subtitles
from vobsubs. OCR  *nix softwares seems either not suited  to the task, not
powerful enough or both. I'm extracting the vobsub subtitles and simply use
them with the .ogm

    mencoder -ovc copy -oac copy -o /dev/null -sid $f -vobsubout sous-titres
+-vobsuboutindex $f -ifo vts_01_0.ifo stream.dump
done

(and yes, I've a DVD with 12 subtitles)
--                                                                              
Rémi


================================================================================


TIPS FOR SMOKE & CLOUDS 

Q: I'm trying  to encode Dante's Peak and I'm  having problems with clouds,
fog and  smoke: They don't  look fine  (they look very  bad if I  watch the
movie  in TV-out).  There are  some artifacts,  white clouds  looks as  snow
mountains, there are things likes hip in the colors so one can see frontier

can understand me, I want to mean that the colors don't change smoothly)
In particular I'm using vqscale=2:vhq:v4mv

A: Try adding "vqcomp=0.7:vqblur=0.2:mpeg_quant" to lavcopts.

Q: I tried your suggestion and it  improved the image a little ... but not 
enough. I was playing with different  options and I couldn't find the way. 
I  suppose that  the vob  is not  so good  (watching it  in TV  trough the 
computer looks better than my encoding, but it isn't a lot of better).     

A: Yes, those scenes with qscale=2 looks terrible :-(

Try with  vqmin=1 in addition to  mpeg_quant:vlelim=-4:vcelim=-7 (and maybe
with "-sws 10 -ssf ls=1" to sharpen a bit the image) and read about vqmin=1

================================================================================


TIPS FOR TWEAKING RATECONTROL

(For the purpose of this explanation, consider "2nd pass" to be any beyond 
the 1st. The algorithm is run only on P-frames; I- and B-frames use QPs 
based on the adjacent P. While x264's 2pass ratecontrol is based on lavc's, 
it has diverged somewhat and not all of this is valid for x264.)

Consider the default ratecontrol equation in lavc: "tex^qComp".
At the beginning of the 2nd pass, rc_eq is evaluated for each frame, and 
the result is the number of bits allocated to that frame (multiplied by 
some constant as needed to match the total requested bitrate).

"tex" is the complexity of a frame, i.e. the estimated number of bits it 
would take to encode at a given quantizer. (If the 1st pass was CQP and 
not turbo, then we know tex exactly. Otherwise it is calculated by 
multiplying the 1st pass's bits by the QP of that frame. But that's not 
why CQP is potentially good; more on that later.)
"qComp" is just a constant. It has no effect outside the rc_eq, and is 
directly set by the vqcomp parameter.

If vqcomp=1, then rc_eq=tex^1=tex, so 2pass allocates to each frame the 
number of bits needed to encode them all at the same QP.
If vqcomp=0, then rc_eq=tex^0=1, so 2pass allocates the same number of 
bits to each frame, i.e. CBR. (Actually, this is worse than 1pass CBR in 
terms of quality; CBR can vary within its allowed buffer size, while 
vqcomp=0 tries to make each frame exactly the same size.)
If vqcomp=0.5, then rc_eq=sqrt(tex), so the allocation is somewhere 
between CBR and CQP. High complexity frames get somewhat lower quality 
than low complexity, but still more bits.

While the actual selection of a good value of vqcomp is experimental, the 
following underlying factors determine the result:
Arguing towards CQP: You want the movie to be somewhere approaching 
constant quality; oscillating quality is even more annoying than constant 
low quality. (However, constant quality does not mean constant PSNR nor 
constant QP. Details are less noticeable in high-motion scenes, so you can 
get away with somewhat higher QP in high-complexity frames for the same 
perceived quality.)
Arguing towards CBR: You get more quality per bit if you spend those bits 
in frames where motion compensation works well (which tends to be 
correlated with "tex"): A given artifact may stick around several seconds 
in a low-motion scene, and you only have to fix it in one frame to improve 
the quality of the whole sequence.

Now for why the 1st pass ratecontrol method matters:
The number of bits at constant quant is as good a measure of complexity as
any other simple formula for the purpose of allocating bits. But it's not

29263:0f1b5b68af32

Let's further assume that the video is 100 minutes or 6000 seconds
long, encoded at 25fps (those nasty NTSC fps values give me
headaches. Adjust to your needs, of course!). This leaves you with
a video bitrate of:

                $videosize * 8
$videobitrate = --------------
                $length * 1000

$videosize in bytes, $length in seconds, $videobitrate in kbit/s.
In my example I end up with $videobitrate = 895.

But the two things that have the most influence on quality are
vbitate and scale. Why? Because both together tell the codec how
many bits it may spend on each frame for each bit: and this is
the 'bpp' value (bits per pixel). It's simply defined as

         $videobitrate * 1000
$bpp = -----------------------
       $width * $height * $fps

I've attached a small Perl script that calculates the $bpp for
a movie. You'll have to give it four parameters:

quantizers really lose quality. So if your distribution shows the
majority of quantizers at 4 and above then you should probably decrease
the resolution (you'll definitly see block artefacts).


Well... Several people will probably disagree with me on certain
points here, especially when it comes down to hard values (like the
$bpp categories and the percentage of the quantizers used). But
the idea is still valid.

And that's why I think that there should NOT be presets in mencoder

You cannot do it without mathematics. Oh well, you can, but you'll
end up with movies that could certainly look better.

Now please shoot me if you have any complaints ;)

--
 ==> Ciao, Mosu (Moritz Bunkus)

===========
ANOTHER APPROACH: BITS PER BLOCK:

>          $videobitrate * 1000
> $bpp = -----------------------
>        $width * $height * $fps

Well, I came to similar equation going through different route. Only I
didn't use bits per pixel, in my case it was bits per block (BPB). The block

scale down again in desesperate need of some bandwidth :)

In my experience, don't try to go below a width of 576 without closely
watching what's going on.

--
Rémi

===========
TIPS FOR ENCODING

I found myself that  4:3 B&W old movies are very hard  to compress well. In
addition to the 4:3 aspect ratio which  eats lots of bits, those movies are
typically very "noisy", which doesn't help at all. Anyway :

> After a few tries I am
> still a little bit disappointed with the video quality. Since it is a
> "dark" movies, there is a lot of black on the pictures, and on the
> encoded avi I can see a lot of annoying "mpeg squares". I am using
> avifile codec, but the best I think is to give you the command line I
> used to encode a preview of the result:

>
> First pass:
> mencoder TITLE01-ANGLE1.VOB -oac copy -ovc lavc -lavcopts
> vcodec=mpeg4:vhq:vpass=1:vbitrate=800:keyint=48 -ofps 23.976 -npp lb
> -ss 2:00 -endpos 0:30 -vf scale -zoom -xy 640 -o movie.avi

1) keyint=48 is way too low. The  default value is 250, this is in *frames*
not seconds. Keyframes are significantly larger than P or B frames, so the
less keyframes you have, better the overall movie will be. (huh, like Yoda
I  speak ;).  Try keyint=300  or  350. Don't  go  beyond that  if you  want

lumi_mask=0.13:dark_mask=0.16:naq:
Be warned that these options are really experimental and the result
could be very good or very bad depending on your visualization device
(computer CRT, TV or TFT screen). Don't push too hard these options.

> Second pass:
> the same with vpass=2

7) I've found  that lavc gives better  results when the first  pass is done
with  "vqscale=2" instead  of a  target bitrate.  The statistics  collected
seems to be more precise. YMMV.

> I am new to mencoder, so please tell me any idea you have even if it
> obvious. I also tried the "gray" option of lavc, to encode B&W only,
> but strangely it gives me "pink" squares from time to time.

Yes, I've seen  that too. Playing the resulting file  with "-lavdopts gray"
fix the problem but it's not very nice ...

> So if you could tell me what option of mencoder or lavc I should be
> looking at to lower the number of "squares" on the image, it would be
> great. The version of mencoder i use is 0.90pre8 on a macos x PPC
> platform. I guess I would have the same problem by encoding anime
> movies, where there are a lot of region of the image with the same
> color. So if you managed to solve this problem...

You could  also try the  "mpeg_quant" flag. It  selects a different  set of
quantizers and produce  somewhat sharper pictures and less  blocks on large
zones with the same or similar luminance, at the expense of some bits.

> This is completely off topic, but do you know how I can create good
> subtitles from vobsub subtitles ? I checked the -dumpmpsub option of
> mplayer, but is there a way to do it really fast (ie without having to
> play the whole movie) ?

I didn't  find a way under  *nix to produce reasonably  good text subtitles
from vobsubs. OCR  *nix softwares seems either not suited  to the task, not
powerful enough or both. I'm extracting the vobsub subtitles and simply use
them with the .ogm

    mencoder -ovc copy -oac copy -o /dev/null -sid $f -vobsubout sous-titres
+-vobsuboutindex $f -ifo vts_01_0.ifo stream.dump
done

(and yes, I've a DVD with 12 subtitles)
--
Rémi


================================================================================


TIPS FOR SMOKE & CLOUDS

Q: I'm trying  to encode Dante's Peak and I'm  having problems with clouds,
fog and  smoke: They don't  look fine  (they look very  bad if I  watch the
movie  in TV-out).  There are  some artifacts,  white clouds  looks as  snow
mountains, there are things likes hip in the colors so one can see frontier

can understand me, I want to mean that the colors don't change smoothly)
In particular I'm using vqscale=2:vhq:v4mv

A: Try adding "vqcomp=0.7:vqblur=0.2:mpeg_quant" to lavcopts.

Q: I tried your suggestion and it  improved the image a little ... but not
enough. I was playing with different  options and I couldn't find the way.
I  suppose that  the vob  is not  so good  (watching it  in TV  trough the
computer looks better than my encoding, but it isn't a lot of better).

A: Yes, those scenes with qscale=2 looks terrible :-(

Try with  vqmin=1 in addition to  mpeg_quant:vlelim=-4:vcelim=-7 (and maybe
with "-sws 10 -ssf ls=1" to sharpen a bit the image) and read about vqmin=1

================================================================================


TIPS FOR TWEAKING RATECONTROL

(For the purpose of this explanation, consider "2nd pass" to be any beyond
the 1st. The algorithm is run only on P-frames; I- and B-frames use QPs
based on the adjacent P. While x264's 2pass ratecontrol is based on lavc's,
it has diverged somewhat and not all of this is valid for x264.)

Consider the default ratecontrol equation in lavc: "tex^qComp".
At the beginning of the 2nd pass, rc_eq is evaluated for each frame, and
the result is the number of bits allocated to that frame (multiplied by
some constant as needed to match the total requested bitrate).

"tex" is the complexity of a frame, i.e. the estimated number of bits it
would take to encode at a given quantizer. (If the 1st pass was CQP and
not turbo, then we know tex exactly. Otherwise it is calculated by
multiplying the 1st pass's bits by the QP of that frame. But that's not
why CQP is potentially good; more on that later.)
"qComp" is just a constant. It has no effect outside the rc_eq, and is
directly set by the vqcomp parameter.

If vqcomp=1, then rc_eq=tex^1=tex, so 2pass allocates to each frame the
number of bits needed to encode them all at the same QP.
If vqcomp=0, then rc_eq=tex^0=1, so 2pass allocates the same number of
bits to each frame, i.e. CBR. (Actually, this is worse than 1pass CBR in
terms of quality; CBR can vary within its allowed buffer size, while
vqcomp=0 tries to make each frame exactly the same size.)
If vqcomp=0.5, then rc_eq=sqrt(tex), so the allocation is somewhere
between CBR and CQP. High complexity frames get somewhat lower quality
than low complexity, but still more bits.

While the actual selection of a good value of vqcomp is experimental, the
following underlying factors determine the result:
Arguing towards CQP: You want the movie to be somewhere approaching
constant quality; oscillating quality is even more annoying than constant
low quality. (However, constant quality does not mean constant PSNR nor
constant QP. Details are less noticeable in high-motion scenes, so you can
get away with somewhat higher QP in high-complexity frames for the same
perceived quality.)
Arguing towards CBR: You get more quality per bit if you spend those bits
in frames where motion compensation works well (which tends to be
correlated with "tex"): A given artifact may stick around several seconds
in a low-motion scene, and you only have to fix it in one frame to improve
the quality of the whole sequence.

Now for why the 1st pass ratecontrol method matters:
The number of bits at constant quant is as good a measure of complexity as
any other simple formula for the purpose of allocating bits. But it's not