[FFmpeg-devel] [PATCH] fix build, avcodec: update OpenH264 header path

[Daniel Pocock]

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 at 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