[MEncoder-users] lowres=3 with HD, docs, and weak CPUs

[Ilya Zakharevich]

[A complimentary Cc of this posting was NOT [per weedlist] sent to
Carl Eugen Hoyos 
<mencoder-users at mplayerhq.hu>], who wrote in article <loom.20100725T235402-788 at post.gmane.org>:
> > Anyway, I picked up this command line from Internet - it was
> > recommended as default for HD movies on weak machines.

> The useful lines (if your goal is to decode "faster") are:
> mplayer file -lavdopts skiploopfilter=all
> (10% faster depending on video, usually no visual difference)
> mplayer file -lavdopts skipframe=nonref:skiploopfilter=all
> (significantly faster, please read the documentation for more details)

Documentation is not helpful.  E.g., my default options include
-autosync 30 -framedrop.  What is the interaction with skipframe=nonref?

What one would assume from documentation is that -framedrop is a
better version of skipframe=nonref (B frames are skipped only when CPU
is stressed).  (I ignore here the last-P frame, which is also nonref,
but probably not involved in -framedrop.)

What I actually see is that -framedrop has practically no effect.  What gives?

===

The recipe I actually saw was

  mplayer -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all !

So do you recommend

  mplayer -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all:skipframe=nonref !

with the latest SVN, where lowres=1 is working when supported?  I mean
recommend as "a starting point; delete image-degrading speedups which
are not needed on your machine"...

> > I presume it worked for *somebody*.  Does not necessarily follows, I know...

> But not with r25844.

Well, I do not agree.  It was working fine with r25844.

It might have been *ignored*, but given the conveniently missing
documentation, how would people know?  (At least I see no mention of
the *output* resolution changed when this option is recognized.)

Thanks,
Ilya

P.S. BTW, why http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.html is
     empty?  One is forced to use
     http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.txt, which is
     served with wrong encoding.  (No encoding supplied, when it is
     not iso-8859-1.)



[A complimentary Cc of this posting was NOT [per weedlist] sent to
Carl Eugen Hoyos 
<mencoder-users at mplayerhq.hu>], who wrote in article <loom.20100725T235402-788 at post.gmane.org>:
> Ilya Zakharevich <nospam-abuse <at> ilyaz.org> writes:
> 
> > > If you think I am wrong (= you have a MPlayer version and a H.264 video were
> > > lowres is correctly supported), please provide full, uncut output (and the
> > > video) so I can reproduce it.
> > 
> > r30994 crashes, r25844 does not.  If this is not a regression, then I
> > do not know what is.
> 
> I just tested r25844: It does not crash with lowres (as latest svn that does not
> crash either) and lowres simply does not work (while it does work for the
> supported decoders in latest svn) - so, no, I still don't see a regression.
> 
> > Anyway, I picked up this command line from Internet - it was
> > recommended as default for HD movies on weak machines.
> 
> The useful lines (if your goal is to decode "faster") are:
> mplayer file -lavdopts skiploopfilter=all
> (10% faster depending on video, usually no visual difference)
> mplayer file -lavdopts skipframe=nonref:skiploopfilter=all
> (significantly faster, please read the documentation for more details)
> 
> > I presume it worked for *somebody*.  Does not necessarily follows, I know...
> 
> But not with r25844.
> 
> Carl Eugen

Newsgroups: gmane.comp.video.mencoder.user
Subject: Re: Another new (?) regression: lowres=3 with HD
Summary:
Expires:
References: <i2336s$327$1 at dough.gmane.org> <loom.20100723T095809-284 at post.gmane.org> <i2h8ef$7i8$1 at dough.gmane.org> <loom.20100725T235402-788 at post.gmane.org>
Sender: Ilya Zakharevich <nospam-abuse at ilyaz.org>
From:  Ilya Zakharevich <nospam-abuse at ilyaz.org>
Followup-To:
User-Agent: trn [how to get a version via %-escapes???] with a custom header
Distribution: 
Organization: U.C. Berkeley Math. Department.
X-How-To-Reach-Me: The From: address is valid
X-How-To-Disable-Cc: Put in the headers the line: Mail-Copies-To: never
Keywords: 
Bcc: ilya
Cc:

[A complimentary Cc of this posting was NOT [per weedlist] sent to
Carl Eugen Hoyos 
<mencoder-users at mplayerhq.hu>], who wrote in article <loom.20100725T235402-788 at post.gmane.org>:
> > Anyway, I picked up this command line from Internet - it was
> > recommended as default for HD movies on weak machines.

> The useful lines (if your goal is to decode "faster") are:
> mplayer file -lavdopts skiploopfilter=all
> (10% faster depending on video, usually no visual difference)
> mplayer file -lavdopts skipframe=nonref:skiploopfilter=all
> (significantly faster, please read the documentation for more details)

Documentation is not helpful.  E.g., my default options include
-framedrop.  What is the interaction with skipframe=nonref?

What one would assume from documentation is that -framedrop is a
better version of skipframe=nonref (they are skipped only when CPU is
stressed).  (I ignore here the last-P frame, which is also nonref, but
probably not involved in -framedrop.)

 [What I see is that -framedrop has practically no effect.  What gives?]

===

The recipe I actually saw was

  mplayer -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all !

So do you recommend

  mplayer -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all:skipframe=nonref !

with the latest SVN, where lowres=1 is working when supported?  I mean
recommend as "a starting point; delete image-degrading speedups which
are not needed on your machine"...

> > I presume it worked for *somebody*.  Does not necessarily follows, I know...

> But not with r25844.

Well, I do not agree.  It was working fine with r25844.

It might have been *ignored*, but given the conveniently missing
documentation, how would people know?  (At least I see no mention in
the docs of the *output* resolution changed when this option is
recognized.)

Thanks,
Ilya

P.S. BTW, why http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.html is
     empty?  One is forced to use
     http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.txt, which is
     served with wrong encoding.  (No encoding supplied, when it is
     not iso-8859-1.)