On Saturday 2022-07-23 16:32, Nicolas George wrote:
>
>No, the ELF symbol version system cannot prevent you from replacing a
>file with an older version.
The information in ELF helps package managers prevent such
replacement. If I even try as much as propose a glibc downgrade to
rpm, this will h
On Saturday 2022-07-23 15:28, Nicolas George wrote:
>Jan Engelhardt (12022-07-23):
>>
>> This is a follow-up to a topic that was already raised earlier,
>> http://ffmpeg.org/pipermail/ffmpeg-devel/2020-July/265694.html
>>
>> The same has now happened to 5.0->
This is a follow-up to a topic that was already raised earlier,
http://ffmpeg.org/pipermail/ffmpeg-devel/2020-July/265694.html
The same has now happened to 5.0->5.1.
==
abidiff /usr/lib64/libavcodec.so.59.18.100 b/usr/lib64/libavcodec.so.59.37.100
Functi
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 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,
for HEVC encoding (2020-07-05
23:43:45 +0800)
are available in the Git repository at:
git://github.com/jengelh/ffmpeg master
for you to fetch changes up to 3ec24e4e548ecd6d4cc2f11a7d6717548abdadab:
build: do proper ELF symbol versioning (2020-07-05 18:50:58 +0200)
---------
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
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
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
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,
>>
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 {
*
On Saturday 2017-06-03 14:27, Timo Rothenpieler wrote:
>
> It is made sure that the public ABI does not break between major releases,
> this
> the major version is not bumped.
> The problem in practice is that _a lot_ of downstream library users misuse the
> API, using non-public fields and what
On Saturday 2017-06-03 14:27, Timo Rothenpieler wrote:
>
>> could ffmpeg then ensure that the major is in fact bumped on major
>> releases? In distro context, a bump is easier to swallow than a
>> non-bump..
>
> It is made sure that the public ABI does not break between major
> releases, this the
On Saturday 2017-06-03 14:11, wm4 wrote:
>>
>> The layout of struct AVCodec changed. Four function pointers were
>> inserted in the middle, shifting void (*flush) to a new address. The
>> size of AVCodec also changed, which would have required a full MAJOR
>> bump.
>
>Those aren't even public
On Saturday 2017-06-03 13:34, Hendrik Leppkes wrote:
>On Sat, Jun 3, 2017 at 1:18 PM, Jan Engelhardt wrote:
>>
>>The layout of struct AVCodec changed. Four function pointers were
>>inserted in the middle, shifting void (*flush) to a new address.
>>The size of AVCode
On Saturday 2017-06-03 14:02, Hendrik Leppkes wrote:
>On Sat, Jun 3, 2017 at 1:58 PM, Jan Engelhardt wrote:
>>
>> On Saturday 2017-06-03 13:34, Hendrik Leppkes wrote:
>>>>
>>>> Fixing the .v file with a patch now won't help remedy the situation on
>
On Saturday 2017-06-03 13:34, Hendrik Leppkes wrote:
>>
>> Fixing the .v file with a patch now won't help remedy the situation on
>> existing systems; however, on future patch submissions, this action of
>> editing the .v file needs to be remembered when functions are
>> added or removed.
>
>We ha
I received a user report about ABI breakage between ffmpeg 3.0 and 3.3
through the distribution commenting system
https://build.opensuse.org/package/show/multimedia:libs/ffmpeg :
"""I'm having a library compiled against ffmpeg 3.3 on OBS. It
uses the avcodec_{send|receive}packe
18 matches
Mail list logo
