[FFmpeg-devel] [PATCH] fix build, avcodec: update OpenH264 header path
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
OR
#include
but in this patch, I used the former.
Regards,
Daniel
--
Debian Developer
https://danielpocock.com
>From 6736ae3d20db9cb79b328c6e3e9080c42c6216d4 Mon Sep 17 00:00:00 2001
From: Daniel Pocock
Date: Tue, 1 Mar 2022 09:09:00 +0100
Subject: [PATCH] avcodec: update OpenH264 header path
---
configure | 2 +-
libavcodec/libopenh264.c| 4 ++--
libavcodec/libopenh264dec.c | 4 ++--
libavcodec/libopenh264enc.c | 4 ++--
4 files changed, 7 insertions(+), 7 deletions(-)
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
-#include
-#include
+#include
+#include
#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
-#include
+#include
+#include
#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
-#include
+#include
+#include
#include "libavutil/attributes.h"
#include "libavutil/common.h"
--
2.30.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fix build, avcodec: update OpenH264 header path
On 01/03/2022 10:19, Hendrik Leppkes wrote: > On Tue, Mar 1, 2022 at 9:16 AM 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 >> >> OR >> >> #include >> >> 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 -- Debian Developer https://danielpocock.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fix build, avcodec: update OpenH264 header path
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 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 >>>> >>>> OR >>>> >>>> #include >>>> >>>> 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 -- https://danielpocock.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
