On Sat, 9 Dec 2023, Kalev Lember wrote:
With the way the runtime checks are currently set up, every single
openh264 release, no matter how minor, is considered an ABI break and
requires ffmpeg recompilation. This is unnecessarily strict because it
doesn't allow downstream distributions to ship a
With the way the runtime checks are currently set up, every single
openh264 release, no matter how minor, is considered an ABI break and
requires ffmpeg recompilation. This is unnecessarily strict because it
doesn't allow downstream distributions to ship any openh264 bug fix
version updates without
On Fri, Dec 8, 2023 at 9:34 PM Martin Storsjö wrote:
> If that was when the soname version was introduced, that sounds reasonable
> - since then, there's at least an intent not to break it (even if mistakes
> always can happen).
>
Yep, 1.3.0 is when the soname version was introduced. Let's go wi
On Fri, 8 Dec 2023, Kalev Lember wrote:
On Fri, Dec 8, 2023 at 8:12 PM Cosmin Stejerean via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
As of what version of openh264 though is it safe to assume that ABI won't
change without soname changes? Since years ago ABI changes without soname
changes
On Fri, Dec 8, 2023 at 8:12 PM Cosmin Stejerean via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
> As of what version of openh264 though is it safe to assume that ABI won't
> change without soname changes? Since years ago ABI changes without soname
> changes were present there's likely to be som
> On Dec 8, 2023, at 11:07 AM, Kalev Lember wrote:
>
> On Fri, Dec 8, 2023 at 4:59 PM James Almer wrote:
>
>> Does the configure check ensure a new enough openh264 version is the
>> minimum supported?
>>
>
> Hm, I'd say that configure minimum version check is mostly orthogonal to
> the patc
On 12/8/2023 4:07 PM, Kalev Lember wrote:
On Fri, Dec 8, 2023 at 4:59 PM James Almer wrote:
Does the configure check ensure a new enough openh264 version is the
minimum supported?
Hm, I'd say that configure minimum version check is mostly orthogonal to
the patch here.
This patch just remov
On Fri, Dec 8, 2023 at 4:59 PM James Almer wrote:
> Does the configure check ensure a new enough openh264 version is the
> minimum supported?
>
Hm, I'd say that configure minimum version check is mostly orthogonal to
the patch here.
This patch just removes a check that made it error out if the
On 12/8/2023 5:15 AM, Kalev Lember wrote:
Years ago, openh264 releases often changed their ABI without changing
the library soname. To avoid running into ABI issues, a version check
was added to lavc libopenh264 code to error out at runtime in case the
build time and runtime openh264 versions don
On Fri, Dec 8, 2023 at 3:16 AM Kalev Lember wrote:
>
> Years ago, openh264 releases often changed their ABI without changing
> the library soname. To avoid running into ABI issues, a version check
> was added to lavc libopenh264 code to error out at runtime in case the
> build time and runtime ope
On Fri, 8 Dec 2023, Kalev Lember wrote:
On Fri, Dec 8, 2023 at 1:00 PM Martin Storsjö wrote:
On Fri, 8 Dec 2023, Kalev Lember wrote:
> As for dlopening, I think instead of version checks, it would
make sense to
> try to dlsym() all of the actual required symbols, and e
On Fri, Dec 8, 2023 at 1:00 PM Martin Storsjö wrote:
> On Fri, 8 Dec 2023, Kalev Lember wrote:
>
> > As for dlopening, I think instead of version checks, it would make sense
> to
> > try to dlsym() all of the actual required symbols, and error out in init
> if
> > anything is missing. That should
On Fri, 8 Dec 2023, Kalev Lember wrote:
As for dlopening, I think instead of version checks, it would make sense to
try to dlsym() all of the actual required symbols, and error out in init if
anything is missing. That should make it all super flexible and resilient to
e.g. struct size changes th
On Fri, Dec 8, 2023 at 9:39 AM Martin Storsjö wrote:
> I guess this seems reasonable to me, so LGTM.
>
> The version check would be more relevant if we would be dlopening the
> OpenH264 library (which pretty much is what one has to do in order to take
> advantage of the patent offer from Cisco),
Hi,
On Fri, 8 Dec 2023, Kalev Lember wrote:
This should no longer be an issue with newer openh264 releases and we
can drop the runtime version check and rely on upstream doing the right
thing and bump the library soname if the ABI changes, similar to how
other libraries are consumed in ffmpeg.
Years ago, openh264 releases often changed their ABI without changing
the library soname. To avoid running into ABI issues, a version check
was added to lavc libopenh264 code to error out at runtime in case the
build time and runtime openh264 versions don't match.
This should no longer be an issue
16 matches
Mail list logo
