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

[Martin Storsjö]

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

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