[FFmpeg-devel] FFmpeg 3.5 / 4.0

[James Almer]

On 4/12/2018 10:17 PM, James Almer wrote:
> On 4/12/2018 9:11 PM, Michael Niedermayer wrote:
>> On Thu, Apr 12, 2018 at 07:59:25PM -0300, James Almer wrote:
>>> On 4/12/2018 7:53 PM, Michael Niedermayer wrote:
>>>> On Mon, Feb 19, 2018 at 02:50:08AM +0100, Michael Niedermayer wrote:
>>>>> Hi
>>>>>
>>>>> Its 4 months since 3.4 was branched so its time for a new major release
>>>>>
>>>>> Is 4.0 or 3.5 preferred ?
>>>>> Any name suggestions ?
>>>>>
>>>>> If there are no objections i will likely make that release in the next weeks
>>>>
>>>> more time has passed than intended ...
>>>>
>>>> what issues do remain that need to be fixed before the release ?
>>>> I see fate.ffmpeg.org is not looking that well (compared to most
>>>> releases in the past) i remember this being pretty much green longer ago
>>>> do people want these to be fixed before the release ?
>>>>
>>>> Thanks
>>>
>>> I fixed two targets the other day, and another has the patch pending in
>>> the ml (OpenBSD). 
>>
>>> Then there are your FreeBSD clients that you need to
>>> switch to yasm, 
>>
>> I can do that, it doesnt feel right though. configure should not pick
>> a nasm that then fails later.
> 
> Do you have a suggestion of what kind of configure check could trigger
> this failure? As is, all the current checks are succeeding. It's only
> failing once it tries to compile the first asm file in the tree.
> 
>>
>>
>>> and apply the fix to the c11 check in configure.
>>
>> you want me to apply it ?
>> or i misunderstand ?
> 
> You confirmed it worked ("foo += bar" and "bar = 0" alike), so push
> whichever you prefer, yes.
> 
>>
>>
>>>
>>> The kfreebsd failures are for the tests filter-metadata-silencedetect
>>> and checkasm-aacpsdsp. After a recent patch silencedetect prints float
>>> values with more precision. Paul said to remove the test and forget
>>> about it, but no idea if there's a better solution.
>>
>> of course removing the test is the easy solution.
>> there is only 1 test for silencedetect, so that would remove not just
>> one silencedetect test but all silencedetect tests
>>
>> The test currently uses a amrwb test file which is decoded with a
>> non bitexact float decoder.
>> has someone tried to replace this by bitexact input ?
> 
> Do we have a relatively quiet sample using a bitexact codec like this
> amrwb one? Or we could convert it to flac and upload it instead.
> 
>>
>> Thanks

In any case, save for the c11 configure check fix, none of these issues
should IMO block the release seeing it was already delayed enough. They
are either strict float comparisons in fate (Where the fix is using a
laxer comparison value), or external issues like broken assemblers and
binutils tools.