mån 2020-07-06 klockan 01:28 +0200 skrev Michael Niedermayer:
> On Sun, Jul 05, 2020 at 11:48:14PM +0200, Jan Engelhardt wrote:
> > On Sunday 2020-07-05 23:17, Michael Niedermayer wrote:
> > > so its all doable in theory, but at that point the question arises, can we
> > > maybe generate this
On Sun, Jul 05, 2020 at 11:48:14PM +0200, Jan Engelhardt wrote:
>
> On Sunday 2020-07-05 23:17, Michael Niedermayer wrote:
> >
> >so its all doable in theory, but at that point the question arises, can we
> >maybe generate this automatically from the APIchanges file if we decide to
> >do that.
>
On Sunday 2020-07-05 23:17, Michael Niedermayer wrote:
>
>so its all doable in theory, but at that point the question arises, can we
>maybe generate this automatically from the APIchanges file if we decide to
>do that.
>APIchanges should list all added functions and the version numbers.
On Sun, Jul 05, 2020 at 05:08:51PM +0200, Tomas Härdin wrote:
> sön 2020-07-05 klockan 14:10 +0200 skrev Jan Engelhardt:
> > On Sunday 2020-07-05 13:39, Tomas Härdin wrote:
> > > > > Downgrading to a .so file with a lower minor version number than
> > > > > the program is built against can never
On 7/5/2020 3:59 PM, Jan Engelhardt wrote:
>
> On Sunday 2020-07-05 19:21, James Almer wrote:
>>> 8 files changed, 1163 insertions(+), 44 deletions(-)
>>
>> The list of functions is incomplete. After a quick look, you're for
>> example missing av_map_videotoolbox_format_* in libavutil.[..]
>>
On Sunday 2020-07-05 19:21, James Almer wrote:
>> 8 files changed, 1163 insertions(+), 44 deletions(-)
>
>The list of functions is incomplete. After a quick look, you're for
>example missing av_map_videotoolbox_format_* in libavutil.[..]
>This is another issue that i don't know if you
On Sun, Jul 5, 2020 at 7:29 PM James Almer wrote:
>
> On 7/5/2020 1:58 PM, Jan Engelhardt wrote:
> >
> > On Sunday 2020-07-05 18:18, James Almer wrote:
>
> Won't that break the entire ABI of anything currently linked, and thus
> would
> require a major bump?
> >>>
> >>> Since
On 7/5/2020 1:58 PM, Jan Engelhardt wrote:
>
> On Sunday 2020-07-05 18:18, James Almer wrote:
Won't that break the entire ABI of anything currently linked, and thus
would
require a major bump?
>>>
>>> Since 4.3 was sort of a break over 4.2.3 already
>>
>> No, it wasn't.
>
>
On Sunday 2020-07-05 18:18, James Almer wrote:
>>>
>>> Won't that break the entire ABI of anything currently linked, and thus would
>>> require a major bump?
>>
>> Since 4.3 was sort of a break over 4.2.3 already
>
>No, it wasn't.
Perhaps not on a high level. But for the ELF system, it was a
On 7/5/2020 12:46 PM, Jan Engelhardt wrote:
>
> On Sunday 2020-07-05 16:43, Timo Rothenpieler wrote:
>>> LIBAVCODEC_58 {
>>>global:
>>>av_foo;
>>>av_bar;
>>>av_whatever_else_there_is;...
>>>local:
>>>*;
>>> };
>>> LIBAVCODEC_58.91 {
>>>global:
>>>
On 05.07.2020 17:46, Jan Engelhardt wrote:
On Sunday 2020-07-05 16:43, Timo Rothenpieler wrote:
LIBAVCODEC_58 {
global:
av_foo;
av_bar;
av_whatever_else_there_is;...
local:
*;
};
LIBAVCODEC_58.91 {
global:
avpriv_mpeg4audio_get_config2;
} LIBAVCODEC_58;
On Sunday 2020-07-05 16:43, Timo Rothenpieler wrote:
>> LIBAVCODEC_58 {
>>global:
>>av_foo;
>>av_bar;
>>av_whatever_else_there_is;...
>>local:
>>*;
>> };
>> LIBAVCODEC_58.91 {
>>global:
>>avpriv_mpeg4audio_get_config2;
>> } LIBAVCODEC_58;
>> LIBAVCODEC_58.123 { /*
Am So., 5. Juli 2020 um 16:44 Uhr schrieb Timo Rothenpieler
:
> Generally, this seems incredibly hard to maintain and will very likely
> cause confusion every time someone adds stuff in the future.
True, and this is while this will not even reach the committee.
Carl Eugen
Am So., 5. Juli 2020 um 16:46 Uhr schrieb Timo Rothenpieler
:
>
> On 05.07.2020 16:18, Carl Eugen Hoyos wrote:
> > Am So., 5. Juli 2020 um 01:38 Uhr schrieb Andreas Rheinhardt
> > :
> >
> >> This crash is due to Chromium using av_max_alloc in an undocumented way;
> >> more exactly, the Chromium
sön 2020-07-05 klockan 14:10 +0200 skrev Jan Engelhardt:
> On Sunday 2020-07-05 13:39, Tomas Härdin wrote:
> > > > Downgrading to a .so file with a lower minor version number than
> > > > the program is built against can never be expected to work. Else
> > > > we couldn't add new functions without
On Sun, 5 Jul 2020, Timo Rothenpieler wrote:
On 05.07.2020 16:18, Carl Eugen Hoyos wrote:
Am So., 5. Juli 2020 um 01:38 Uhr schrieb Andreas Rheinhardt
:
This crash is due to Chromium using av_max_alloc in an undocumented way;
more exactly, the Chromium FFmpeg fork changes the allocation
On 05.07.2020 16:18, Carl Eugen Hoyos wrote:
Am So., 5. Juli 2020 um 01:38 Uhr schrieb Andreas Rheinhardt
:
This crash is due to Chromium using av_max_alloc in an undocumented way;
more exactly, the Chromium FFmpeg fork changes the allocation functions
so that if max_alloc_size is zero, the
On 05.07.2020 14:10, Jan Engelhardt wrote:
On Sunday 2020-07-05 13:39, Tomas Härdin wrote:
Downgrading to a .so file with a lower minor version number than
the program is built against can never be expected to work. Else
we couldn't add new functions without a major bump.
It requires the use
Am So., 5. Juli 2020 um 10:43 Uhr schrieb Jan Engelhardt :
> A program may have been built with 4.3 but is combined
> with 4.2.3 at runtime
While I can only speak for myself, this is not only not supported,
it is also something that FFmpeg will not support in the future.
Carl Eugen
, then
Am So., 5. Juli 2020 um 01:38 Uhr schrieb Andreas Rheinhardt
:
> This crash is due to Chromium using av_max_alloc in an undocumented way;
> more exactly, the Chromium FFmpeg fork changes the allocation functions
> so that if max_alloc_size is zero, the limit is completely disabled; and
> of
On 7/5/2020 5:43 AM, Jan Engelhardt wrote:
>
> On Sunday 2020-07-05 01:04, James Almer wrote:
>> On 7/4/2020 7:54 PM, Jan Engelhardt wrote:
>>> @@ -67,6 +67,10 @@ typedef struct AVDCT {
>>> +
>>> +void (*get_pixels_unaligned)(int16_t *block /* align 16 */,
>>> + const
On Sunday 2020-07-05 13:39, Tomas Härdin wrote:
>>> Downgrading to a .so file with a lower minor version number than
>>> the program is built against can never be expected to work. Else
>>> we couldn't add new functions without a major bump.
>>
>> It requires the use ELF symbol versions -- which
sön 2020-07-05 klockan 12:54 +0200 skrev Jan Engelhardt:
> On Sunday 2020-07-05 12:06, Tomas Härdin wrote:
> > > Or, summarized: A program may have been built with 4.3 but is
> > > combined
> > > with 4.2.3 at runtime, then this can happen:
> > >
> > > a = avcodec_dct_alloc(); // allocates 896
On Sunday 2020-07-05 12:06, Tomas Härdin wrote:
>
>> Or, summarized: A program may have been built with 4.3 but is combined
>> with 4.2.3 at runtime, then this can happen:
>>
>> a = avcodec_dct_alloc(); // allocates 896
>> #ifdef HAVE_STRUCT_AVDCT_GET_PIXELS_UNALIGNED
>>
sön 2020-07-05 klockan 10:43 +0200 skrev Jan Engelhardt:
> On Sunday 2020-07-05 01:04, James Almer wrote:
> > [[the header file says:
> > * You can use AVOptions (av_opt* / av_set/get*()) to access these fields
> > from user
> > * applications.]]
>
> A "can" can be read as "need not". Perhaps
On Sun, Jul 5, 2020 at 10:43 AM Jan Engelhardt wrote:
>
> Or, summarized: A program may have been built with 4.3 but is combined
> with 4.2.3 at runtime, then this can happen:
>
Running against an older version then the build version is never
supported. ABI compatibility is only guaranteed
On Sunday 2020-07-05 01:04, James Almer wrote:
>On 7/4/2020 7:54 PM, Jan Engelhardt wrote:
>> @@ -67,6 +67,10 @@ typedef struct AVDCT {
>> +
>> +void (*get_pixels_unaligned)(int16_t *block /* align 16 */,
>> + const uint8_t *pixels,
>> + ptrdiff_t
Michael Niedermayer:
> On Sun, Jul 05, 2020 at 12:54:53AM +0200, Jan Engelhardt wrote:
>> Greetings.
>>
>>
>> Between ffmpeg-4.2.3 and ffmpeg-4.3, struct AVCodecContext,
>> publicly exposed through /usr/include, has been changed thus:
>>
>> --- avcodec.h 2020-06-11 11:45:16.0 +0200
>> +++
On Sun, Jul 05, 2020 at 12:54:53AM +0200, Jan Engelhardt wrote:
> Greetings.
>
>
> Between ffmpeg-4.2.3 and ffmpeg-4.3, struct AVCodecContext,
> publicly exposed through /usr/include, has been changed thus:
>
> --- avcodec.h 2020-06-11 11:45:16.0 +0200
> +++ avcodec.h 2020-07-01
On 7/4/2020 7:54 PM, Jan Engelhardt wrote:
> Greetings.
>
>
> Between ffmpeg-4.2.3 and ffmpeg-4.3, struct AVCodecContext,
> publicly exposed through /usr/include, has been changed thus:
>
> --- avcodec.h 2020-06-11 11:45:16.0 +0200
> +++ avcodec.h 2020-07-01 03:45:24.0 +0200
>
30 matches
Mail list logo
