[MPlayer-DOCS] CVS: main/DOCS/man/en mplayer.1,1.753,1.754

Loren Merritt lorenm at u.washington.edu
Tue Sep 28 00:19:19 CEST 2004


On Mon, 27 Sep 2004, Guillaume POIRIER wrote:

> Le lun 27/09/2004 à 23:04, Ivan Kalvachev CVS a écrit :
>> CVS change done by Ivan Kalvachev CVS
>>
>> Update of /cvsroot/mplayer/main/DOCS/man/en
>> In directory mail:/var2/tmp/cvs-serv24022/DOCS/man/en
>>
>> Modified Files:
>> 	mplayer.1
>> Log Message:
>> better default parameter, added counterpart option, better names for 
>> few options, 3-pass support and improved documentation.
>> patch by Loren Merritt
>
> It looks like the manpage patch lacks 3-pass encode documentation
> for x264.
> Before sending in a patch for the manpage, I'd like to know if
> the principle is the same as for "simple" MPEG-4.
> So should we suggest users to disable subq, deblock*, fullinter...
> (these are only examples, they have a great chance to be wrong,
> as it's not my day today)

Yes, it's the same principle, though I don't haven't done any test on what 
can be safely disabled.

subq, deblock, and fullinter are good candidates. (That's disabling 
deblock entirely. There's no point in using different deblock thresholds 
for the first pass.)
cabac probably shouldn't be disabled. I don't know how evenly distributed 
the compression gains are.
frameref is slow, but it greatly improves some frames while not affecting 
most others, so it's also probably not a good candidate.

I note that x264 3-pass encoding is sometimes lower PSNR than 2-pass. 
That is a problem with its 2-pass ratecontrol in general, not something 
caused by the 3rd pass. (The 3rd pass is closer to the planned 
distribution, but the planning is suboptimal.)

You might also try using constant QP for the first pass. CBR is pretty 
much only good for when you really need CBR.

--Loren Merritt


More information about the MPlayer-DOCS mailing list