[FFmpeg-devel] [PATCH]Possible configure support for VDPAU

[Ivan Kalvachev]

On 2/9/09, Diego Biurrun <diego at biurrun.de> wrote:
> On Mon, Feb 09, 2009 at 02:06:21AM +0200, Ivan Kalvachev wrote:
>> On 1/6/09, M?ns Rullg?rd <mans at mansr.com> wrote:
>> >
>> > Gwenole Beauchesne wrote:
>> >>
>> >> On Tue, 6 Jan 2009, M?ns Rullg?rd wrote:
>> >>
>> >>>> I would like to avoid plain header name provided by the vendor, even
>> >>>> if
>> >>>> it's installed under another directory. i.e. avoid plain vdpau.h, or
>> >>>> plain
>> >>>> va.h (or other_kind_hwaccel_api.h) in the future.
>> >>>>
>> >>>> e.g. for VA API, va.h is currently not installed under a specific va/
>> >>>> directory. So, a #include "va.h" would be ambiguous.
>> >>>
>> >>> Yes!  Now we can have a code-gem like this:
>> >>>
>> >>> #include <va.h>
>> >>> #include "va.h"
>> >>
>> >> Except that <va.h> would be in the "va.h" file, so are you fan of some
>> >> #include_next magic?
>> >
>> > No magic needed, unless you used -I. on the compiler command line, and
>> > FFmpeg doesn't do that.
>>
>> We are not talking about FFmpeg only, as vdpau<_render>.h is (going to
>> be) public api.
>> An application can do -Ilibavcodec -Ix11 and then include vdpau.
>
> You have missed an old discussion.  We have a lot of non-unique header
> names already.  An example is png.h.  That's why we have changed FFmpeg
> internally to always use full relative paths with e.g. libavcodec/
> prefixes in the #include.
>
> It is the only way to use FFmpeg or libavcodec correctly.  Everything
> else is bound to fail.

Still, there is no reason to change header from one form to more generic form
only because YOU don't like it.