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