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 <dan...@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 -- 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".
