[FFmpeg-devel] On in-tree external headers

Mark Thompson sw at jkqxz.net
Mon Oct 30 21:51:10 EET 2017


Hi all,

The recent submission of AMD AMF patches including a builtin header prompted me to think further about what external API headers should actually be included in the tree.

For the AMD headers (like V4L2 previously), it seems entirely silly to include them - they are available upstream in a free form which can easily be packaged and available on any build machine to use.

However, there is the problem that this in some sense places them second-class to the Nvidia implementation, which includes all headers in-tree and automatically enables itself - any normal build for x86 will include Nvidia support by default if the user doesn't explicitly disable it.  The effect of that is essentially that the ffmpeg project is facilitating Nvidia's anti-open behaviour by including the headers, which is I think something we really shouldn't be doing.

So: can we please precisely codify under what circumstances external headers should be included in the ffmpeg tree?

As an initial position for consideration, I propose "no external headers may be included in the ffmpeg tree".  That is, the contents of the compat/ directory should only be OS/compiler compatibility workarounds, not any functional headers.

Would anyone like to propose an alternative position?  (Precisely defined - "what we have now" would need some clarification of what that actually means so that we can apply it consistently to future requests.)

I also ask that, whatever discussion here ends up with, the voting committee should vote to ratify it so that we don't have to discuss it again every time someone proposes including headers.

Thanks,

- Mark


PS:

On 26/10/17 21:53, Philip Langdale wrote:
> the nvenc header is there for the reason stated: it's too hard to otherwise
> obtain, and when you do obtain it, it's not in an installable form, so we
> don't know how to find it on the build machine in any sane way.
> 
> The cuda headers in our tree are there because there were actually reverse
> engineered, as the official cuda headers don't have a reasonable licence.

None of this stops an individual from creating an independent repository and packaging the headers for open-source projects (including ffmpeg) to use.  This might be better for other open-source projects as well, because they could refer to that repository rather than having to either include the headers themselves directly (as ffmpeg currently does) or engage in whatever pain is necessary to use them from Nvidia.


PPS:

The position stated above would imply removing the avisynth headers.  Can anyone who uses it comment on what would be required for that?


More information about the ffmpeg-devel mailing list