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

Ivan Kalvachev ikalvachev
Mon Feb 9 01:15:23 CET 2009


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.




More information about the ffmpeg-devel mailing list