[MPlayer-dev-eng] -lameopts: conflicting documentation and code?

Ivan Kalvachev ivan at cacad.com
Fri Feb 20 11:20:17 CET 2004


Corey Hickey said:
> D Richard Felker III wrote:
>> On Thu, Feb 19, 2004 at 01:37:57AM -0300, Diego Biurrun wrote:
>>
>>>Charles Wilcox writes:
>>> > The man page and HTML documentation say that they q= value can be set
>>> from
>>> >  to 9, the equivalent of the same option of Lame.  However, this is
>>> not
>>> > the case of what happens.  mencoder.c:986 has a line that adds one
>>> onto
>>> > the value specified before it is sent off to libmp3lame.  This is
>>> > complicated by the fact that cfg-mencoder.h:25 says that the input is
>>> > indeed in the  to 9 range.  Also, the code makes no effort to check
>>> to
>>> > see if the resulting value is 10, which is an incorrect value to pass
>>> on.
>>> >
>>> > Considering all the docs imply this option should match up to what
>>> LAME
>>> > would normally take, could this possibly be a error in the code?
>>> Taking a
>>> > cursory glance at the lame code in frontend/parse.c:1626, it does not
>>> alter
>>> > the value before it calls lame_set_VBR_q.
>>> >
>>> > Sorry, I'm just learning how to use Mencoder, but I've used Lame
>>> > extensively, and this inconsistency confuses me.  Is there a reason
>>> it it
>>> > like this?  If so, there is no warning to those who'd assume that the
>>> VBR
>>> > quality numbers mean the same thing.  (That, and it just doesn't make
>>> any
>>> > sense to me.)  If this is a mistake... wow, I guess not many people
>>> > specify -lameopts to have caught this.
>>>
>>>Sounds like you found a real bug, could you come up with a patch that
>>>fixes it, please?
>>
>>
>> IMO this is a difficult issue. I wanted to fix it a long time ago, but
>> changing the behavior is not acceptible under mplayer policy afaik...
>>
>> Rich
>>
>
> I thought this sounded familiar:
> http://www1.mplayerhq.hu/pipermail/mplayer-dev-eng/2003-March/016742.html
>
> For what it's worth, I'd vote for it being changed.
So do I.
It's a bug and it should be fixed.
We are not M$ too keep compability with bugs ;))
And if I understand right nobody knows about this +1,
it is not documented, so scripts cannot obbey on it!

Best Regards
   Ivan Kalvachev
  iive




More information about the MPlayer-dev-eng mailing list