[MPlayer-DOCS] [PATCH] XviD documentation reaching almost completeness

Guillaume POIRIER guillaume.poirier at ifsic.univ-rennes1.fr
Tue Sep 7 18:42:36 CEST 2004


Le mar 07/09/2004 à 17:40, The Wanderer a écrit :
> Guillaume POIRIER wrote:

> >>> +.B frame_drop_ratio=<0\-100>
> >>> +XviD keeps track of block coding type (skipped, predicted, intra).
> >>> +The skipped block counter can be used to choose whether a frame is so close
> >>> +to its reference that it can be
> >> 
> >> I don't think "choose" is the verb you want in this case... but I
> >> don't know what would be better. Diego? Any ideas?
> > 
> > I replaced it with "decide". I'm not sure if it makes a world of 
> > difference though.
> 
> No, it doesn't; that was one of the alternates I'd considered and
> rejected as no better. The problem, if I understand the description
> correctly (and if not it probably does need rephrasing), is that the
> counter itself is not the thing doing the choosing, or the deciding; it
> simply affects the thing which does make the decision. As I said, I
> don't know what would be good to use in this context; I think it will
> probably have to be corrected post-commit.

I just can't find much informations on this setting... Most people say:
don't touch! ... unless you're a developer.
So how about documenting frame_drop_ratio that way:
.B frame_drop_ratio=<0\-100>
Don't touch! ;-) ...
if you do, you'll probably screw up your video.
If it doesn't, tell us how to use this parameter, and send a patch! ;-)


Ok, I'm just fooling around... This thread is just getting too darn
long!

> > +.TP
> > +.B bf_threshold=<-255\-255>
> > +Sometimes B frames do not look good, and introduce artifacts when most of
> > +the frame is static and some small zones have high motion (in a static
> > +scene with a man talking, his mouth will probably look bad if what is
> > +surrounding the man and his mouth is completely static).
> > +This setting allows you to specify what priority to place on the use of
> > +B frames.
> > +This setting allows you to favorize or not, the use of B frames.
> 
> Ooops. Both phrasings are here. Looks like you added the new version,
> but forgot to delete the old one.

Corrected.

> > +.B curve_compression_high=<0\-100>
> > +This setting control how much the upper part of the curve has to get
> > +closer to the average bitrate value.
> 
> "controls"
> 
> Same thing immediately following, as before.

Those description have been all written again. Please check the patch.

> 
> > +.B overflow_control_strength=<0\-100>
> > +During pass 1 of 2-pass encoding, a scaled bitrate curve is computed.
> > +The difference between that expected curve and the result obtained during
> > +encoding is called overflow.
> > +Obviously, the two pass Rate Controller tries to compensate for that overflow
> > +distributing, it over next frames to be encoded.
> 
> Sorry, either I mistyped or you misinterpreted me. The comma goes before
> "distributing", not after it - the comma should go immediately after the
> final occurrence of "overflow".

Thanks. I should have noticed. I'm getting tired. :-(

> 
> > +.B max_overflow_improvement=<0\-100>
> > +During the frame bit allocation, overflow control may increase the frame
> > +size.
> > +This parameter controls how much the overflow control is allowed to
> > +increase the frame size in percent compared to the ideal curve allocation
> > +(default: 5).
> 
> Hmmm. This doesn't look right, somehow; I think it's mainly the
> placement of the bit about "percent". How about "This parameter
> specifies the maximum percentage by which the overflow control is
> allowed to increase the frame size, compared to the ideal curve
> allocation"? That's not necessarily perfect, but I don't understand the
> technical side of this well enough to suggest further changes and be
> sure they won't break the meaning.
> 
> The following option, being phrased almost identically, has the same
> problem.

Corrected your way for it's a lot clearer.

All changes are in the attached (round 9) patch...

Regards,

Guillaume

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer1.0-20040906-en_man_xvid_1.0.x_options_round9.patch
Type: text/x-patch
Size: 10497 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-docs/attachments/20040907/9f7ef7fd/attachment.bin>


More information about the MPlayer-DOCS mailing list