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 <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
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
_______________________________________________
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".
