[MPlayer-users] Re: encoding quality - bpp, resolution, quants and quality

[D Richard Felker III]

On Tue, Sep 09, 2003 at 07:20:08PM +0200, Matthias Wieser wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> Am Dienstag, 9. September 2003 15:33 schrieb Tuukka Toivonen:
> 
> > Just a comment: I've recently experimented encoding PAL video (768x576
> 
> Video or TV? TV normally has more noise. Denoise3d should help.
> 
> > at 25 fps scaled down to 352x288, 640x480, or not at all) and with 1.2
> > Mbit/s (0.109-0.156) it was totally unacceptable quality to me (except
> > when scaling down to 352x288, but that's somewhat low resolution). So
> > now I'm scaling to 640x480 and coding at 2 Mbit/s (0.26 bpp). Even with
> > this bitrate 640x480 appears to be better than unscaled size.
> 
> Those bpp values are probably thought for two-pass encoding. If you only 
> use "vhq" then you need more bpp than if you use 
> "vhq:precmp=2:cmp=2:subcmp=2:trell".

If you want max quality/compression for live recording, you should
record to a lossless format first (or perhaps vqscale=1) then do a
2pass encode later with denoising to make a copy at reasonable size
for archival use.

> > Is there a reason you are using Xvid instead of ffmpeg's MPEG-4 coder? 
> > I thought the latter would be better, or is there significant
> > difference anyway?
> 
> The latter _was_ better. Ther are no recent comparisons between both but  
> Xvid is better than many other modern codecs, so Xvid has probably become 
> better than libavc.

Doubtful. You could try a comparison (PSNR or better yet double-blind
:), but it's generally accepted by mplayer developers that lavc is the
encoder of choice...

> > Have you experimented whether -sws 2 or 9 is better (or something
> > else?). I'm using 9, I suppose it should be better in theory?
> 
> Do you mean, 9 should be sharper? If so, then that may be bad because more 
> bit/s are needed.
> 
> If sws 2 is faster I would choose that and 
> vcodec=[...]vhq:precmp=2:cmp=2:subcmp=2 which produces better files than 
> only vhq or vhq:v4mv.

Yes, agreed!

Rich