On Sat, Mar 24, 2018 at 11:10:41AM +0100, Carlo Bramini wrote:
> Hello,
>
> > > > > However, what about the patch attached for fixing the declaration
> > > > > of ff_adpcm_afc_coeffs[2][16]?
> > > >
> > > > This would revert 10542491, a relatively recent change: Maybe Paul,
> > > > the author, wa
Hello,
> > > > However, what about the patch attached for fixing the declaration
> > > > of ff_adpcm_afc_coeffs[2][16]?
> > >
> > > This would revert 10542491, a relatively recent change: Maybe Paul,
> > > the author, wants to comment.
> > >
> > > Do you think the code gets more readable?
> >
>
2018-03-23 12:35 GMT+01:00, Carlo Bramini :
> Hello everyone,
>
>> Il 11 marzo 2018 alle 11.42 Carl Eugen Hoyos ha
>> scritto:
>>
>> 2018-03-11 11:27 GMT+01:00 Carlo Bramini :
>>
>> > Hello,
>> > I see. I expected that adding that could be considered out of the coding
>> > guidelines.
>>
>> You mi
Hello everyone,
> Il 11 marzo 2018 alle 11.42 Carl Eugen Hoyos ha scritto:
>
> 2018-03-11 11:27 GMT+01:00 Carlo Bramini :
>
> > Hello,
> > I see. I expected that adding that could be considered out of the coding
> > guidelines.
>
> You misunderstand:
> The issue is not (afaict) the coding gui
2018-03-11 11:27 GMT+01:00 Carlo Bramini :
> Hello,
> I see. I expected that adding that could be considered out of the coding
> guidelines.
You misunderstand:
The issue is not (afaict) the coding guidelines but the fact that the
change would mean we claim a compatibility that we cannot guarantee
Hello,
I see. I expected that adding that could be considered out of the coding
guidelines.
However, what about the patch attached for fixing the declaration of
ff_adpcm_afc_coeffs[2][16]?
Although it works because the binary values are the same, this is wrong,
independently by the fact that you
2018-03-10 15:02 GMT+01:00 Carlo Bramini :
> I noticed this thing because I compiled those sources with a more robust
> syntax check, by using C++ rather that plain C. At pratical level, nothing
> changed, except for the .h files that required to use the extern "C" keyword.
> I was wondering if
On Sat, 10 Mar 2018 15:02:56 +0100 (CET)
Carlo Bramini wrote:
> and just add FFMPEG_EXTERN_C_BEGIN and FFMPEG_EXTERN_C_END to the top and to
> the bottom of each include file. You could take it as a suggestion, allowing
> compilation with both GCC and G++ may show you some defects you cannot se
On Sat, 10 Mar 2018 15:02:56 +0100 (CET)
Carlo Bramini wrote:
> and just add FFMPEG_EXTERN_C_BEGIN and FFMPEG_EXTERN_C_END to the top and to
> the bottom of each include file. You could take it as a suggestion, allowing
> compilation with both GCC and G++ may show you some defects you cannot se
Hello,
while working with ADPCM source code, I noticed that there is a type mismatch
in ff_adpcm_afc_coeffs[2][16]. Inside libavcodec/adpcm_data.c it is declared as
uint16_t:
https://github.com/FFmpeg/FFmpeg/blob/d168e78effd170377ec57f67bca05c9f0de91bca/libavcodec/adpcm_data.c#L109
but into lib
10 matches
Mail list logo