| Message ID | 752868c0-25e3-8801-67fa-0a4ec1adb0c4@pocock.pro |
|---|---|
| State | New |
| Headers | show |
| Series | [FFmpeg-devel] fix build, avcodec: update OpenH264 header path | expand |
| Context | Check | Description |
|---|---|---|
| andriy/make_aarch64_jetson | success | Make finished |
| andriy/make_fate_aarch64_jetson | success | Make fate finished |
| yinshiyou/make_loongarch64 | success | Make finished |
| yinshiyou/make_fate_loongarch64 | success | Make fate finished |
| andriy/make_armv7_RPi4 | success | Make finished |
| andriy/make_fate_armv7_RPi4 | success | Make fate finished |
On Tue, Mar 1, 2022 at 9:16 AM Daniel Pocock <daniel@pocock.pro> wrote: > > > This updates the locations searched for the OpenH264 headers to be > consistent with upstream > > Discussed here: > https://github.com/cisco/openh264/pull/3415 > > Due to the change in the pkgconfig file, it is possible to compile with > either: > > #include <openh264/codec_api.h> > > OR > > #include <codec_api.h> > > but in this patch, I used the former. > Which releases of the library have the updated location? Will older releases still work, if so, which? As far as I can see, the change is days old and not in any release, so committing this now would break compatibility with anything but OpenH264 git master? Is that correct? - Hendrik
On 01/03/2022 10:19, Hendrik Leppkes wrote: > On Tue, Mar 1, 2022 at 9:16 AM Daniel Pocock <daniel@pocock.pro> wrote: >> >> >> This updates the locations searched for the OpenH264 headers to be >> consistent with upstream >> >> Discussed here: >> https://github.com/cisco/openh264/pull/3415 >> >> Due to the change in the pkgconfig file, it is possible to compile with >> either: >> >> #include <openh264/codec_api.h> >> >> OR >> >> #include <codec_api.h> >> >> but in this patch, I used the former. >> > > Which releases of the library have the updated location? Will older > releases still work, if so, which? This patch is very trivial and doesn't attempt to support older releases of OpenH264. Please keep in mind the OpenH264 code is patented and not widely installed in Linux distributions. Developers have to download it directly each time they include it in a project. So there doesn't appear to be a compelling case to support many versions concurrently. > As far as I can see, the change is days old and not in any release, so > committing this now would break compatibility with anything but > OpenH264 git master? Is that correct? Yes, that is correct Jeff made a comment in Github about this change breaking the ffmpeg build. I don't know which combination of ffmpeg and OpenH264 he is aiming to build. It would be a good idea to commit in ffmpeg whenever OpenH264 makes another tag. Their last tag was v2.2.0 on 28 January and the next one will eventually appear on this page: https://github.com/cisco/openh264/tags Regards, Daniel
On Tue, 1 Mar 2022, Daniel Pocock wrote: > > > On 01/03/2022 10:19, Hendrik Leppkes wrote: >> On Tue, Mar 1, 2022 at 9:16 AM Daniel Pocock <daniel@pocock.pro> wrote: >>> >>> >>> This updates the locations searched for the OpenH264 headers to be >>> consistent with upstream >>> >>> Discussed here: >>> https://github.com/cisco/openh264/pull/3415 >>> >>> Due to the change in the pkgconfig file, it is possible to compile with >>> either: >>> >>> #include <openh264/codec_api.h> >>> >>> OR >>> >>> #include <codec_api.h> >>> >>> but in this patch, I used the former. >>> >> >> Which releases of the library have the updated location? Will older >> releases still work, if so, which? > > This patch is very trivial and doesn't attempt to support older releases > of OpenH264. So far, ffmpeg has supported a range of versions of OpenH264, from 1.3 up to the latest version. > Please keep in mind the OpenH264 code is patented .. and how does that differ from the code in libavcodec? > and not widely installed in Linux distributions. Developers have to > download it directly each time they include it in a project. > So there doesn't appear to be a compelling case to support many versions > concurrently. First off, supporting one or more versions is kinda essential for being able to track down any regression in the combination of the two projects. Then secondly, OpenH264 does provide binaries for the existing releases, with the extra benefit that if you have the users download the binary from Cisco, Cisco covers the patent license fee for that individual copy of the library. To be able to benefit from this, you need to build ffmpeg against one of the existing releases out there. So TL;DR, just because _you_ don't see a reason for supporting older releases, please don't deprive others of the ability to do that. So to support latest git master of OpenH264, we'd instead have to add a configure check to see what include path the library happens to use. // Martin
On 01/03/2022 14:27, Martin Storsjö wrote: > On Tue, 1 Mar 2022, Daniel Pocock wrote: > >> >> >> On 01/03/2022 10:19, Hendrik Leppkes wrote: >>> On Tue, Mar 1, 2022 at 9:16 AM Daniel Pocock <daniel@pocock.pro> wrote: >>>> >>>> >>>> This updates the locations searched for the OpenH264 headers to be >>>> consistent with upstream >>>> >>>> Discussed here: >>>> https://github.com/cisco/openh264/pull/3415 >>>> >>>> Due to the change in the pkgconfig file, it is possible to compile with >>>> either: >>>> >>>> #include <openh264/codec_api.h> >>>> >>>> OR >>>> >>>> #include <codec_api.h> >>>> >>>> but in this patch, I used the former. >>>> >>> >>> Which releases of the library have the updated location? Will older >>> releases still work, if so, which? >> >> This patch is very trivial and doesn't attempt to support older releases >> of OpenH264. > > So far, ffmpeg has supported a range of versions of OpenH264, from 1.3 > up to the latest version. > >> Please keep in mind the OpenH264 code is patented > > .. and how does that differ from the code in libavcodec? The libavcodec/libopenh264*.c files do not implement the patented algorithm, they simply wrap the library > >> and not widely installed in Linux distributions. Developers have to >> download it directly each time they include it in a project. > >> So there doesn't appear to be a compelling case to support many >> versions concurrently. > > First off, supporting one or more versions is kinda essential for being > able to track down any regression in the combination of the two projects. > > Then secondly, OpenH264 does provide binaries for the existing releases, > with the extra benefit that if you have the users download the binary > from Cisco, Cisco covers the patent license fee for that individual copy > of the library. To be able to benefit from this, you need to build > ffmpeg against one of the existing releases out there. > > So TL;DR, just because _you_ don't see a reason for supporting older > releases, please don't deprive others of the ability to do that. > > So to support latest git master of OpenH264, we'd instead have to add a > configure check to see what include path the library happens to use. If somebody wants to test some other permutation as part of a search for a regression they could create a symlink manually before running configure. Nothing changes in the API so no code changes are necessary As an example: mkdir /tmp/old-openh264 ln -s /usr/include/wels /tmp/old-openh264/openh264 ./configure --extra-cflags=-I/tmp/old-openh264 Regards, Daniel
On Tue, 1 Mar 2022, Daniel Pocock wrote: > On 01/03/2022 14:27, Martin Storsjö wrote: >> On Tue, 1 Mar 2022, Daniel Pocock wrote: >> >>> >>> >>> On 01/03/2022 10:19, Hendrik Leppkes wrote: >>>> On Tue, Mar 1, 2022 at 9:16 AM Daniel Pocock <daniel@pocock.pro> wrote: >>>>> >>>>> >>>>> This updates the locations searched for the OpenH264 headers to be >>>>> consistent with upstream >>>>> >>>>> Discussed here: >>>>> https://github.com/cisco/openh264/pull/3415 >>>>> >>>>> Due to the change in the pkgconfig file, it is possible to compile with >>>>> either: >>>>> >>>>> #include <openh264/codec_api.h> >>>>> >>>>> OR >>>>> >>>>> #include <codec_api.h> >>>>> >>>>> but in this patch, I used the former. >>>>> >>>> >>>> Which releases of the library have the updated location? Will older >>>> releases still work, if so, which? >>> >>> This patch is very trivial and doesn't attempt to support older releases >>> of OpenH264. >> >> So far, ffmpeg has supported a range of versions of OpenH264, from 1.3 >> up to the latest version. >> >>> Please keep in mind the OpenH264 code is patented >> >> .. and how does that differ from the code in libavcodec? > > The libavcodec/libopenh264*.c files do not implement the patented > algorithm, they simply wrap the library That's not what I meant. I meant that libavcodec/h264*.c also implement patented algorithms, yet multiple distributions package and ship that code. Therefore, this is no argument for why OpenH264 couldn't be shipped as part of a distribution (even if it admittedly isn't done much). >> First off, supporting one or more versions is kinda essential for being >> able to track down any regression in the combination of the two projects. >> >> Then secondly, OpenH264 does provide binaries for the existing releases, >> with the extra benefit that if you have the users download the binary >> from Cisco, Cisco covers the patent license fee for that individual copy >> of the library. To be able to benefit from this, you need to build >> ffmpeg against one of the existing releases out there. >> >> So TL;DR, just because _you_ don't see a reason for supporting older >> releases, please don't deprive others of the ability to do that. >> >> So to support latest git master of OpenH264, we'd instead have to add a >> configure check to see what include path the library happens to use. > > If somebody wants to test some other permutation as part of a search for > a regression they could create a symlink manually before running configure. > > Nothing changes in the API so no code changes are necessary > > As an example: > > mkdir /tmp/old-openh264 > ln -s /usr/include/wels /tmp/old-openh264/openh264 > > ./configure --extra-cflags=-I/tmp/old-openh264 But users shouldn't need to do that! So far users could use a wide range of versions - and you're arguing that everybody should be inconvenienced - for no visible gain whatsoever. // Martin
On Tue, Mar 01, 2022 at 09:16:17AM +0100, Daniel Pocock wrote: > > This updates the locations searched for the OpenH264 headers to be > consistent with upstream > > Discussed here: > https://github.com/cisco/openh264/pull/3415 > > Due to the change in the pkgconfig file, it is possible to compile with > either: > > #include <openh264/codec_api.h> > > OR > > #include <codec_api.h> > > but in this patch, I used the former. > > Regards, > > Daniel > > -- > Debian Developer > https://danielpocock.com > configure | 2 +- > libavcodec/libopenh264.c | 4 ++-- > libavcodec/libopenh264dec.c | 4 ++-- > libavcodec/libopenh264enc.c | 4 ++-- > 4 files changed, 7 insertions(+), 7 deletions(-) > 281ee5285fd9f4b7f9ae94f3786e0006de037b6a 0001-avcodec-update-OpenH264-header-path.patch > From 6736ae3d20db9cb79b328c6e3e9080c42c6216d4 Mon Sep 17 00:00:00 2001 > From: Daniel Pocock <daniel@pocock.pro> > Date: Tue, 1 Mar 2022 09:09:00 +0100 > Subject: [PATCH] avcodec: update OpenH264 header path breaks build here on ubuntu x86_64 ERROR: openh264 not found using pkg-config If you think configure made a mistake, make sure you are using the latest version from Git. If the latest version fails, report the problem to the ffmpeg-user@ffmpeg.org mailing list or IRC #ffmpeg on irc.libera.chat. Include the log file "ffbuild/config.log" produced by configure as this will help solve the problem. [...]
diff --git a/configure b/configure index 8c69ab0c86..a08d86049c 100755 --- a/configure +++ b/configure @@ -6562,7 +6562,7 @@ enabled libopencv && { check_headers opencv2/core/core_c.h && { check_pkg_config libopencv opencv opencv2/core/core_c.h cvCreateImageHeader || require libopencv opencv2/core/core_c.h cvCreateImageHeader -lopencv_core -lopencv_imgproc; } || require_pkg_config libopencv opencv opencv/cxcore.h cvCreateImageHeader; } -enabled libopenh264 && require_pkg_config libopenh264 openh264 wels/codec_api.h WelsGetCodecVersion +enabled libopenh264 && require_pkg_config libopenh264 openh264 openh264/codec_api.h WelsGetCodecVersion enabled libopenjpeg && { check_pkg_config libopenjpeg "libopenjp2 >= 2.1.0" openjpeg.h opj_version || { require_pkg_config libopenjpeg "libopenjp2 >= 2.1.0" openjpeg.h opj_version -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } } enabled libopenmpt && require_pkg_config libopenmpt "libopenmpt >= 0.2.6557" libopenmpt/libopenmpt.h openmpt_module_create -lstdc++ && append libopenmpt_extralibs "-lstdc++" diff --git a/libavcodec/libopenh264.c b/libavcodec/libopenh264.c index 0f6d28ed88..a230e2ae5f 100644 --- a/libavcodec/libopenh264.c +++ b/libavcodec/libopenh264.c @@ -20,8 +20,8 @@ */ #include <string.h> -#include <wels/codec_api.h> -#include <wels/codec_ver.h> +#include <openh264/codec_api.h> +#include <openh264/codec_ver.h> #include "libavutil/error.h" #include "libavutil/log.h" diff --git a/libavcodec/libopenh264dec.c b/libavcodec/libopenh264dec.c index 7f5e85402a..9d1210ca3e 100644 --- a/libavcodec/libopenh264dec.c +++ b/libavcodec/libopenh264dec.c @@ -19,8 +19,8 @@ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA */ -#include <wels/codec_api.h> -#include <wels/codec_ver.h> +#include <openh264/codec_api.h> +#include <openh264/codec_ver.h> #include "libavutil/common.h" #include "libavutil/fifo.h" diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c index 7c0501a2eb..605c0c0532 100644 --- a/libavcodec/libopenh264enc.c +++ b/libavcodec/libopenh264enc.c @@ -19,8 +19,8 @@ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA */ -#include <wels/codec_api.h> -#include <wels/codec_ver.h> +#include <openh264/codec_api.h> +#include <openh264/codec_ver.h> #include "libavutil/attributes.h" #include "libavutil/common.h"