Aleksey Nogin <[email protected]> added the comment: > you miss a point in your rant, your code is broken you return random > data completely independant of the bug or not bug issue.
No, I got your point the first time - the problem is that is not what my code is doing and you do not seem to be willing to even give me enough benefit of the doubt to listen to what I have to say. Please for once read *all* the following points: 1. Existing ffmpeg code keeps calling lame_encode_flush() repeatedly in am almost infinite loop (both LAME guys and I say this!) - until lame_encode_flush returns 0 enough times for all the frames in the buffer to be copies out. 2. In lame 3.98.2, lame_encode_flush() on already flushed lame session returns *two* frames (yes, this could be considered a bug). ffmpeg code would move only one frame out of the buffer, so on every iteration of the "infinite" loop, the buffer grows by one frame, and eventually overflows no matter how big it was. 3. My patch contains three *separate* portions: a. The main fix: do not call lame_encode_flush() more than once in a row. Ought to be a no-brainer. b. Extra safety & optimization: right after calling lame_encode_flush() (and only then!) copy the whole buffer out, regradless of how many frames are in it. c. Extra safety: if mp3len returns a negative number (indicating an error), do not do incorrect memmoves based on that negative number. 4. I completely understand that copying the buffer out could result in incomplete/broken frames being copied out. But I am only doing that right after lame_encode_flush() - at that point the frames must be complete! 5. Note that my fix "b" is only really a minor optimization. If you are still uncomfortable with it, please feel free to disregard and apply only the first part of the fix. ________________________________________________ FFmpeg issue tracker <[email protected]> <https://roundup.ffmpeg.org/issue803> ________________________________________________
