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 autom
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.
APIchange
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 be
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.[..]
>> Thi
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 considered,
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.
>
> P
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 bre
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:
>>>avpriv_mpeg4audio_g
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;
LIBAVCODE
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 { /* f
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 FFm
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 fun
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 lim
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 this
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 course
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 uin
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
>> a->get_pixels_u
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 tha
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 forwar
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 li
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
>> +++ a
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 03:45:24
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
> @@
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
@@ -3370,6 +2334,24 @@ typedef struct AVCodecContext {
*
31 matches
Mail list logo
