Michael Niedermayer <[email protected]> added the comment:
On Mon, Mar 08, 2010 at 05:57:15PM +0000, Aleksey Nogin wrote:
>
> Aleksey Nogin <[email protected]> added the comment:
>
> > The bug this issue is about was a bug in LAME that was fixed
> > (probably in 3.98.3).
>
> You are mistaken. LAME did not have a bug - ffmpeg did (and still does), and
> LAME added a workaround.
>
> See
> http://sourceforge.net/tracker/?func=detail&aid=2553863&group_id=290&atid=100290
> - it fully identifies the issue:
>
> -- Date: 2009-03-24 13:49
> -- Sender: robert [Project Admin]
> --
> -- If I find some time, I'll add a workaround for the FFMPEG bug. Maybe
> -- it will be in 3.98.3, to be released sometime this year.
> --
> -- Note: FFMPEG seems to be calling lame_encode_flush in a loop,
> -- instead of once only.
>
> My patch fixes the "calling lame_encode_flush in a loop, instead of once only"
> issue correctly identified by LAME people as an ffmpeg bug.
>
> More from the LAME entry:
>
> -- Date: 2009-02-03 13:17
> -- Sender: robert [Project Admin]
> [...]
> -- it isn't really a bug inside LAME library, it's just not well
> -- documented in lame.h.
> [...]
>
> -- Date: 2009-02-02 13:13
> -- Sender: robert [Project Admin]
> --
> -- A negative return value signals a fatal error, in this case it
> -- signals "buffer too small".
>
> As I understand (have not actually looked at older versions of ffmpeg and
> LAME)
> - ffmpeg was (always?) using lame_encode_flush incorrectly, but it never
> resulted in anything user-visible until a change in 3.98.2 cause this
> incorrect
> usage to produce an error. In 3.98.3 LAME change again so that ffmpeg's
> incorrect usage is once again tolerated. I propose to fix the incorrect usage
> on
> the ffmpeg side.
ffmpeg followed the documented and implemented lame api
3.98.2 apparently changed the implementation (ABI and API breakage no matter
which API was intended originally, one just cant change it without a soname
bump and major version bump for libs following that standard versioning sheme)
about a workaround for the lame 3.98.2 behavior, iam not opposed to it
but your patch is buggy
and when we speak about rants and bugs, i really wish lame would return mp3
frames and not requires absolutely every application using it to either
generate broken files or parse the bytestream to find frame boundaries
or was that fixed recently? iam not following lame development really ...
it also would make things faster obviously ...
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.
________________________________________________
FFmpeg issue tracker <[email protected]>
<https://roundup.ffmpeg.org/issue803>
________________________________________________
