[MPlayer-users] Which codec is fast and good?

[Rainer Hantsch]

Hi!

Yesterday I gave pp=tn a chance - because of the hint of Matthias Wieser.

o  The first thing I recognized is that it causes much less CPU load. My
   Celeron-1700 was running at 95-100% with 'denoise3d' but it was
   somewhere around 50-70% (mostly 60%) with pp=tn.
   A good optimization.

o  But I also found out that the resulting avi file (encoding with divx)
   was much bigger. This will surely be because of that what Richard Felker
   means below.
   Recording 2:05:00 of TV in 640x400 (I recorded StarGate for testing),
   resulted in 4.8 GB File size !!! This would have been somewhere at 3.5GB
   with 'denoise3d', I estimate, based on earlier tests with 1 minute
   recordings.
   So this is possibly a problem in turn. - Today I watch the quality and
   then decide which one I use...


Another big problem arose after this test-recording:
----------------------------------------------------
o  Because the only _working_ software with GUI which can cut DivX/avi
   files is on Windoze, I tried to transfer this huge 4.8 GB file from the
   Linux machine to my son's Win98 machine, where this tool is installed.
   The transfer was done using nfs and Linux onto a mounted 2nd HDD with
   FAT32.
   Result: The transfer aborts after exactly 2GB filesize. Does FAT32
           support no files bigger than 2GB? :-/

o  Because of the above, I am (again) asking, if mencoder can automatically
   record into a set of files instead of only one. If not, this will be a
   big suggestion to the developers!
   mencoder should get an option to automatically enumerate output files
   and continue with a new one, whenever a given filesize is reached. So I
   would get 5 1GB Files instead of 1 5GB file, and all problems with too
   big files are gone.

   A workaround like watching the file with an external daemon, aborting
   mencoder when a given size is reached and re-launching it with a new
   output name is NOT acceptable, because this causes a loss of multiple
   frames.


-- 

On Wed, 27 Aug 2003, D Richard Felker III wrote:
| On Wed, Aug 27, 2003 at 11:45:55AM +0200, Matthias Wieser wrote:
| > Am Mittwoch, 27. August 2003 08:56 schrieb Rainer Hantsch:
| >
| > > About "denoise3d":
| > > I do not "want" it as a "must". I got it suggested, so I use it. It
| > > will surely cause additional system load, but as long as the CPU is
| > > below 100%... Anyway, CPU far below 100% would be better, but I could
| > > not find a description of denoise3d and its options...
| >
| > -vf pp=tn
| > should do similar things. But it's much faster.
|
| pp=tn should not be used. Ever. It's broken by design. It selectively
| turns the noise filter on or off on a per-block basis (8x8 blocks) so
| it will ADD blocking artifacts to your movie. :(
|
| > And does one of those two deinterlacing filters have an advantage over the
| > other?
| > -vf lavcdeint
| > or
| > -vf pp=fd
|
| They are identical. lavcdeint was supposed to be removed but no one
| ever bothered. Actually lavcdeint calls libavcodec's deinterlace
| function, while pp=fd implements the same thing in the libpostproc
| framework.
|
| > "Mplayer -vf help" says that the first one uses "libavcodec's
| > deinterlacing filter" and "mplayer -pphelp" says that the second uses
| > "ffmpeg deinterlacer". What's the difference?
|
| pp=fd is probably faster; otherwise, nothing. Both will create an
| 'embossed' looking ghost outline when the two fields differ by any
| significant amount, though, so imo this deinterlacer should be
| avoided.
|
| Rich


mfg

  Ing. Rainer Hantsch