[FFmpeg-devel] [PATCH] avcodec/libmp3lame: properly handle unaligned frame data

[Paul B Mahol]

On 5/1/17, Muhammad Faiz <mfcc64 at gmail.com> wrote:
> On Tue, May 2, 2017 at 1:05 AM, Paul B Mahol <onemda at gmail.com> wrote:
>> On 5/1/17, Muhammad Faiz <mfcc64 at gmail.com> wrote:
>>> On Tue, May 2, 2017 at 12:45 AM, Paul B Mahol <onemda at gmail.com> wrote:
>>>> On 5/1/17, Muhammad Faiz <mfcc64 at gmail.com> wrote:
>>>>> On Mon, May 1, 2017 at 11:22 PM, Kyle Swanson <k at ylo.ph> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Mon, May 1, 2017 at 3:18 AM, Paul B Mahol <onemda at gmail.com> wrote:
>>>>>>> On 4/30/17, Nicolas George <george at nsup.org> wrote:
>>>>>>>> Le primidi 11 floreal, an CCXXV, Muhammad Faiz a ecrit :
>>>>>>>>> Are you working on these? Because currently I'm not.
>>>>>>>>
>>>>>>>> There is nothing to work on yet: the message you answer to is
>>>>>>>> raising
>>>>>>>> a
>>>>>>>> question about the global design of the internal API. That question
>>>>>>>> needs an answer before any work can be done, and I can not decide
>>>>>>>> alone.
>>>>>>>>
>>>>>>>
>>>>>>> How nice, introducing bug that causes crash and then claiming there
>>>>>>> is
>>>>>>> not such bug.
>>>>>>>
>>>>>>> Which filters you consider deemed worthy to not crash?
>>>>>>> _______________________________________________
>>>>>>> ffmpeg-devel mailing list
>>>>>>> ffmpeg-devel at ffmpeg.org
>>>>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>>>>
>>>>>> Maybe 383057f8e744efeaaa3648a59bc577b25b055835 should be reverted
>>>>>> until API stuff is sorted. This should also be backported to 3.3
>>>>>> because these issues are present in that release.
>>>>>>
>>>>>> Kyle
>>>>>
>>>>> Of course no. Reverting it will make more bug.
>>>>>
>>>>> Unless
>>>>> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-January/206285.html
>>>>> and
>>>>> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-January/206284.html
>>>>> are also applied.
>>>>
>>>> One of those are already reviewed, other looks like is not needed at
>>>> all.
>>>> Could you elaborate why it is needed?
>>>
>>> The code before the patch write to unwritable frame.
>>>
>>> test-case:
>>> ffplay -i lavfi 'aevalsrc=sin(1000*t*t), aformat=sample_fmts=fltp,
>>> asplit [a][b];
>>> [a] firequalizer=fixed=on, showcqt=s=1280x360 [a1];
>>> [b] firequalizer=fixed=on, showcqt=s=1280x360 [b1];
>>> [a1][b1] vstack'
>>>
>>> the data will be corrupted because fixed=on enables partial_buf_size
>>> stuff
>>>
>>> Compare that without fixed=on.
>>
>> Hmm, so it seems Nicolas blocked [1/2] patch which is mandatory for [2/2]
>> one,
>> time without providing alternative solution.
>
> The alternative was 383057f8e744efeaaa3648a59bc577b25b055835, of
> course. I approved it at that time.

This is all one big mess.